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
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.

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.