Understanding Warehouse Management Systems

This chapter discusses:

• General warehouse management system (WMS) integration issues.

• WMS enterprise integration points (EIPs).

• The order-to-cash business process in a WMS integration.

• The procure-to-pay business process in a WMS integration.

• Four-wall warehousing functions in a WMS integration.

• Static information updates in a WMS integration.

General WMS Integration Issues

This section discusses system-wide assumptions about WMS integration.

Integrating PeopleSoft with a third-party WMS enables you to streamline the order-to-cash and procure-to-pay business processes. This streamlining enables you to reduce costs, improve service levels, and generate more revenue.

You can integrate the following products with a WMS:

• PeopleSoft Purchasing.

• PeopleSoft Payables.

• PeopleSoft Order Management.

• PeopleSoft Inventory.

The integration consists of generic EIPs using service operations in PeopleSoft Integration Broker to exchange transactional and static data between the PeopleSoft system and the WMS. Transactional data relates to order processing and material management. Static data relates to customers, items, carriers, and locations.

System-Wide Assumptions About WMS Integration

The WMS integration works as designed only if you understand certain system-wide assumptions and your system complies with them. The following sections discuss these assumptions.

Business Units

One WMS installation corresponds to one PeopleSoft Inventory business unit. When defining the PeopleSoft Inventory business unit in the PeopleSoft system, you specify that the business unit is under external warehouse control on the Inventory Definition - Business Unit Options page.

Static Information

All static information, such as customer, vendor, carrier, and item information, is maintained in the PeopleSoft system. Updates are sent to the WMS when new information is added or changes are made to existing information. Changes made to this information within the WMS are not sent back to the PeopleSoft system.

Quantity Balance Data

The WMS drives all inventory balances. The WMS sends material movement transactions to the PeopleSoft system. Any material movement transactions initiated in the system are not sent to the WMS. If the WMS is not manually updated to reflect a material movement transaction performed in the PeopleSoft system, quantity balance data between the two systems will not agree.

Open and Hold Stock Status Attributes

The PeopleSoft system does not need to track on-hand quantity balances at the material storage location level because all material movement transactions occur within the WMS. In most cases, quantity balances in the PeopleSoft system can be maintained at the business-unit level by using the Open or Hold stock status attributes to determine which stock is available to fulfill orders. In this balance structure, you can use the PeopleSoft material storage location balance record, PHYSICAL_INV, to maintain the Open and Hold quantity balances. Two storage location balance records are created in PHYSICAL_INV: one for stock quantity with an Open status and another for stock quantity with a Hold status.

When determining whether to use this structure or a more detailed balance structure, take the following considerations into account:

• Material storage locations can have a status of only Open or Hold.

  Inventory status values of Restricted and Rejected are not used in a WMS integration. You should always initiate status updates in the WMS. Status changes made using the Inventory Status page or the Lot Control Information page in PeopleSoft Inventory are not reflected in the WMS and may cause discrepancies between the available (that is, Open) and unavailable (or Hold) quantity balances in the two systems.

• The status update data that the WMS sends to the PeopleSoft system does not directly change the status of stock.

  Instead, the WMS reports a material storage location stock transfer in which the stock is moved to a location with the appropriate status, Open or Hold. The Inventory Transfer EIP (the EIP used to send status update data to PeopleSoft) is designed with the assumption that the Open or Hold status of a material storage location is handled in the WMS mapping logic to support the status update transaction. If the WMS implementation uses the material storage location fields in PeopleSoft Inventory for purposes other than tracking Open and Hold balances, these fields must be accounted for in the mapping logic.

• All key fields related to item definition in the PeopleSoft Inventory material storage location balance table, PHYSICAL_INV, are supported for transactions that allow entry of the item ID.

  These fields include the business unit, item, staged date, lot ID, serial ID, container ID, and unit of measure. If you want to maintain a breakdown of balances at a lower level than the item ID (for example, at the lot ID or serial ID level), all transactions entered against these balances must contain all item definition keys.

• Modifications to the check boxes on the Material Storage Locations page in PeopleSoft Inventory can affect available balances for items in that location.

  Changes made to these settings are not reflected in the WMS and may cause discrepancies in the available and unavailable quantity balances between the two systems.

See Also

Managing Inventory Status

WMS EIPs

The EIPs used to exchange data between the PeopleSoft system and a WMS are service operations defined within PeopleSoft Integration Broker.

The following diagram illustrates the data flow between the WMS and PeopleSoft Inventory, Order Management, Purchasing, and Payables:

The integration between PeopleSoft and the warehouse management system using service operations.

The following sections describe the information that each EIP provides.

PeopleSoft Purchasing

The EIPs within PeopleSoft Purchasing are:

PeopleSoft Order Management and PeopleSoft Inventory

The EIPs within PeopleSoft Order Management and PeopleSoft Inventory are:

Note. If the Inventory business unit is integrated with WMS and uses the return to vendor (RTV) feature in PeopleSoft Purchasing, then you cannot use the Express option for the RTV Inventory Ship Option or the RTV Inventory Destroy Option in PeopleSoft Purchasing. The express option could cause the stock quantities between the PeopleSoft Inventory business unit and the WMS to become out of balance.

Note. In prior releases of PeopleSoft Inventory, the Shipping Notification EIP was used to send back picking and shipping details from the WMS system. The Shipping Notification EIP is available for backwards compatibility to earlier releases. However, if you are currently implementing the integration point between PeopleSoft Inventory and a WMS, use the Inventory Pick Confirm EIP and the Inventory Shipping EIP instead of the Shipping Notification EIP.

PeopleSoft Payables

The EIPs within PeopleSoft Payables are:

PeopleSoft General Ledger

PeopleSoft General Ledger is not directly integrated with the WMS. Instead, it is updated by transactions in PeopleSoft Payables, PeopleSoft Order Management, and PeopleSoft Inventory.

See Also

Understanding PeopleSoft Supply Chain Management Enterprise Integration Points

The Order-to-Cash Business Process in a WMS Integration

The Procure-to-Pay Business Process in a WMS Integration

Four-Wall Warehousing Functions in a WMS Integration

Static Information Updates in a WMS Integration

Managing Inventory Status

Counting Inventory Stock

The Order-to-Cash Business Process in a WMS Integration

This section discusses:

• Order entry.

• Reservation processing.

• Order release processing.

• Order changes.

• Shipping processing.

The order-to-cash business process enables companies to sell their goods and services to customers. Here is an overview of the process in a WMS integration:

1. PeopleSoft components are used to take the customer orders, reserve the orders against available quantity balances, and release the orders to the WMS.

2. In the WMS, the orders are picked, packed, and shipped to the customer.

3. PeopleSoft provides shipment tracking, advanced shipment notice transactions, costing, accounting, invoicing, and cash collection functions.

Order-to-Cash Process Flow in a WMS Integration

The following diagram illustrates the order-to-cash flow between PeopleSoft and a WMS. The PeopleSoft system is the entry point for the order where the stock is then reserved and released to the WMS using the Shipping Order Release service operation. The WMS picks, packs, and ships the order and sends the details back to PeopleSoft using the Inventory Pick Confirm service operation or the Inventory Shipping service operation. PeopleSoft then completes the costing and billing steps:

Order-to-cash process flow between WMS and PeopleSoft

The EIPs that support the order-to-cash business process in a WMS integration are based on a number of assumptions. The following sections detail the assumptions for each phase of the order-to-cash business process.

Order Entry

In a WMS integration, orders are captured and staged for fulfillment in PeopleSoft tables. PeopleSoft Inventory enables you to capture demand for stock from many sources, including sales order entry functions in PeopleSoft Order Management and material stock requests accepted from other PeopleSoft business units and third-party applications.

Regardless of demand source, all orders that are staged for fulfillment in the PeopleSoft Inventory the demand fulfillment table, IN_DEMAND, can be processed in a WMS. However, orders issued with the Creating Express Issue Stock Requests in PeopleSoft Inventory cannot be processed in a WMS. Express issue orders bypass picking, packing, and shipping functions are directly inserted into the PeopleSoft Inventory history table, TRANSACTION_INV.

See Also

Creating Orders for Fulfillment

Understanding Order Fulfillment Processing

Introduction to Sales Order Entry

Reservation Processing

Before the order can be released for picking in a WMS, the demand line must set to the releasable fulfillment state by reservation processing in PeopleSoft Inventory. A demand line can be set to the releasable state with soft-reserve, ATP promise, pre-allocation, or just released downstream for picking. A demand line could be fully or partially backordered by the reservation process.

Pre-allocations

Pre-allocations are a hard allocation of quantity at the material storage location level when orders are in the unfulfilled state. Pre-allocations include hard allocations created by the pegging feature and lot-allocations. In PeopleSoft Inventory, the Order Release Request process is run to generate the Shipping Order Release EIP. This service operation sends the hard allocations to the WMS . If PeopleSoft Inventory receives a transfer transaction for a pre-allocated item from the WMS, the transaction is rejected because allocated material cannot be transferred. Do not use pre-allocation processing if the WMS implementation has procedures that require transferring material from a material storage location to a shipping area before sending data using the Inventory Pick Confirm EIP or the Inventory Shipping EIP.

Back Orders

If back orders are permitted for orders, the back order processing takes place in PeopleSoft Inventory. Back order functionality in the WMS is not used in a WMS integration. If you allow order lines to ship with partial quantities, demand lines with the available portion of the requested quantity are inserted into IN_DEMAND, where they can be released for picking in the WMS.

See Also

Promising and Reserving Inventory

Order Release Processing

In a WMS integration, running the Order Release process in PeopleSoft Inventory releases eligible orders to the WMS to be picked, packed, and shipped. For PeopleSoft Inventory business units under external warehouse control, the Order Release process using the Shipping Order Release output option, sends the order data to the WMS using the Shipping Order Release EIP.

The sort selections available from the Additional Options page of the Order Release process do not control the sequence of the orders in the Shipping Order Release service operation. The order data sent to the WMS is separated into logical orders based on breaks in the following sort sequence:

1. Business unit.

2. Demand source.

3. Source business unit.

4. Order number.

5. Customer ID.

6. Ship to ID.

7. Address sequence code.

8. Carrier ID.

9. Ship via.

Note. If the Ship Using TMS Reference ID check box is selected on the Inventory Definition page then the orders released to the WMS system will be set up and sorted using the TMS Reference ID and TMS Reference ID Line Number.

Note. If the address information for an order is modified before order release, the address fields are added to the sort sequence.

For each logical order, there is a single order header that contains the address and shipping information for the order. The Order Release process assigns an external reference number to the order header. For each Order Release process run, the external reference numbers are assigned to order headers sequentially starting with 1. This number is also referenced on each demand line associated with the order header and can be viewed on the Stock Requests Inquiry page. The combination of the external reference number and the pick batch ID provides a unique key that the WMS uses to identify a specific order release transaction.

The data sent by the Shipping Order Release service operation contains detailed information for each line on the order, including details of quantities allocated to specific items and material storage locations. Lot detail for lot-allocated demand lines is always provided; however, quantity allocation for push picking plans is provided on an optional basis only.

The order release transaction in a WMS integration is the same for both pull and push picking plans. However, if you use a push picking plan (Create Allocations action on the Order Release process page), the quantities are allocated at the material storage location level. If PeopleSoft Inventory receives a transfer transaction for an allocated item from the WMS, the transaction is rejected because allocated material cannot be transferred. Push picking plans should not be used if the WMS implementation has procedures that require transferring material from a material storage location to a shipping area before sending the data using the Inventory Pick Confirm EIP or the Inventory Shipping EIP.

To delete an order line from a pick batch ID, you must manually delete the line in both PeopleSoft Inventory and the WMS. To delete the order line in PeopleSoft Inventory, use the Material Picking Feedback page. (This is the only circumstance in which the Material Picking Feedback page is used in a WMS integration.) If you do not also delete the order line in the WMS system and the line is returned to PeopleSoft Inventory on an Inventory Pick Confirm EIP or an Inventory Shipping EIP, the line is rejected because it is no longer associated with the order.

The Shipping Order Release EIP does not include substitute item detail as provided on picking plans in PeopleSoft Inventory. However, all other notes tied to a picking plan are included in this data. In addition, the Shipping Order Release EIP includes any notes associated with the bill of lading to support WMSs that print their own bills of lading.

See Also

Understanding PeopleSoft Supply Chain Management Enterprise Integration Points

Picking Inventory

Order Changes

In general, once an order is released to the WMS, any changes made to the order in either the WMS or in the PeopleSoft system must be manually communicated between the two systems. The PeopleSoft system does not send any order change information to the WMS. Changes made to the order shipping information in the WMS for the carrier, shipping method, and freight terms are sent to the PeopleSoft system as part of the Inventory Pick Confirm EIP or the Inventory Shipping EIP. Any other order changes made in the WMS, however, must be manually duplicated in the PeopleSoft system.

You can cancel an order line at any time until the order line has the status Shipped in PeopleSoft Inventory. However, in a WMS integration, first cancel the order in the WMS and then cancel the order in the PeopleSoft system using the Cancel/Hold Stock Request page. If an order canceled in PeopleSoft Inventory is actually shipped in the WMS, PeopleSoft Inventory rejects the transactional data from the Inventory Pick Confirm EIP or the Inventory Shipping EIP received from the WMS. You cannot reverse an order cancellation in PeopleSoft Inventory.

See Also

Changing, Canceling, and Holding Orders

Shipping Processing

When the WMS ships an order, it sends shipping information to the PeopleSoft system using the Inventory Shipping EIP. This service operation contains all the information necessary to pick, pack, and ship individual orders in the system tables. In addition to providing basic information, the transaction creates single-level shipping containers and ship serial IDs.

The Inventory Pick Confirm EIP may be used in place of the Inventory Shipping EIP if the actual shipping action will occur in the PeopleSoft system. This EIP provides all information necessary to pick and relieve bin location inventory balances but does not ship orders. Information necessary to create single level shipping containers and ship serial IDs may also be provided on this EIP.

A third alternative for providing shipping information is the Shipping Notification EIP. In prior releases, the Shipping Notification EIP was used to send back picking and shipping details from the WMS system. The Shipping Notification EIP is available for backwards compatibility to earlier releases. However, if you are currently implementing the integration point between PeopleSoft Inventory and a WMS, use the Inventory Pick Confirm or the Inventory Shipping EIP instead of the Shipping Notification EIP.

No matter which of the above three EIPs are used, shipping information overriding carriers, shipping methods and freight terms can be entered on the transactional data if changes were made at shipping time. In addition, a unique Ship ID can be assigned to each shipment coming from the WMS system. However, if the Ship ID is left blank, the system will automatically assign a shipping ID as the order is shipped.

Note. A single release order line cannot be split across two different shipping IDs.

Shipping Notification EIP

The system converts the Shipping Notification EIP to either an Inventory Pick Confirm or Inventory Shipping transaction as thedata is processed by the subscription process assigned to the Shipping Notification EIP. The original Shipping Notification data is written to the transaction log (BCT_CTL and BCT_DTL) in a complete status for audit purposes only. The system also writes the Inventory Pick Confirm or Inventory Shipping transaction data to the transaction log.

The shipping notification EIP includes the shipment header and shipment lines. A shipment designated by a shipment header is defined as a shipment event for a single carrier ID, ship type ID, freight terms value, ship date, ship time, and bill of lading. These field values must be identical for all lines defined for the given instance of a shipment header.

Shipping History and Documentation

PeopleSoft collects and tracks shipping history based on the information from the Inventory Pick Confirm EIP or the Inventory Shipping EIP. If a bill of lading number is sent to PeopleSoft Inventory in the data, the PeopleSoft system updates the demand fulfillment table, IN_DEMAND, for tracking purposes only. A bill of lading is not created in the PeopleSoft system.

In a WMS integration, the required shipping documentation is usually generated using the WMS; however, you can also generate this documentation using PeopleSoft components.

See Also

Understanding PeopleSoft Supply Chain Management Enterprise Integration Points

Entering Picking Feedback Using an Electronic Data Collection System

Shipping Inventory

Understanding Order Fulfillment Processing

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:

1. PeopleSoft components are used to manage stock replenishment, create requisitions and purchase orders, and automatically source and dispatch the purchase orders.

2. When the requested stock on purchase orders arrives, the WMS handles the receiving, inspection, and putaway transactions for the stock.

3. 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 business process flow for procure-to-pay between PeopleSoft and a WMS

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

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

See Also

Understanding Requisitions

Purchase Orders

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

See Also

Understanding Purchase Orders

Purchase Order Expected Receipts Processing

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 receiptstransaction is published when the change event occurs. This includes closing or canceling the purchase order. When the WMS receives a POexpected 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 vendor 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.

See Also

Creating Requisition Lines

Transferring Stock Between Business Units

Receiving

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.

See Also

Receiving and Putting Away Stock

Receiving Shipments

Four-Wall Warehousing Functions in a WMS Integration

This section discusses:

• Inventory adjustments.

• Storage location transfers (inventory status updates).

• Physical inventory (stock quantity snapshots).

Four-wall functions are material management activities bounded by the four walls of a specific warehouse, including performing cycle counts and full physical inventory counts, adjusting quantities for specific material storage locations, replenishing fixed picking locations, and making any other stock transfers between material storage locations. In a WMS integration, all four-wall functions are performed in the WMS and then reported to the PeopleSoft system by using EIPs.

Process Flow for Four-Wall Warehousing Functions in a WMS Integration

The following diagram shows the process flow for four-wall EIPs in a WMS integration. The WMS performs any wall-to-wall inventory counts or cylce counts and then passes the data to PeopleSoft Inventory using the Physical Inventory service operation. The WMS also performs any warehouse transfers or stock adjustments and passes this information to PeopleSoft using the Inventory Transfer service operation and the Physical Inventory service operation:

Four-wall warehousing integration between PeopleSoft and the WMS

The EIPs that support the four-wall functions in a WMS integration are based on a number of assumptions. The following sections detail the assumptions for each function.

Inventory Adjustments

Inventory quantity adjustment transactions are generated from the WMS using the Inventory Adjustment EIP. The inventory adjustment transaction notifies PeopleSoft Inventory of quantity changes required for defective, found, or lost stock. This transaction is a simple quantity adjustment for an item in a particular material storage location.

Distribution types on the adjustment transaction are used for inventory accounting. Some WMSs have charge codes that match up to the distribution type fields. However, if the WMS charge codes differ from the distribution types established in PeopleSoft Inventory on the Distribution Type page, the WMS charge codes must be converted to match the PeopleSoft distribution types when the transactional data is mapped. If the distribution type field is left blank, the PeopleSoft system uses the default distribution type established for the selected adjustment type on the Default Distribution Type page.

Note. ChartField overrides are not permitted for adjustment transactions.

Storage Location Transfers (Inventory Status Updates)

To notify PeopleSoft Inventory of material transfers between material storage locations, the WMS generates inventory transfer data using the Inventory Transfer EIP. In a typical WMS integration in which quantity balances are tracked only at the business unit level in the PeopleSoft system, the inventory transfer data sent to the PeopleSoft system change the status of the stock to Open or Hold. In PeopleSoft Inventory, two storage locations are defined in the PHYSICAL_INV table: one for quantity with an Open status and another for quantity with a Hold status. Inventory status change transactions originating from the WMS must be translated to map to the EIP by identifying the Open and Hold locations that are used in the PeopleSoft system.

Physical Inventory (Stock Quantity Snapshots)

To synchronize quantity balances between the two systems, the WMS uses the Physical Inventory EIP to send PeopleSoft Inventory a stock quantity snapshot transaction that reflects the current stock quantity balances for the business unit. In PeopleSoft Inventory, this data is processed as a physical inventory transaction. You can use the quantity balances in this inbound data to run a reconciliation report and stock quantity update process, just as you would for a cycle or physical count performed for an PeopleSoft Inventory business unit that is not integrated with a WMS.

Because the success of the WMS integration relies on synchronous quantity balances between the two systems, a quantity balance synchronization procedure should be performed as often as feasible.

Synchronizing Quantity Balances

Here are steps for synchronizing quantity balances between PeopleSoft Inventory and a WMS:

1. In the WMS, perform a counting event and use the Physical Inventory EIP to send PeopleSoft Inventory a transaction that reflects the current quantity count.

   A counting event can be for all items in the WMS or for a specific item, lot, or material storage location. Each stock quantity snapshot includes header information for the counting event and lines detailing the count quantity and material storage location information for each item counted. When the data is received, PeopleSoft Inventory loads the counting event data into the electronic data collection transaction tables.

   Note. The data sent using the Physical Inventory EIP is used to perform periodic checks of the quantity balance synchronization between the two systems. There is no expectation that an actual cycle count or physical inventory count has occurred in the WMS. The Physical Inventory EIP is not used to communicate quantity balance changes from a physical inventory or cycle counts in the WMS. In these cases, the WMS sends PeopleSoft Inventory an adjustment using the Inventory Adjustments EIP.

2. Run the Physical Inventory process (INPIPHYS) to move the counting event data to the count table (COUNT_INV) in PeopleSoft Inventory.

   Set up run control parameters for the Physical Inventory Load process on the Physical Inventory Process page under the SCM Integrations menu.

3. Run the Physical Accounting Reconciliation report to detect any discrepancies between the two systems.

   Set up run control parameters for the Physical Accounting Reconciliation report on the Reconciliation Report page. If you find a discrepancy and do not want to accept the adjustment, you can use the Item Counts page to change the status of the counting event line to exclude it from the Stock Quantity Update process (INPOPOST).

4. Run the Stock Quantity Update process to update the quantities in PeopleSoft Inventory.

   Set up run control parameters for the Stock Quantity Update process on the Stock Quantity Update Process page.

See Also

Counting Inventory Stock

Static Information Updates in a WMS Integration

This section discusses:

• Customer data.

• Vendor data.

• Item data.

• Carrier and shipping method data.

• Location data.

Static information includes data about customers, vendors, items, carriers, and locations. In a WMS integration, all static information is maintained in the PeopleSoft system and update information is sent to the WMS as necessary. If a change is made to any part of the static information in the PeopleSoft system, even to a field that does not exist on the outbound message, information indicating a change event is sent to the WMS.

Process Flow Static Information Transfers in a WMS Integration

The following diagram shows the process flow for static information transfers between a WMS and PeopleSoft, including customer, vendor, item, carrier, shipping method, and location table data:

Static information transfers in a WMS integration

The EIPs that support the static information updates in a WMS integration are based on a number of assumptions. The following sections detail these assumptions for each static data type.

Customer Data

Using the Customer/Address EIPs, the PeopleSoft system publishes updates for customer-related information to the WMS when a customer record is created, changed, or inactivated. These EIPs includes customer master and address information and may be filtered based on the PeopleSoft setID.

See Also

Maintaining General Customer Information

Vendor Data

Using the Vendor EIP, the PeopleSoft system publishes updates for vendor-related information to the WMS when a vendor record is created, changed, or inactivated. The information may be filtered by the PeopleSoft setID.

See Also

Maintaining Vendor Information

Item Data

Using the Item Master EIP, the PeopleSoft system publishes updates for item-related information to the WMS when an item record is created and set to an approved status, or when changes are made to the item after it has reached an approved status. The data includes item master, item detail, unit of measure, purchasing attributes, business unit attributes, and business unit weight and volume information for approved items only. The item data may be filtered by both the PeopleSoft setID and business unit.

See Also

Defining Items by SetID

Carrier and Shipping Method Data

Using the Carrier/Shipping Method EIP, the PeopleSoft system publishes updates for carrier-related information to the WMS when a carrier record is created or changed. The transaction includes carrier master information and is filtered by the PeopleSoft setID.

See Also

Setting Up Freight Carriers

Location Data

Using the Location Table EIP, the PeopleSoft system publishes updates for location-related information to the WMS when a location record is created or changed. The data includes location master information and is filtered by the PeopleSoft setID. The locations are established on the Location - Location Definition page in the PeopleSoft system to identify the address of an internal location that can receive interunit transfer orders. The WMS uses the location on interunit transfer orders as it would the customer ID on customer sales orders.