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.

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

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 the product documentation for PeopleTools: Integration Broker

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:

Record

Field

EM_PO_HDR_REC

BUSINESS_UNIT

PO_ID

TO_STATUS

PO_DT

VENDOR_ID

BUYER_ID

CURRENCY_CD

EM_PO_LINE_REC

BUSINESS_UNIT

PO_ID

LINE_NBR

CATEGORY_CD

UNIT_OF_MEASURE

DESCR254_MIXED

EM_PO_SHIP_REC

BUSINESS_UNIT

PO_ID

LINE_NBR

SCHED_NBR

PRICE_PO

DUE_DT

SHIPTO_ID

QTY_PO

MERCHANDISE_AMT

EM_PO_DIST_REC

BUSINESS_UNIT

PO_ID

LINE_NBR

SCHED_NBR

DST_ACCT_TYPE

DISTRIB_LINE_NUM

QTY_PO

MERCHANDISE_AMT

LOCATION

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.