Processing Invoices

This chapter provides an overview of electronic invoice creation and integration and the Open Applications Group (OAG) format, and discusses how to:

• Prepare for invoice XML integration.

• Define code sets.

• Process third-party transactions.

• Enter and manage self-service invoices.

• Run the eSettlements Notification Application Engine process (EM_NOTIFY_WF).

• Run the Voucher Build Application Engine process (AP_VCHRBLD).

• Verify externally received data and delete vouchers.

Understanding Electronic Invoice Creation and Integration

During the Voucher Integration process, XML messages are submitted to the PeopleSoft gateway and processed by Integration Broker. Subscription PeopleCode then validates data integrity, controls edits, adds registration and agreement default values, and converts the message into a PeopleSoft transaction. Once the system processes the information, the newly created transaction can be viewed through self-service invoice pages. Transactions must be loaded into the appropriate tables in order to view, approve, and pay invoices from suppliers.

Suppliers can transmit invoices in XML format (either PeopleSoft or OAG standard). When the invoices are related to purchase orders, the purchase order feed (message, file, or load) must precede the voucher feed. The voucher lines include the purchase order number, line number, and schedule number. If this information does not exist at the time that the invoice is interfaced, it is rejected.

Before invoices can be integrated, PeopleSoft procurement options must be specified. In addition, you must complete buyer, supplier, and agreement registrations.

See Also

Understanding Purchase Order and Receipt Integration

Entering and Processing Vouchers Online: General Voucher Entry Information

Understanding the OAG Format

OAG is a nonprofit organization that focuses on best practices and process-based XML content for application integration, and is the largest publisher of XML-based content for business software interoperability. The OAG format enables integrators to work with a standardized invoice represented in XML, such that integrators no longer need the specifications of the table structure for invoices in the receiving PeopleSoft database. Instead, integrators populate each XML tag in the OAG SyncInvoice business object document (BOD) that corresponds to a field on the PeopleSoft voucher staging tables.

Integration Broker defines a relationship between the sending node and the receiving node (the receiving node must be the default, local, active node), so that the system can run the appropriate Application Engine Transformation program. The transformation can leverage the code set functionality provided by Integration Broker; therefore, if you intend to use code sets for data translation, you must specify the code set group name for the two nodes involved in the relationship and enter the values that need to be translated.

This diagram illustrates the XML data flow:

XML invoice data flow

Preparing for Invoice XML Integration

Subscription PeopleCode converts XML messages into eSettlements transactions. This PeopleCode calls or references information that has been configured in PeopleSoft in a method similar to the way in which a save is accomplished through the online pages.

This section discusses how to:

1. Register buyers.

2. Register suppliers.

3. Create agreements.

4. Define voucher defaults.

Registering Buyers

Buyer registration establishes the buying entity in eSettlements and a corresponding business unit in the underlying PeopleSoft system. This creates the underlying business units from which the voucher processing options appear by default. These include pay from bank information, as well as the matching and value-added tax (VAT) preferences that automatically appear on the voucher, either during application messaging or the Voucher Build process.

Each buyer has a unique Payables business unit associated with it. If you plan to enable suppliers to use OAG XML functionality when transacting with a particular buyer in the Business Service Provider model—or when transacting with your organization in the Buyer Direct model—you must provide each supplier with the respective business unit value (identifier) for each buyer during buyer registration, so that each supplier can embed this identifier in the Header/Parties/BillToParty/PartyID/ID tag of the OAG XML file that they send.

If, for example, suppliers cannot embed this identifier in their files, the system administrator must define the identifier in their systems for this buyer. They must map this identifier to the buyer ID using code sets, so that each XML file provides a return value (translated value). This value uses the code set functionality for data translations in the Application Engine Transform program (EM_INV_OAG).

Supplier XML files must either contain this return value or must have the correct value in the appropriate corresponding tag.

Note. Read the code set sections in this chapter if you are not providing a valid identifier for the eSettlements application, because you must set up the code set to perform the data translation for the buyer value you provide in the XML file. If you don't provide a valid identifier, the subscription PeopleCode generates an email notification that the invoice failed edits.

See Also

Creating Buyers

Registering Suppliers

Supplier registration creates the selling entity in eSettlements and a corresponding vendor ID in the underlying PeopleSoft system. During registration, the supplier establishes basic location information, such as address, payment terms, and pay to bank account information. The system references these default values during the Voucher Build process.

See Also

Creating Suppliers

Defining Agreements

You use agreements to define general processing options that are unique to a given buyer-supplier combination. Agreements are by supplier location and contain processing options such as payment terms and pay from bank information. Subscription PeopleCode references this configuration as the system converts incoming voucher XML messages into eSettlements transactions.

Note. If a transacting buyer-supplier pair is using OAG XML invoices, the buyer must enter EM_SUPPLIER_REF in the Supplier Reference ID field on the agreement.

The OAG tag can be populated with either the EM_SUPPLIER_REF value that corresponds to the unique value entered on the agreement, or with a vendor ID. If the system cannot determine the vendor ID using the value in the Supplier Reference ID field, the system assumes that the value submitted is a valid vendor ID.

See Also

Understanding Agreements

Defining Voucher Defaults

Voucher transmission relies on the existence of tables established in previous tasks. These tables provide values for invoices that are not included in the XML feed or in the online entry.

Defining Code Sets

To define code sets, use the following components:

• Code Set Groups (IB_CODESETGROUP).

• Code Sets (IB_CODESET).

• Code Set Values (IB_CODESETVAL).

This section provides an overview of code sets and discusses how to:

• Enter match names and values and associate them with buyers.

• Enter match names and values into code sets.

• Associate match names and values with PeopleSoft field values.

Understanding Code Sets

Code sets are predefined mappings that translate data values between multiple systems. In eSettlements, code sets are only relevant for inbound third-party XML invoice integration using the OAG format and are not applicable to purchase orders or receipts.

An Application Engine Transform program maps the values provided by the supplier in the XML tags in the OAG-formatted invoice to PeopleSoft invoice fields at the header, line, and distribution levels. When the program encounters an XML tag where code set functionality is employed, it translates the value in the tag into a value appropriate to the receiving application, based on the return values specified on the Code Set Values page.

This table lists six fields that appear on the voucher tables. For data translation, enter code set values for all of these fields:

Note. If a supplier can transmit correct XML tag values that correspond with PeopleSoft field values that eSettlements can identify, then you do not have to enter code set values. For example, if BUY01 were transmitted by a supplier as a business unit, no code set lookup would be necessary, because PeopleSoft recognizes the business unit BUY01. However, you still must enter values for the UNIT_OF_MEASURE and—only if a given buyer operates in a value-added tax (VAT) country—for the TAX_CD_VAT fields.

eSettlements supports the OAG Version 8 SyncInvoice BOD format, as well as the PeopleSoft XML voucher format (message EM_VOUCHER_IN).

Note. Ensure you do not use special characters—such as the ampersand (&)—in your code sets, because such characters cannot be added to and saved correctly in an XML file.

See Also

PeopleTools PeopleBook: PeopleSoft Integration Broker

Pages Used to Define Code Sets

Entering Match Names and Values and Associating Them with Buyers

Access the Code Set Groups page.

Select EM_SUPPLIER as the code set group name for each of the six fields that require XML OAG data translation.

Note. You do not have to set up code sets or code set values for a field if your system can transmit the correct XML tag value that corresponds with the respective PeopleSoft field value, but you must set up the UNIT_OF_MEASURE, and, if you must use value-added tax (VAT), also set up the VAT_TX_CD code sets.

If the supplier's application populates the OAG XML SyncInvoice BOD with the buyer name in the Header/Parties/BillToParty/PartyID/ID tag, then enter a match name of BUYER and enter the buying organization name as the match value.

Note. Use the delivered EM_SUPPLIER code set group.

Entering Match Names and Values into Code Sets

Access the Code Sets page.

Note. You access the page by clicking the respective EM_SUPPLIER link on the search page for each of the six fields on which you potentially must implement code set functionality. Here you add the match name and match value pair that you entered previously, to the appropriate code set.

Associating Match Names and Values with PeopleSoft Field Values

Access the Code Set Values page.

Associate your match name and match value pair with the recipient's PeopleSoft field values by selecting the appropriate code set name for the PeopleSoft field that requires the incoming value to be translated.

Currency code is important when providing amounts. This table lists the values that must be provided as currency node attributes:

See Also

PeopleTools PeopleBook: PeopleSoft Integration Broker

Processing Third-Party Transactions

This section discusses how to:

• Load invoices.

• Populate invoice records.

Loading Invoices

Both OAG and PeopleSoft standard XML invoices are interfaced the same way and make use of the EM_VOUCHER_IN message definition. The message definition for vouchers is accessible through Application Designer. Use this tool to view the structure of the message and the subscription PeopleCode for incoming vouchers. When loading invoice data, the system validates the information and stores the data in the VCHR_HDR_QV, VCHR_LINE_QV, VCHR_DIST_QV tables, which are also used during self-service invoice creation.

Note. When loading invoice data for self-service invoices, the system also populates the VCHR_MSCH_QV table and the VCHR_MSCL_QV table.

In addition to copying data from XML to the voucher QV tables, the subscription PeopleCode in the EM_VOUCHER_IN message definition adds default values that would not normally be handled by the Voucher Build process. If an invoice is loaded and any of its required fields are invalid, an error message appears on the Integration Broker Message Monitor page.

When loading invoices using XML messages, if the invoice load errors notification type has been set up, then a notification is sent for any errors encountered during processing of the subscription PeopleCode for the EM_VOUCHER_IN message.

Note. Subscription PeopleCode errors generate only an initial email notification; reminder days notifications are not sent for PeopleCode errors.

The system administrator must modify, save, and resubmit the invoice until the message status is Done. Once the system receives an invoice that is free of errors, the buyer can review it. The email notification routings for invoices that cause errors, in either subscription PeopleCode or in pre-edit or edits in the Voucher Build process, are determined from the routings defined for invoice load errors notification at either the agreement level or the buyer and supplier location level.

All other invoices are available for selection by the Voucher Build process, which performs further edits according to the voucher processing rules, and populates these records:

• PS_VOUCHER

• PS_VOUCHER_LINE

• PS_DISTRIB_LINE

• PS_PYMNT_VCHR_XREF

When you run the Voucher Creation Notification Application Engine process (EM_VCHR_CRT) and a voucher fails any of these edits or rules, the system sends an email notification (if you set up this notification type), and the voucher is reported on the Correct Invoice Errors page. Reminder days notifications are also generated.

When suppliers submit the XML invoice (using PeopleTools SendMaster or any other XML posting utility), the system returns a confirmation BOD. If the OAG invoice is valid XML and is also a valid OAG BOD, the system sends a confirmation BOD containing a NounSuccess tag. If there are errors, the system sends a confirmation BOD containing a NounFailure tag that includes an explanation of the error.

Note. The system sends email notifications when invoices are successfully loaded, as well as when invoice transmission errors occur (whether recycled, pre-edit, or subscription PeopleCode XML). Email notifications are sent for both error and for success, and as with all email notifications, there is a hierarchy. The email routings for invoices with errors, either from subscription PeopleCode, pre-edit, or edits from the Voucher Build process, are determined from the routings set up for invoice load errors notification established at either the agreement level or at the buyer and supplier location level.

Once the vouchers populate Payables tables, the system administrator must run the Matching Application Engine process (AP_MATCH) to perform match edits between vouchers, purchase orders, and receipts.

See Also

Understanding Voucher Build Processing

Understanding Matching

Populating Invoice Records

For invoices associated with a purchase order or receipt, the distribution records do not have to be populated, because the Voucher Build process will create the distribution records by copying the distribution details from the purchase order or receipt document.

The following table lists record-field combinations that must be populated with valid data for each invoice. The OAG Tag column lists the XML tags that exist in the OAG SyncInvoice BOD that are applicable to a field on a PeopleSoft voucher record.

Note. An asterisk in the Field column indicates that the field is required.

See Also

Setting Up Numbering

Entering and Managing Self-Service Invoices

This section provides an overview of self-service invoice entry and management and discusses how to:

• Enter supplier invoice details.

• Edit invoice accounting line information.

• Copy purchase order information.

• Copy packing slip information.

• Complete online invoice entry.

• View and modify invoices.

• View and delete invoices.

• View and print invoices.

• Review invoices.

• Release and deny invoices.

• Correct invoice errors.

Understanding Self-Service Invoice Entry and Management

This section discusses:

• Invoice entry.

• Invoice processing.

• Invoice routing and verification.

• ChartField defaulting logic.

Invoice Entry

You can create an invoice by copying purchase orders, purchase order lines, or information from a packing slip, receipt, or receipt lines. However, only users assigned system administrator and supplier administrator role types can create invoices by copying invoice information from a purchase order or packing slip, or by adding invoice lines.

Because some amounts are only estimates at the time a purchase order is created, the system does not copy these specific amounts onto the self-service invoice. This means that users must enter the actual amounts when they become known (for example, when the goods are shipped) for the following amounts:

• Sales tax

• Use tax

• Value-added tax (VAT)

• Freight

• Miscellaneous charges

If an item-vendor relationship and pricing have been established for the supplier, then the supplier can select items from the item master, set up in Purchasing. This restricts suppliers to access items associated with their organization only. If ChartFields have been set up for an item, then they appear by default on the distribution line, along with unit pricing and unit of measure (UOM) information. Users can change this information. If an item-vendor relationship has not been established, then suppliers are not able to select items from the item master, but can still complete description, quantity, UOM, and unit price information.

Invoice Processing

Online invoices go through processes similar to those described in the previous Loading Invoices section. Online transactions are picked up by the Voucher Build process, in the same way as the XML invoice messages are picked up from external systems.

See Loading Invoices.

If email notifications have been established for invoice load errors, then the supplier receives an email if errors exist and are available for review. The supplier then notifies the system administrator of corrections that need to be made and can also request that a voucher be deleted so that it can be re-entered. The system administrator verifies voucher transactions after each process, to ensure that each transaction is error-free.

Just as with invoices submitted electronically, you must ensure that the Payables business unit is set up for invoice autonumbering.

You can review invoices before they pass through the Voucher Build process and become vouchers in the system. You can also make changes to the accounting associated with an invoice.

Invoice Routing and Verification

The system marks invoices designated for ChartField completion and review with a Voucher Build status of N (none). This status prevents the invoice from being selected by the Voucher Build process. Invoices with a status of N require verification of buyer-specified details by the requester or other buyer user for ChartField accuracy and completeness before being processed by the Voucher Build process. You set up invoice verification routing at the agreement level, and it is dependent upon the type of invoice (such as purchase order or non-purchase order), and the buyer-supplier location combination. During this invoice verification, the buyer adds ChartField values, if necessary, then releases the invoice for processing by clicking the Release for Processing button. This changes the invoice Voucher Build status to B (to build) and enables the Voucher Build process to pick it up.

When creating invoices, suppliers can save their work and then later review, correct, change, or add invoice details. At this point the Voucher Build status is I (initiated). Once the supplier is satisfied with the invoice, the Voucher Build status is N marking it for invoice verification, or B, enabling it to be picked up by the Voucher Build process.

Note. When the system routes notifications by role, all users associated with a given role receive the invoice verification notification. Similar to invoice header approval, when the first user in the correct role verifies the invoice and releases it for processing, the system sets the invoice voucher build status to B for selection by the Voucher Build process.

When the system routes notifications by multiple user IDs, roles, and requesters, the first of these users to access and release an invoice for processing sets the Voucher Build status to B.

If an invoice has the requester ID populated, then that user (the requester), if set up for it, receives the email notification. If an invoice does not have the requester ID populated then the system obtains the default requester (or role) from the email setup (agreement or buyer setID level). These users or roles receive notification and can perform the invoice verification.

ChartField Defaulting Logic

This section discusses how the system populates ChartField values on an invoice, depending on the invoice type.

For self-service, XML, and OAG invoices, the system uses the following logic (outlined in the table) to retrieve ChartField values. This table is ordered from the highest level (Level 1, the buyer template) to the lowest level (Level 4, the item ID value).

If an invoice is copied from a PO or receipt, the ChartFields are obtained from the PO or receipt. When an invoice is not created by copying a PO or receipt, and when ChartFields provide default values for self-service and XML invoices where a PO is not associated with the invoice line, the ChartFields are obtained as stated in the above table. The general ledger business unit is derived from the requester if populated; otherwise from the Payables Business Unit table (BUS_UNIT_TBL_AP).

If suppliers are able to enter ChartFields based on the agreement setup, then they can enter one distribution line per invoice line only. However, during the invoice review step, the buyer can add additional distribution lines.

The account definition is obtained from the Line/Distribution/Project/GLElement/NameValue field. However, for OAG invoices you must specify ACCOUNT as the node name for the NameValue field.

You specify the ability to view or edit ChartFields at the installation level, then at the buyer registration level, and further at the agreement level. Buyers specify whether a supplier can see the ChartFields, regardless of what the buyer has set up on buyer registration. When entering self-service invoices, suppliers can only view ChartFields, if access to them has been enabled by a given buyer.

See Also

Enabling ChartFields

Pages Used to Enter and Manage Self-Service Invoices

Entering Supplier Invoice Details

Access the Create Invoice - Invoice Entry page.

Invoice Header Information

Invoice Details

Additional Information Tab

Select the Additional Information tab.

PO Details Tab

Select the PO Details (purchase order details) tab.

View the PO unit, PO number, line, and schedule number information.

Receiver Details Tab

Select the Receiver Details tab.

View the receipt unit, receipt number, line, and schedule information.

Settlement Information

View the payment terms and method, and the various amounts for the invoice.

You can also enter a sales tax amount, shipping amount, and miscellaneous charge amount.

Editing Invoice Accounting Line Information

Access the Create Invoice - Invoice Entry page.

Click the Accounting button on the Additional Information tab on the Create Invoice - Invoice Entry page to access this page. Modify the ChartField values for each invoice line.

Note. Any ChartField values you define here for Account, Alternate Account, or Product fields overwrite any values established at the agreement or requester level.

See Understanding Self-Service Invoice Entry and Management.

Copying Purchase Order Information

Access the Create Invoice - Look Up a Purchase Order page.

Search Criteria

You can enter additional search criteria, such as purchase order unit, purchase order number, purchase order date, item ID, and description, if necessary, but the buyer and supplier values appear by default.

Search Results

Copying Packing Slip Information

Access the Create Invoice - Look Up a Packing Slip page.

Search Criteria

You can enter additional search criteria, such as receipt unit, packing slip, receipt number, receipt date, item ID, and description, if necessary, but the supplier value appears by default.

Search Results

Note. Clicking the Select button actually copies a receipt or packing slip. You can select one or many packing slips to copy, and one or many lines from one or many packing slips. You can also copy information from packing slips not associated with a purchase order.

Completing Online Invoice Entry

Access the Create Invoice - Invoice Entry page.

Note. Transfer to this page occurs when you click the Select button on either the Create Invoice - Look Up a Purchase Order or the Create Invoice - Look Up a Packing Slip page.

Complete the invoice by entering a location (if different from the default location), an invoice ID, and a requester (if applicable).

The Payment Terms and Payment Method field values appear by default according to the supplier entered.

You can also change the invoice date and the currency. You can enter a sales tax amount, shipping amount, and a miscellaneous charge amount.

Note. The currency is the type designated at the supplier location level. Otherwise, in the Buyer Direct model, the Payables default hierarchy determines the currency type. The payment terms appear by default from the agreement level.

If value-added tax (VAT) is applicable, then sales tax does not appear, and you can enter the VAT amount.

Viewing and Modifying Invoices

Access the Self-Service Invoice - View Invoice page.

Invoices

Note. You can edit only those invoices which have not been released for processing—invoices with a Voucher Build status of I (initiated).

Viewing and Deleting Invoices

Access the Self-Service Invoice - Delete Invoice page.

Invoices

Viewing and Printing Invoices

Access the Self-Service Invoice - Print Invoice page.

Invoices

Reviewing Invoices

Access the Self-Service Invoice - Review Invoice page.

You can enter search criteria.

You can modify the accounting information for any invoice lines that are subject to invoice verification.

Releasing and Denying Invoices

Access the Review Invoices - Invoice page.

Review invoice header and detail information.

See Also

Entering Supplier Invoice Details

Correcting Invoice Errors

Access the Self-Service Invoice - Correct Invoice Errors page.

Invoices

Note. You can only view and correct invoice errors after the Voucher Build process has run.

Depending on the nature of the errors, when you click the Correct Errors link on the Voucher Build Error Detail page, the system transfers you to either the Invoice Information page in Payables (for edit errors), or the Create Invoice - Invoice Entry page in eSettlements (for pre-edit errors).

Only the system administrator users—not suppliers—can correct edit errors. Suppliers can, however, correct pre-edit errors. All errors must be corrected before the invoice can be resubmitted.

See Also

Entering Invoice Information for Online Vouchers

Running the eSettlements Notifications Process

This section provides an overview of the eSettlements notification process and discusses how to run the eSettlements Notifications process.

Understanding the eSettlements Notifications Process

When buyers log in to the application and access the Buyer Dashboard page, the Invoices to Verify link provides a transfer to the Self-Service Invoice - Review Invoice page where the user can view the invoices awaiting his or her verification. Run the eSettlements Notifications process to generate the email notifications for invoice verifications, as well as to determine which invoices users need to verify.

Note. Upon receiving any email notification and clicking the link it contains, if the system returns an authorization error message you must add the component the user is trying to access to a permission list that is attached to the user's ID. Alternately, you can add another role that already has access to the component to the user's ID.

There is a hierarchy for invoice verification routing:

1. If an invoice has a value in the Requester field, then that user receives the email notification.

2. If an invoice does not have a Requester value, the default requester—or role—is the one defined at the agreement or buyer setID level.

These users or roles receive notification and can perform the invoice verification.

You can run this process for certain buyers by selecting Specify Buyers in the Invoice Processing drop-down list box, or for all buyers by selecting All Buyers.

See Also

PeopleTools PeopleBook: PeopleTools Security

Page Used to Run the eSettlements Notifications Process

Running the Voucher Build Process

This section provides an overview of and discusses how to run the Voucher Build process.

The Voucher Build process performs the first series of edits on the vouchers entered through the self-service invoice pages or received electronically into the Voucher Header (VCHR_HDR_QV), Voucher Line (VCHR_LINE_QV), and Voucher Distribution (VCHR_DIST_QV) tables. The system then moves these transactions to the edit tables.

When invoices are created from the Voucher Build process (self-service invoices), or loaded from other sources such as XML, the system obtains the origin for the voucher from the user ID of the user creating the invoice. In cases where no voucher origin can be obtained this way, the system obtains the voucher origin from the origin ID associated with the user running the Voucher Build process.

In the case of duplicate invoice entry, the Voucher Build process puts duplicate invoices into the status Recycled.

See Also

Defining Payables Business Units

Defining Cross-Application User Preferences

Page Used to Run the Voucher Build Process

Running the Voucher Build Process

Access the Voucher Build page.

Interfaces

Verifying Externally Received Data and Deleting Vouchers

The system reformats and integrates externally received third-party application data, including self-service and XML invoice data. Several pages enable you to view this data to correct errors or delete vouchers containing errors. Voucher deletion is applicable to both self-service and XML invoices.

This section lists the pages to verify externally received data and delete vouchers.

Pages Used to View Externally Received Data and Delete Vouchers

See Also

Modifying, Unposting, Deleting, and Closing Multiple Vouchers

Processing Batch Vouchers