The Procure-to-Pay Business Process in a WMS Integration
This section discusses:
Requisitions.
Purchase orders.
Purchase order expected receipts processing.
Receiving.
The procure-to-pay business process enables companies to buy goods and services from their suppliers. Here is an overview of the process in a WMS integration:
PeopleSoft components are used to manage stock replenishment, create requisitions and purchase orders, and automatically source and dispatch the purchase orders.
When the requested stock on purchase orders arrives, the WMS handles the receiving, inspection, and putaway transactions for the stock.
The PeopleSoft system provides costing and accounts payable functions.
Procure-to-Pay Process Flow in a WMS Integration
The following diagram shows how the procure-to-pay functions are performed in a WMS integration. PeopleSoft creates and dispatches the purchase order or the interunit stock request. The Purchase Order Expected Receipts service operation or the Interunit Expected Receipt service operation is used to send expected receipt data to the WMS. The incoming stock is received and inspected by the WMS. The Purchase Order Receipt service operation or the Interunit Receipt service operation sends the receiving information back to PeopleSoft where inventory putaway, costing, and accounts payable vouchers are processed:
The following diagram shows how the procure-to-pay functions are performed
The EIPs that support the procure-to-pay business process in a WMS integration are based on a number of assumptions. The following sections detail these assumptions for each phase of the procure-to-pay business process.
Requisitions can be created in PeopleSoft Purchasing using a variety of methods. After a requisition is created, it moves through PeopleSoft Purchasing to become either a purchase order that is sent to a supplier or a demand that is staged in a PeopleSoft Inventory business unit. In a WMS integration, requisitions are created and maintained in the PeopleSoft system. Requisitions are not sent to the WMS.
As with requisitions, purchase orders can be created in PeopleSoft Purchasing using a variety of methods. After they are approved and sourced, purchase orders are dispatched to suppliers.
For purchase orders that will be received by a business unit under external warehouse control, the PeopleSoft system publishes outbound information using the Purchase Order Expected Receipts EIP. When receiving the stock from a purchase order, the WMS matches the actual receipt against the data in the PO expected receipts transaction.
The transactional data in the PO Expected Receipt EIP is sent to the WMS for dispatched purchase orders that are expected to be received within a user-defined period. If a change is made to a purchase order that has been included in a previous PO expected receipts transaction, another expected receipts transaction is published when the change event occurs. This includes closing or canceling the purchase order. When the WMS receives a PO expected receipts transaction for a purchase order with a Closed or Canceled status, the corresponding PO expected receipt transaction in the WMS can also be closed or canceled.
The PO expected receipts transaction includes purchase order header, order line, schedule line, and comment information. The PO expected receipt line segment includes an order quantity field that represents the total of the associated schedule lines. The schedule line segment contains a combination of specific purchase order line, schedule, and distribution information. Purchase order comments and notes segments are provided at the header, line, and schedule levels.
Note: The order quantity on the receipt line is provided for WMSs that cannot handle the three-level purchase order structure (header, line, and schedule). In this case, the WMS uses the purchase order line-level receipt variation (Transaction Code 0103) of the purchase order receipt transaction.
In the PeopleSoft system, there are two service operations that make up the Purchase Order Expected Receipt EIP:
The first service operation (PO_EXPECTED_RECEIPT_BUS_UNIT) contains PO expected receipt information for a specific PeopleSoft Inventory business unit.
For example, you may have a single purchase order line with an order quantity of 75 units that are distributed among three different PeopleSoft Inventory business units for a quantity of 25 units each. Three different purchase order expected receipt transactions containing an order line quantity of 25 are generated, one for each inventory business unit. This is the transaction that is used in most WMS implementations, because most WMSs expect purchase order information for the specific business unit under their control.
The second service operation (PO_EXPECTED_RECEIPT_SHIPTO) contains PO expected receipt information for a specific ship to location.
In this case, the PO expected receipts are grouped by ship to location instead of business unit. Using this second type of purchase order expected receipt transaction in the preceding example, the system generates a single transaction for a total quantity of 75 units.
The Publish Outbound Message process publishes the purchase order expected receipt data for all PeopleSoft Inventory business units or ship to locations on purchase orders that meet specified selection criteria.
Only the Process Outbound Message process publishes purchase order expected receipt data. An expected receipt transaction cannot be generated from the Return to Vendor - RTV page. This constraint has the following implications for a WMS integration:
When you reopen a purchase order in PeopleSoft, no transaction is sent to the WMS to reopen the purchase order; however, if you make a change to the reopened purchase order, the system sends a PO expected receipt message to the WMS, where the purchase order has a Closed status.
To resolve this discrepancy, you can set up the WMS to reopen a purchase order automatically if a PO expected receipt transaction is received for a closed purchase order. Alternatively, for business units under WMS control, the option to reopen purchase orders for supplier returns, RTV Reopen PO, can be disabled in the PeopleSoft system on the Purchasing Definition - Business Unit Options page.
When you perform a vendor return in PeopleSoft Purchasing, you can return a quantity for replacement.
When you select the return-for-replacement option, the quantity that was received is reduced by the quantity you are returning for replacement. This logic makes the open quantity on the purchase order equal to the returned quantity. However, because no PO expected receipt data is sent to the WMS from the Return to Vendor - RTV page, the new open quantity is not reflected in the WMS. To resolve this discrepancy, you can either:
Enable the WMS to over-receive, this will allow receipts greater than the original order quantity.
This solution requires that the WMS be able to receive against a closed purchase order. If the purchase order was originally closed in the PeopleSoft system and then reopened from the RTV page, the status of the purchase order remains closed in the WMS.
Disable the RTV Adjust Source option on the Purchasing Definition - Business Unit Options page.
When you disable this option, the receipt quantity (Net Receive Qty) is not decreased when you return for replacement from the Return to Vendor - RTV page. With this solution, after entering the return-to-vendor information, you add a new schedule for the replacement quantity on the Purchase Order - Form page. The change on the Purchase Order Form page generates PO expected receipt information, which provides the WMS with an open quantity against which to receive.
Interunit Transfer Expected Receipts Processing
Interunit transfer orders are created in the PeopleSoft system to move stock between business units. The Interunit Expected Receipt EIP is an asynchronous outbound service operation (INTERUNIT_EXPECTED_RECEIPT). The transactional data is generated by the Process Outbound Message process using this EIP when an interunit transfer order has a destination business unit that is under external warehouse control and the transfer order is depleted. The WMS uses the information from the interunit expected receipt EIP to validate the receipt of goods when the shipment arrives at the destination warehouse.
The interunit expected receipt EIP includes receipt header information and receipt lines with details of each item that was shipped.
In PeopleSoft Inventory, you can cancel in-transit interunit transfer orders using the Cancel Interunit Transfers page. For transfer orders that have been sent out on previous interunit expected receipt transaction, the cancellation transaction generates an interunit expected receipt transaction with a status of Cancel.
In a WMS integration, all receiving, inspection, and putaway activities are performed using the WMS. To confirm that stock has been received for a purchase order or an interunit transfer, the WMS sends a receipt confirmation transaction to the PeopleSoft system using the Purchase Order Receipt EIP or the Interunit Receipt EIP.
For both purchase order and interunit receipts, the receipt confirmation transaction includes header information and receipt lines with details about what was physically received at the business unit under WMS control.
The WMS can include the receipt ID and receipt line number in either of the receipt confirmation transactions. To ensure that receipt IDs assigned by the WMS are unique, define a range of ID numbers during implementation for exclusive use by the WMS. If the receipt ID is not included on the confirmation , the PeopleSoft system generates one automatically.
If either of the receipt confirmation transactions includes the material storage location data, the item is put away to the specified material storage location. Otherwise, the item is put away using the putaway rules defined for the business unit.
Blind receipts from a WMS are not accepted. All receipt confirmation data that the WMS sends must have a valid purchase order number or interunit ID number.
In PeopleSoft Purchasing, the Receiver Load process (PO_RECVLOAD) processes the purchase order receipt confirmation transactions. The Receiver Load process can accept purchase order receipts at either the purchase order line or schedule level. During a WMS implementation, consider these processing rules when deciding how best to use this functionality:
When working at the schedule level, the Receiver Load process receives the full quantity against a given schedule line number.
When working at the line level, the Receiver Load process applies the full quantity received to the first open schedule for that line unless the Allow Receipt Load Cascade option is enabled to cascade receipts across multiple schedules. If the cascading feature is enabled, any full quantity is applied to the first schedule, and any excess quantity is applied to the next schedule, and so on until the full quantity is consumed. You set the Allow Receipt Load Cascade option on the Purchasing Definition - Business Unit Options page.
The inventory business unit is included in the receipt transaction to associate the receipts to the appropriate distribution line.
If the inventory business unit is included on the transaction, the receipt affects only the quantity for the business unit's distribution line. If the inventory business unit is blank, the quantity received is received against each distribution line until the entire quantity for the schedule is received.
The Interunit Receiving process (INPJIURV) processes the interunit transfer receipt confirmation transactions. When an interunit receipt is completely received and closed, an interunit expected receipt transaction is generated with a status of Received. The Received status on the transaction indicates that the transfer order can be closed in the WMS system.