Understanding Purchase Order and Receipt Integration

This section discusses:

  • General implementation information.

  • PeopleSoft Purchasing default hierarchy.

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

If you are implementing PeopleSoft eSettlements using the Buyer Direct model, the information in this topic 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 PeopleTools: 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.

 PeopleSoft eSettlements purchase order, receipt, and payment data flow

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

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.

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.