Processing Purchase Orders and Receipts in PeopleSoft eSettlements

This chapter provides an overview of purchase order and receipt integration in the Business Service Provider model and discusses how to:

• Define buyer item categories.

• Process third-party purchase orders.

• Verify externally received purchase order and receipt data.

• Prepare for receipt integration.

• Process third-party receipts.

• Verify externally received transaction data.

• Load receipts into PeopleSoft Purchasing records.

• Create receipts.

Understanding Purchase Order and Receipt Integration

This section discusses:

• General implementation information.

• PeopleSoft Purchasing default hierarchy.

General Implementation Information

If you are implementing PeopleSoft eSettlements as the Business Service Provider model, you must implement the functionality discussed in this chapter to process purchase orders and receipts.

If you are implementing PeopleSoft eSettlements using the Buyer Direct model, the information in this chapter is not applicable because you implement and use the Buyer Direct model in conjunction with PeopleSoft Purchasing, and use PeopleSoft Purchasing pages to manage purchase order and receipt processing.

Purchase order transactions from third-party products for use in PeopleSoft eSettlements are predicated on the use of XML messaging and the PeopleSoft open integration architecture. Once you register a buyer and a supplier in PeopleSoft eSettlements and establish PeopleSoft Procurement options, integration can occur. The system retrieves XML messages from the third-party product and transmits them for processing by using PeopleSoft Integration Broker. Subscription PeopleCode validates data integrity, controls edits, adds registration defaults, and converts the message into a PeopleSoft transaction. Once the transaction is processed, you can view it in PeopleSoft Purchasing tables.

Note. Oracle delivers integration points as application messages and as web services. Enabling messaging is discussed in the Enterprise PeopleTools PeopleBook: Integration Broker.

PeopleSoft eSettlements integrates fully with PeopleSoft eProcurement and can also be implemented with a variety of third-party procurement applications, such as Commerce One or Ariba. In cases in which PeopleSoft eSettlements is not implemented with PeopleSoft eProcurement, you can configure PeopleSoft eSettlements to receive purchase orders from an external system for use in the settlement process.

Note. You cannot view or process Payables vouchers marked with the Procurement Card (PCard) payment method in PeopleSoft eSettlements.

Note. Before loading an XML file, you must set up a valid node and channel.

This diagram illustrates purchase order, receipt, and payment data flow into and out of the PeopleSoft eSettlements system.

Note. The specifics of this diagram also apply to the Buyer Direct model.

PeopleSoft eSettlements purchase order, receipt, and payment data flow

See Also

Understanding Purchase Orders

Enterprise PeopleTools PeopleBook: Integration Broker

PeopleSoft Purchasing Default Hierarchy

This section discusses the purchasing default hierarchy at the purchase order header and line levels.

Note. The Buyer Direct model uses the PeopleSoft Purchasing default hierarchy for processing purchase orders and receipts.

See Using Default Hierarchies.

Purchase Order Header Defaults

The Business Service Provider model uses the buyer and supplier agreements for match control and payment term defaults for PO header data. If no valid agreement exists, the system uses the buyer and supplier registrations.

The host administrator defines the match rule control during the global PeopleSoft setup. The buyer administrator then specifies the match rule control ID during buyer registration. This ID is used as the default value on agreements, although it can be changed there as well.

The supplier administrator defines payment terms either during supplier registration or agreement registration. When a valid agreement exists between a buyer and supplier, default matching and payment terms from the buyer and supplier agreement information pages appear on the purchase order header and schedule details. The values for the default supplier location are obtained from the agreement.

When purchase orders are created prior to the existence of a valid agreement, default matching information appears from buyer registration settings, and default payment terms information appears from the supplier location registration settings.

This diagram illustrates the purchase order default hierarchy when an agreement does and does not exist:

Purchase order default hierarchy when a valid agreement does and does not exist

The following diagram illustrates how the existence of an agreement affects subsequent default values:

Matching control and payment terms defaults if a valid agreement does or does not exist

Note. These diagrams are valid only for the Business Service Provider model.

Purchase Order Line Defaults

The Business Service Provider model uses item category attributes defined at the business unit level for PO, PO schedule, and PO distribution line defaults. If no attributes exist, the system uses the defaults from the item category setID level. The system always obtains the account defaults from the item category setID level. You can override all defaults at the purchase order level.

The following diagram illustrates the processing logic used to obtain correct item category attribute information:

Matching and receiving tolerance defaults used to obtain item category attribute information

Note. This diagram is valid only for the Business Service Provider model.

If the buyer has item category attributes defined at the business unit level, the system:

• Obtains the Receipt Required value from the buyer (business unit) item category attributes level.

  This value appears automatically on the purchase order line (PS_PO_LINE).

• Obtains the account from the item category setID level, because the account field does not appear at the business unit level of the item category.

• Obtains matching and receiving tolerances from the buyer item category level.

  These controls are used as default values on the purchase order schedule (PS_PO_LINE_SHIP).

If the buyer does not have item category attributes at the business unit level, the system:

• Obtains the receipt required value from the item category setID level.

  This value is used as the default on the purchase order line.

• Obtains the account from the item category setID level.

• Obtains matching and receiving tolerances from the item category setID level.

  These tolerances are used as default values on the purchase order schedule.

See Also

Creating Agreements

Defining Buyer Item Categories

The host administrator defines item categories at the buyer (business unit) level, including preferences for matching tolerances and receiving controls. Because item categories are a way to group items together, and because item categories are determined by setID, the attributes defined at the setID level for an item category are the same for all buyers. Use document association rules to group items for matching when you use descriptions on the purchase orders instead of item IDs.

To define buyer item categories, use the Maintain Item Categories (EM_ITEM_CATEGORIES) and Document Association Rules (AP_ASSOCIATION) components.

This section provides an overview of item category processing for business units and discusses how to:

• Define and maintain item categories.

• Define document association criteria.

• View, define, and maintain item category matching and receiving controls.

• (Optional) Define matching and receiving tolerances.

Understanding Item Category Processing for Business Units

Using item categories is a way to group items together. PeopleSoft eSettlements processes item categories in much the same way as PeopleSoft Purchasing. However, in PeopleSoft eSettlements, you can add attributes to item categories at the buyer (business unit) level and at the setID level. Attributes defined at the buyer item category level override those defined at the setID level.

You can establish buyer item category attributes on the Item Categories - Buyer Specific Attributes page, but this is not required for purchase order and receipt processing. When you create a purchase order, the system verifies whether buyer item category attributes are already established for that buyer. If so, then the purchase order is automatically populated with the selected receipt required, receiving details, and matching and receiving tolerances . If no buyer item category attributes are available, the defaults are derived from the setID item category attributes.

Fields not shown on the Item Categories - Buyer Specific Attributes page are automatically populated from the setID level. These same attributes are used during the Matching Application Engine process (AP_MATCH).

Note. Before you can interface purchase orders, you must set up item categories.

Pages Used to Define Buyer Item Categories

Defining and Maintaining Item Categories

Access the Item Categories - Category Definition page (eSettlements, Administration, Maintain Item Categories, Category Definition).

Enter an effective date, status, description, short description, and account for this category.

See Also

Viewing and Updating Document Association Rules

Defining Document Association Criteria

Access the Document Association Rules page (Set Up Financials/Supply Chain, Product Related, Procurement Options, Vouchers, Document Association Rules).

To enable receipt summarization on orders that have only an item category and a description, use the delivered Receipt document association rules. Use this configuration if you are ordering by description and are not using items on the purchase orders.

See Also

Viewing and Updating Document Association Rules

Viewing, Defining, and Maintaining Item Category Matching and Receiving Controls

Access the Item Categories - Category Definition 2 page (eSettlements, Administration, Maintain Item Categories, Category Definition 2).

Matching Controls

Receiving Controls

See Also

Defining Purchasing Item Information

Defining Matching and Receiving Tolerances

Access the Buyer Specific Attributes page (click the Buyer Specific Attributes link on the Item Categories - Category Definition page).

Buyer and Effective Date

Specify these if a buyer uses matching tolerances and receiving controls other than those defined at the setID level for this purchasing business unit. If you enter a buyer (business unit) and leave the tolerance fields blank, the system assumes that the buyer accepts standard tolerances. If the buyer accepts standard tolerances, do not complete any fields on this page. Note. If this page is left blank, setID level tolerances and receiving controls appear by default.

Processing Third-Party Purchase Orders

When loading information from third-party products, PeopleSoft eSettlements can process any purchase order information, provided the necessary setup is complete.

This section discusses how to:

• Populate required fields.

• Format incoming XML files.

• Load purchase orders.

Populating Required Fields

The following are standard, required fields for PeopleSoft Purchasing and must be populated in the purchase order XML file for processing by PeopleSoft eSettlements before purchase orders can be loaded successfully:

• BUSINESS_UNIT

• BUYER_ID

• VENDOR_ID

• CURRENCY_CD

• CATEGORY_CD

• ACCOUNT

• UNIT_OF_MEASURE

• SHIPTO_ID

• LOCATION

Formatting Incoming XML Files

Subscription PeopleCode transforms an XML message into a PeopleSoft eSettlements transaction. This PeopleCode populates the application tables in a manner similar to that of the online pages.

This interface uses standard PeopleSoft XML format. During implementation, the exchange host can select an Electronic Application Integration (EAI) or other product to facilitate this integration. The message definition for PeopleSoft eSettlements purchase orders is EM_PO_MSG. You can use PeopleSoft Application Designer to view the structure of the message and the subscription PeopleCode for the incoming purchase orders.

Note. Before loading an XML file, you must set up a valid node and channel.

See Also

Enterprise PeopleTools PeopleBook: Integration Broker

Loading Purchase Orders

The system validates purchase order data and converts it to a purchase order while loading it from an XML file. For this to occur, the following conditions must be met:

• Changes to an externally loaded purchase order can be made only if the purchase order status is Approved.

  Once the purchase order status becomes Dispatched, no changes can be made. Prior to entering a receipt or creating a voucher for the purchase order, the purchase order status must be Dispatched. When a purchase order is successfully loaded, users can access that purchase order only through inquiry pages. Users other than the host are not given add or update access to valid purchase orders.

• Once a validated purchase order is loaded, the system performs further edits according to the processing rules for that purchase order.

  Where a purchase order fails any of these edits, the system displays an error message in PeopleSoft Integration Broker. For example, if a purchase order is loaded with invalid data, the system displays an error message, and the host administrator modifies and resubmits the purchase order until the message status is Done. You can access the message by selecting PeopleTools, Integration Broker, Service Operations Monitor, Monitoring, Asynchronous Services.

• All key purchase order fields must be populated.

  If a purchase order is submitted with a missing or invalid key field, the message appears with an error status.

  The host administrator must then correct the data in PeopleSoft Integration Broker and resubmit the message until the message status is Done. Alternatively, the host administrator can cancel the error message, and the buyer can correct the XML and resubmit it. If a user leaves a key field blank and the host administrator corrects it, that field is corrected throughout the purchase order. For example, if the purchase order message is missing the BUSINESS_UNIT field throughout the message, it has an Error status, because the field failed edits. The host administrator must then determine where in the message the field has been left blank. Because the field is blank throughout the purchase order, the host administrator can correct the error once at the highest level of the message where the field was left blank. For purchase orders, the highest level is PO_HDR, followed by PO_LINE, PO_LINE_SHIP, and finally PO_LINE_DISTRIB. Once the host administrator saves the message, the field is populated with the entered value throughout the message.

The system loads purchase orders from an XML file directly into the following PeopleSoft Purchasing records:

• PO_HDR

• PO_LINE

• PO_LINE_SHIP

• PO_LINE_DISTRIB

The following diagram illustrates the purchase order data flows along four levels:

Purchase order data flow from third-party systems to the PO records

The XML message requires that the following key record and field combinations are populated with valid data for each purchase order:

When purchase orders are interfaced through an XML file, purchase order tables are populated through the following views:

• EM_PO_HDR_VW

• EM_PO_LINE_VW

• EM_PO_SHIP_VW

• EM_PO_DIST_VW

All field-edit validations for externally loaded purchase orders are defined on the tables in these views. During the XML load, the system validates data values in the XML against the edit prompts defined in the purchase order record-field combination table. The XML data must exist in these edit tables before the purchase order can be loaded successfully. When a data element does not exist in the edit tables, the entire XML message is set in error and must be corrected before further processing. Default values other than those retrieved from the agreement and the item category are also established on these tables.

Verifying Externally Received Purchase Order and Receipt Data

PeopleSoft delivers several pages to enable you to view details of integrated purchase orders and receipts.

This section discusses how to:

• Inquire about purchase orders.

• Review purchase order details.

• Inquire about receipts.

• Review receipt details.

• Review voucher information for purchase orders or receipts.

Pages Used to Verify Externally Received Purchase Order and Receipt Data

Inquiring About Purchase Orders

Access the Review Purchase Orders - Purchase Order Inquiry page (eSettlements, Procurement Information, Review Purchase Orders, Review Purchase Orders - Purchase Order Inquiry).

You can specify a particular buyer and purchase order to limit your search results. Use the fields in the Advanced Search group box to further narrow your inquiry.

Reviewing Purchase Order Details

Access the Review Purchase Orders - Purchase Order Detail page (click a link in the PO column on the Review Purchase Orders - Purchase Order Inquiry page).

Voucher	Click a link in this column to view invoice and payment details.
Receipt No (receipt number)	Click to view receipt line details.

See Also

Reviewing Invoices

Inquiring About Receipts

Access the Review Receipts - Receipt Inquiry page (eSettlements, Procurement Information, Review Receipts, Review Receipts - Receipt Inquiry).

This page is similar to the Review Purchase Orders - Purchase Order Inquiry page.

Reviewing Receipt Details

Access the Review Receipts - Receipt Detail page (click a link in the Receipt Number column on the Review Receipts - Receipt Inquiry page).

This page is similar in form and function to the Review Purchase Orders - Purchase Order Detail page, but it displays the associated purchase order for the receipt.

Review Voucher Information for Purchase Orders or Receipts

Access the Review Purchase Orders - Invoice Details page or the Review Receipts - Invoice Details page (click a link in the Voucher column on the Review Receipts - Receipt Detail page).

These pages display voucher information for purchase orders and receipts.

Preparing for Receipt Integration

As with PeopleSoft Purchasing, receipts can be created either online or by loading an XML file. To successfully create a receipt, a valid purchase order must exists with the status Dispatched to receive against. Receipts support the Matching process when receiving is required. The reconciliation of a purchase order, an invoice, and a receipt is known as three-way matching. When receiving is required, the receipt must be present before the invoice can be matched successfully.

See Also

Understanding Purchase Order and Receipt Integration

Understanding the Receiving Business Process

Processing Third-Party Receipts

XML messages are pushed to the PeopleSoft gateway, and then processed by PeopleSoft Integration Broker. Subscription PeopleCode validates data integrity, controls edits, adds registration defaults, and converts the message into a PeopleSoft transaction. When loading information from a third party, the PeopleSoft Integration Broker can process receipt information, provided the necessary setup is complete.

This section discusses how to:

• Format incoming receipt files.

• Use transaction codes.

See Also

Receiving Items Using EDC

Understanding the Receiving Business Process

Formatting Incoming Receipt Files

Standard PeopleSoft XML format is used to format incoming receipt files. The message definition for receipts is (PURCHASE_ORDER_RECEIPT). Use PeopleSoft Application Designer to view the structure of the message and the subscription PeopleCode for the incoming receipts.

Note. Before loading an XML file, you must set up a valid node and channel.

Note. In addition to delivering the PO Receipt EIP as an application message (PURCHASE_ORDER_RECEIPT), Oracle also delivers it as a web service. Enabling web services is discussed in the Enterprise PeopleTools PeopleBook: Integration Broker.

The XML message requires that the following record and field combinations be populated with valid data for each receipt:

Using Transaction Codes

The system uses the following transaction codes:

At the child label of the message, you can indicate what you are receiving in this particular shipment by entering the appropriate code. If you specify code 0102, you must enter the PO and the business unit for the PO. If you specify 0103, you must provide the quantity, PO, unit, line number, and unit of measure (UOM). If you specify 0104, you must enter the quantity, PO, unit, line, schedule number, and UOM.

The end transaction flag (END_TRANS_FLAG) tells the system whether this message can be processed and whether the receipt can be created immediately. If the flag status is N, the data remains in the system with an incomplete status—therefore, populate this flag with Y.

Verifying Externally Received Transaction Data

After XML messages are loaded, the host administrator can identify and correct errors and verify receipt data before it is written to the receipt records. The Receipt Load Application Engine process (PO_RECVLOAD) then loads the transaction data into the receipt records. After the process successfully finishes, the host administrator can view receipts on the Receiving page. Once the receipt XML file is created and loaded, the host administrator must verify that the receipts have been loaded and have passed edits successfully.

The host administrator can view, correct, and resubmit transactions on the Transaction Maintenance pages. For example, if an XML file is loaded with a blank Ship To ID field, that file generates an error message. The host administrator must correct the errors and then resubmit the message from the Transaction Maintenance pages.

After errors have been corrected and the messages have been resubmitted, the messages are picked up by the Receipt Load process.

This section lists the pages used to verify externally received transaction data.

Pages Used to Verify Externally Received Transaction Data

See Also

PeopleSoft SCM Inbound EIPs

Using Transaction Maintenance

Receiving Items Using EDC

Loading Receipts Received Using EIPs and EDC

Loading Receipts into PeopleSoft Purchasing Records

After error-free receipt data has been loaded successfully into PeopleSoft staging tables, the host administrator runs the Receipt Load process to load receipt data into PeopleSoft Purchasing records.

This section lists the pages used to load receipts into purchasing records.

See Also

Loading Receipts Received Using EIPs and EDC

Pages Used to Load Receipts into PeopleSoft Purchasing Records

Creating Receipts

You can also enter receipts by creating them on the Select Purchase Order page.

This section discusses how to enter receipts.

Pages Used to Create Receipts

Entering Receipts

Access the Select Purchase Order page (eSettlements, Procurement Information, Create Receipt).

To create receipts:

1. Enter the relevant search information.

2. Click Search.

3. Select the Sel (select) check box of any purchase order.

4. Click the OK button.

   The system automatically creates the receipt and displays the Maintain Receipts - Receiving page.

5. Use the Maintain Receipts - Receiving page to define receipt details, view associated information, and cancel receipt information.

See Also

Selecting Purchase Orders

Receiving Purchase Order Items