Professional Documents
Culture Documents
Distributed WMS White Paper
Distributed WMS White Paper
System
The current Oracle EBS Warehouse Management system (WMS) is an integral part of Oracle
E-Business Suite and hence both the transaction source systems such as Purchasing and
Order Management and execution systems like WMS reside and operate within the same
instance. The main advantage of such an integrated solution is that it eliminates the need for
reference and transaction data integrations, which are needed for a typical ‘bolt-on’ WMS
solution. At the same time it makes it difficult for the customers to implement Oracle EBS
WMS outside the framework of an E-Business solution. This limitation restricts the potential
target markets of Oracle EBS WMS due to the below mentioned reasons:
Facilitate Outsourcing
• How to serve the needs of LSPs for a
warehouse solution that handles complexity
and integration with client systems?
Distributed WMS
WMS for Non-EBS Host WMS instance Ensure High Availability
• How can I use WMS to decoupled from EBS • How to ensure that a
manage my warehouse mission critical
Easily integrate with
with a non-EBS host host system application like WMS
system? is available 24*7?
Streamlined processes
& visibility
A distributed WMS system capable of integrating with the host system enables the
customer to leverage the features available in the latest Oracle EBS WMS release
without having to upgrade the whole application suite.
The distributed WMS deployment is potentially targeted for prospects that are planning to use
Oracle WMS due to any of the above business drivers. The deployment options for WMS
now provide the customers significant flexibility to use WMS in their application landscape.
This Technical Brief documents the solution and also explains in detail the integration
approach with the backend host or ERP system. At a high level it also provides an insight as
to how customers can implement this solution. The target audience for this document are
customer as well as sales and implementation consultants.
Salient Features
Some of the salient features of the Distributed WMS solution include the following
Distributed WMS solution is an independent ERP instance capable of serving multiple
independent warehouses or organizations.
Distributed WMS enables you to integrate with any host system including legacy systems,
other ERP system like SAP etc. or another Oracle ERP system.
Distributed WMS is an independent WMS solution with minimal set up requirements. It
supports all the routine warehouse and inventory functions available in the E-Business
suite today.
Distributed WMS is a pure execution system and does not have any costing or
accounting implications of material transactions. The financial implications of the
transactions are maintained in the host system.
Transaction sources like Sales Orders and Purchase Orders are created in the host
instance and are communicated to the distributed instance. The distributed system
executes the transactions and provides a mechanism to send the confirmations back to
the host system.
Any change management supported for the transaction documents like Sales Order and
Purchase Order in the E-Business Suite today are also supported in the Distributed
system.
Distributed WMS solution provides a mechanism through which any inventory
adjustments or current on hand inventory snap shot can be sent to the host system as
needed.
Distributed WMS is a distributed deployment of WMS. A new profile option ‘WMS:
Deployment Mode’ is provided to identify the instance as distributed.
Minimum licensing requirements are Oracle WMS (enabled for distributed deployment)
with Oracle Inventory, with the minimum WMS user licenses. The customer no longer
needs Order Management, Purchasing or Financials for the distributed instance.
Detailed steps to configure a Distributed WMS instance and its implementation will
be captured in a separate Technical Brief.
Integration
Framework
Integrated but decoupled WMS Instances
The host system will receive the demand from the customers and will procure the raw
material from its suppliers. It will communicate the demand and supply source documents
to the distributed system using the integration framework. After the transactions are
completed in the distributed instance, they will be transmitted to the host system through
the integration layer. The actual steps to configure a distributed instance will be captured
in a separate Technical Brief.
The following process flow diagram depicts the typical flow of documents between a
distributed warehouse, its host system, customers and suppliers.
Invoice Payment
Purchase Order
Sales Order
EDI 856 ASN
Outsourcer O 1
Host System
Receipt Confirmation
Shipment Confirmation
Purchase Order
Shipment Request
Supplier S1 Customer C 1
Supplier Customer
Inventory Adjustments
Reference Data –
Item, Customers,
synchronization
Suppliers etc.
Onhand
EDI 856 ASN
Ship Material
Physical Arrival of Goods
Lightweight Leightweight
Receiving Purchasing Shipping
Order
Management
Figure 3: Process flow involving a distributed system, its host, customers and suppliers.
In the above figure, the warehouse is using Oracle Distributed WMS solution in a distributed
deployment for supply chain execution, while the host system can be Oracle EBS or legacy
system or other ERP system.
In order to better understand these flows, we have classified them into following functional areas
The following figure depicts the steps involved in a typical inbound flow:
Supplier Suppliers
Host
9 Perform receipt,
7 S Dist tanc
close PO &
ER ion eipt
en ribu e
finish payment
to
d g te
at ec
Ins
Create or update
rm d r
oo d
PO
P
nfi en
ds
co 8 S
to
2 Send PO details to
Distributed Instance
1) The ‘Host’ system plans for material and places purchase orders on its
suppliers to ship the material to the warehouse.
2) After the supplier accepts the purchase order, host system is responsible for sending
the information about these purchase orders to the warehouse so that material can be
received against the purchase order in the warehouse.
3) The distributed warehouse system creates purchase orders based on the information
sent by the host.
4) Sometimes, after the supplier finalizes its delivery schedule, it sends an advance
shipment notice (ASN) to the distributed system with information about the details of
the shipment. The ASN can also be sent to the host system which can then send the
information to the distributed system.
5) After the distributed system receives the ASN from the supplier, it can plan its labour
better and make receipts against these ASNs when material arrives.
6) The distributed warehouse imports ASNs based on the information sent by the host.
7) When material arrives, warehouse receives the material against the purchase order
(or the ASN, if ASN information was sent).
8) After material is received, warehouse provides a mechanism through which the host
system can pull the information about the receipt that was made against the purchase
order or the ASN.
9) The host system performs the receipt transactions and updates the account payable
system for the material received.
The following figure depicts the steps involved in a typical outbound flow –
Customer
1 Customer Orders
Customers
Material
Host
5 S Cust
7 Perform
hip om
shipping, close
nt t
P atio en
Create & update SO & finish
go er
o
ER rm ipm
Sales Order invoicing
od
nfi sh
st
co nd
o
2 Send Orders to ship to
e
Distributed Instance via
6S
Shipment Request
Distributed WMS
4 Pick release orders to
prepare for shipping
Warehouse execution
3 Create &
(pick/load/drop/consolidate)
update Orders
Figure 5: Outbound Material Flow in a Distributed Environment
1) Customer places a sales order on the host system to ship goods to an address.
3) The distributed warehouse creates sales orders based on the information sent by the
host system
4) Warehouse releases the orders to the warehouse. Material is packed and deliveries
are consolidated for shipment.
5) The goods are shipped to the customer and an ASN is sent to the Customer.
6) Once the goods are shipped, warehouse provides a mechanism through which host
system can pull the information regarding the shipment transaction.
7) Host system updates its order management system with the shipment information and
updates the accounts receivables for the goods shipped.
5 Send PO (850) to
Instance 2
8 Send receipt
confirmation
(944) to host
4 Send shipment
request (940) to
2 Send shipment
advice (945) to
Instance 1
host
1) Host system creates an internal requisition/internal order to move material from one
warehouse to another warehouse.
2) Host system sends the shipment request to the distributed instance representing the
shipping warehouse. The distributed warehouse creates sales orders based on the
information sent by the host system.
3) The order is released and the material is picked and shipped to the destination
warehouse.
4) A shipment advice is sent to the host system after the material is shipped.
5) An equivalent purchase order is created from the internal order and sent to the
instance representing the receiving warehouse so that it can receive the material.
6) Optionally the shipping instance can also send an ASN message along with the
shipment. The distributed destination warehouse imports ASNs based on the
information sent.
7) When material arrives, receiving warehouse receives the material against the
purchase order (or the ASN, if ASN information was sent).
8) After the material is received, the receiving instance provides a mechanism through
which host system can pull the information regarding the receipt transaction so that
inventory can be updated in the host system and requisition can be closed.
The following figure depicts the steps involved in a typical RMA flow
Customer Customers
1 Customer Calls to
Return Material
Host
Se istri ance
6 Perform receipt,
nd bu
close RMA &
D st
finish payment
In
go ted
ER atio ipt
P n to
Create & update
od
rm ce
RMA
n fi re
st
co end
o
5S
2 Send RMA details to
Distributed Instance
Distributed Instance
1) Customer calls to return material. An RMA is created in the host system to receive it.
2) RMA information from the host system is sent to the distributed system.
3) RMA is created in the distributed system. RMA number is same as in the host system.
4) When the goods are received from the customer, it is received against the RMA.
5) After material is received, warehouse provides a mechanism through which the host
system can pull the information about the receipt that was made against the RMA.
6) The host system performs the receipt transactions and updates account payable
system for the material received.
Manufacturing
Plant Plant
Host
7 Perform receipt
S e w a re
nd ho
to
Ho ati eipt
st on
go use
irm rec
Create & update 3 Create Interorg
- org transfer
Inter
od
Work order
co end
to move material from
st
mfg to DC
nf
o
6S
4 Transform and send- inter org
details to distributed instance
to create equivalent PO
Distributed Instance
Figure 8: Manufacturing to Distribution Center Material Flow
1) Host system creates a work order to produce finished goods. The information is sent
to the manufacturing system.
2) Work order is completed and information is sent back to the host system
3) The host system creates an internal order or inter-org transfer to move the finished
goods from plant to the distributed warehouse.
4) The internal order information is then sent to the distributed system to create an
equivalent purchase order so that material can be received in the warehouse.
5) When the goods are received from the manufacturing plant, it is received against the
PO.
6) After material is received, warehouse provides a mechanism through which the host
system can pull the information about the receipt that was made against the PO.
7) The host system transforms the PO receipt and performs the intransit receipt
transactions and updates the inventory to close the internal order.
In order to execute the above flows, reference data such as item, customers, and
suppliers must be synchronized between the host system and the distributed system. The
host system is the owner of the reference data. The following flows are required between
the host and the distributed system
1) Whenever an item is created or modified in the host system, it sends that information
to the distributed system.
2) The distributed system processes the information and creates or modifies that item.
3) Whenever a vendor (or supplier) is created or modified in the host system, it sends
that information to the distributed system.
4) The distributed system processes this information and creates or modifies that
vendor.
6) The distributed system processes this information and creates or modifies that
customer.
Reference data needs to be synchronized between the host system and the distributed
system so that transactions do not fail due to lack of reference data. In some cases such
as customer data, reference data can also be created while processing the transactions
(sales orders).
3 Solution
This section focuses on the solution and implementation of Oracle Distributed WMS solution for
the distributed warehouse. This assumes that the host system can be another EBS instance,
legacy system, other Oracle or non-oracle ERP system. The following picture describes the
responsibility across host and distributed system for various business functions to enable
Oracle Distributed WMS solution for the distributed warehouse.
Warehouse Transfers Wave & Wave & Count and Labeling &
Functions and Moves Labor Plan Labor Plan Adjustment Value Adds GL Process
Setup &
Master Data Products Customers Vendors Rules Layout
The following section uses the individual flows identified in the earlier section and describes
how they can be fulfilled using Oracle Distributed WMS solution for the distributed warehouse.
The steps involved in implementing information flow between the host system and the
distributed system for material inbound to the warehouse are described below
Populate the
Populate PO interface on
Receiving open
distributed instance
interface.
Distributed WMS
(EBS 12.1)
In the above figure the host is assumed to be EBS 11.5.10 and the distributed system is
EBS 12.1. However the host system can be any other version of EBS, other ERP or
legacy system. Steps described below are applicable only for an EBS host and may
change for a different ERP or legacy system.
Please refer to “Oracle Purchasing Users Guide” for detailed information on how to create
new purchase orders.
The host can pass specific receiving controls such as receipt routing, over receipt
tolerance, receipt days early or late for each PO line. If this information is not passed,
then it will default from the receiving parameters defined in the distributed system for that
organization.
System Integrators are also responsible for keeping the information updated in the
distributed system as the purchase orders are updated or cancelled in the host system.
They will have to call appropriate purchasing public APIs to orchestrate these changes.
After the interface tables have been loaded, the “Import Standard Purchase Order
program” must be run in the Distributed system to import the data from the interface
tables into Oracle Purchasing. The Purchasing Documents Open Interface program
receives the data, derives and defaults any missing data, and validates the data. If no
errors are found in the submission process, the data in the Purchasing Documents Open
Interface tables is loaded into the purchasing base tables to create the standard purchase
order. The purchase order should be created in approved status and should have the
same document number as in the host system.
If the Purchasing Documents Open Interface program finds errors in the interface tables,
the record identification number and the details of the error are written to the
PO_INTERFACE_ERRORS table. You can launch the Purchasing Interface Errors
Report in Purchasing to view the rows that were not imported by the Purchasing
Documents Open Interface along with the failure reason(s) for each row.
The Purchasing Documents Open Interface errors out on a line-by-line basis. This means
that if an error is found in a document line, only that line is rolled back (not submitted to
Purchasing), and you can find the error in the PO_INTERFACE_ERRORS table. The
error records in the interface tables must be updated before the re-run of the import
program. Because the Purchasing Documents Open Interface saves or errors out line by
line, it can accept partial documents. Assumption for importing purchase orders into the
distributed system is that the required reference data such as item, supplier (or vendor),
supplier site, buyer information, UOM, organization, subinventories, locators must already
be set up in the distributed system.
Please refer to “Oracle Purchasing Open Interfaces and APIs manual” for detailed information on
what fields to populate for importing new purchase orders.
Please refer to “Oracle Warehouse Management Users Guide” for detailed information on how to
perform receiving transactions.
Historical information about the receipts made and results of quality inspection etc. are
stored in RCV_TRANSACTIONS (RT) table in Oracle Purchasing. Distributed solution will
provide a view ‘RCV_RECEIPT_CONFIRMATION_V’ which will contain all the detailed
information about the receipt transactions that have been ‘Delivered’. The view contains
information like source document number (PO#), line number, shipment number, item,
quantity received, unit of measure etc. and contains information about the following
transaction types – PO Receipt, Return to Receiving, Corrections, RMA Receipt, Internal
Requisition Intransit Receipt, Inventory Intransit Receipt. Only those transactions which
affect on hand will be retrieved by the view and therefore Return to Receiving will be
played back as Return to Vendor or Return to Customer in the host system based on
source document type.
System Integrators can query this view directly to fetch all the new receipts for which
confirmation has not been sent to the host system. They can then convert this information
into appropriate format to populate the receiving interface tables of the host system. This
can be achieved in either of the following ways –
If the host system is an Oracle E-Business Suite, then the information can be written
directly into the “Receiving Documents Open Interface” of the host system. System
integrator loads the receipt information of distributed system in the receiving interface
tables of the host system. After the receipts have been imported into “Receiving
Documents Open Interface”, one can periodically schedule the “Receiving Transaction
Processor” to process these transactions and create receipts in the host system.
Please refer to “Oracle Purchasing Open Interfaces and APIs manual” for detailed information on
how to make use of “Receiving Documents Open Interface” to update receipt information in the
host system.
Please refer to “Oracle Purchasing Open Interfaces and APIs manual” for detailed
information on how to invoke purchase order change and cancellation APIs.
Import ASNs
Supplier sends the ASNs to the distributed system. One can import ASNs into Oracle
Distributed WMS by passing the data in the form of ASC X12 856 EDI or its equivalent
XML transaction. For the EDI/XML import to successfully go through suppliers and
supplier sites should be defined as trading partners and Oracle e-Commerce Gateway
should be appropriately set up. After all the setups are complete, one can run the Oracle
e-Commerce Gateway import program to process the transactions. Supplier can also
send the ASNs to the host system from where they can be imported into the Distributed
System by a variety of methods – iSupplier Portal, EDI, or XML.
If the required data is not provided in the transaction, the Oracle e-Commerce Gateway
import process fails the transaction and an exception message is displayed in the View
Staged Documents window. If the trading partner is valid and the transaction is enabled,
the import process proceeds to validate the transaction using the user-defined column
rules. If no process or column rule exceptions are detected, the Oracle e-Commerce
Gateway import program will write the transaction to the “Receiving Open Interface”
tables to be processed by the Receiving Open Interface API. The system integrators can
also write the ASN information in the “Receiving Open Interface” tables directly using the
public APIs. To successfully import ASNs into Oracle Purchasing, one must run the
“Receiving Transaction Manager”.
Please refer to “E-commerce PO Implementation guide” for detail information on how to import
new ASNs.
The Purchase Order window can also be utilized to manually create a purchase order in
the distributed system when the integration layer is down and receipt advice cannot be
sent or received. The purchase order number in the distributed system should be same
as purchase order number in the host system.
Reverse Logistics
Distributed system users can perform a ‘Return to Receiving’ transaction to initiate a
return to vendor. After the ‘Return to Receiving’ transaction is completed in the distributed
system, the goods will move from inventory to receiving and on hand will get
decremented. The Receipt Confirmation view will pick these transactions and once the
host interface tables are updated, the Return to Vendor transaction will be created in the
host system even if the distributed system has performed only Return to Receiving
transaction. This is necessary for inventory synchronization.
If for some reason, distributed system decides to put the material back into inventory
(Deliver transaction), then a correction against the Return to Vendor transaction needs to
be done in the host system and a deliver transaction should be created.
Assumptions – Some of the key assumptions for the inbound flow described above are
summarized again:
1) All the required reference data must be created in advance in the distributed system
before purchase order is sent.
2) There should be one to one mapping of purchase orders between the host and
distributed system i.e. for every PO in the host system, a corresponding PO will be
created in the distributed system.
3) The purchase order in the distributed system should be created in approved status
and its number should be same as purchase order number in the host system.
4) If the host system requires specific receiving controls on a given PO line, then the
receiving controls must be passed to the distributed system along with the PO
information. Otherwise system will default the receiving controls from the Receiving
Parameters defined in the distributed system. For simplicity it is recommended that
receipt routing for PO in the host system be ‘Direct Delivery’ while it can be ‘Standard’
or ‘Inspection Required’ in the distributed system based on the requirements.
The steps involved in implementing information flow between the host system and the
distributed system for material outbound from the warehouse are described below -
Generate shipment
Process shipment advice
batches.
Transfer shipment
request to distributed Import shipment advice
instance.
WMS (EBS 12.1)
Distributed
Process shipment
Pick and stage
request to create Ship material
material
shipment
Please refer to Distributed WMS technical Implementation step Out of the box
brief for more details on implementation steps.
In the above figure the host is assumed to be EBS 11.5.10 and the distributed system is
EBS 12.1. However the host system can be any other version of EBS, other ERP or
legacy system. Steps described below are applicable only for an EBS host and may
change for a different ERP or legacy system.
Customers can transfer the shipment data from the host system to distributed system and
shipment advice from distributed system to the host system using any of the following
ways –
1) Using Oracle Data Integrator (ODI) – Customers can configure the ODI maps to send
shipment request to the distributed system and process the shipment advice
extracted from the distributed system.
2) Using Oracle Open Interfaces and Public Application Programming Interfaces (APIs) -
To insert shipment data into interface tables of the distributed system and to process
the shipment advice extracted from the distributed system.
3) Using XML Gateway - Oracle XML gateway can be configured to insert the shipment
data passed from host system into shipping interface tables of the distributed system
and invoke appropriate program to process this data.
We will discuss each of these methods for data transfer while describing the steps for the
above flow. We can break down the above flow in the following steps:
Please refer to “Oracle Order Management Users Guide” for detailed information on how
to create new sales orders and ‘Oracle Transportation Execution User’s Guide’ for more
details on ‘Third Party Warehousing’.
The shipment request can be sent to the distributed system in any of the following ways:
• Using ODI maps - Customers can create and configure ODI maps to extract the
data from shipment views and insert into shipping interface tables of the
distributed system. Please refer to Distributed Warehouse Management System
Integrations Technical Brief for more details on how to create and configure
ODI maps.
• Directly populate the data into shipping interface tables on the distributed system
using public APIs
• As an XML message – If distributed instance is configured with Oracle XML
Gateway, customer can generate an XML message for shipment request batches
and post it to XML Gateway. Oracle XML gateway will insert the data into shipping
interface tables in the distributed system and invoke appropriate programs to
process it. This shipment request XML message should be generated based on a
new XML map (WSH_STNDI_OAG721_IN) which has been created based on
OAG 161_show_shipment_005.dtd to process the shipment request received
from the host system.
Please refer to “Oracle XML Gateway manual” for detailed information on how to set up XML
gateway to import shipment into Oracle Shipping Execution.
Alternately if XML gateway is not used then customers can use ODI or create a
concurrent program to fetch the shipment request data from shipment views and directly
populate the information in the shipping interface tables of the distributed system using
the public APIs. After the records are loaded into the shipping interface tables, they can
be processed in any of the following ways –
All the required reference data like customer, ship-to and Bill-to locations, customer
contacts, items, UOMs, ship methods, carriers, freight terms, FOB, organization, sub
inventories and locators must be already set up in the distributed system before the
shipment request is received and processed. If not, the received shipment requests will
error out. However distributed system can create customer, customer addresses and
contacts on the fly if the customer data does not exists in the distributed system and is
sent along with the shipment request.
Any interface error records can be viewed and corrected in the Shipment Message
Corrections UI. After the records are corrected, they can be re-submitted for processing.
After the shipment request is processed successfully, delivery details are created or
modified in the distributed system. Additionally if you use XML gateway to process the
shipment request data then a confirmation Business Object Document (BOD) can be sent
to the host system. The confirmation BOD will be sent to the host system only if the
trading partner is set up to send the confirmation BOD.
The shipment request will contain header and detail level information. The host system
should provide a unique document number (DocumentID in XML schema) in the
shipment request header and a unique document line number
Please refer to “Oracle XML Gateway manual” for detailed information on how to set up XML
gateway to import shipment into Oracle Shipping Execution.
3.2.5 Pick, Pack and Ship Material against Shipment Request in Distributed System
Orders are released, tasks are created, and material is picked, packed, and shipped from
the warehouse for the shipment requests. The host system’s sales order and line number
information is stored in the delivery details in the distributed system. When the shipment
is done from the distributed system, all the shipping documents like packing slip or
customer labels generated, will contain the host system sales order number.
If required, the distributed system can send shipment information to the customer in the
form of EDI 856. This EDI document can be generated in Oracle Distributed System,
once the order has been ship confirmed.
Please refer to “Oracle Warehouse Management User guide” for detailed information on how to
process and ship a sales order using Oracle EBS WMS and refer to “Oracle E-Commerce
Shipping Implementation Guide” for detailed information on how to generate and send ASNs (EDI
856) to the customers.
3.2.6 Generate Shipment Advice XML Message in the Distributed System (If using XML
Gateway)
Shipment advice can be generated in the distributed system as an XML message when
XML gateway is used. XML shipment advice message can be generated using XML
transaction Shipment_Advice which is equivalent to EDI transaction 945 outbound.
Oracle XML gateway must be installed to generate the XML messages. A new XML map
(WSH_STNDO_OAG721_OUT) has been created based on OAG
161_show_shipment_005 dtd to generate the shipment advice from the distributed
system. The distributed system organization must be defined as trading partner and
transaction must be enabled in XML gateway for generating the shipment advice.
A shipment advice will contain information like the document number received in the
shipment request, item, quantity, customer, ship to address etc. Shipment advice can be
generated once the delivery is in Closed or In-transit status in the distributed system. The
distributed system can initiate the XML shipment advice in either of the following ways –
• Using the Send Outbound Message action in the Shipment Transaction Form
(Navigation: Shipping Transaction form > Delivery tab > Actions > Send
Outbound Message > Select Send Shipment Advice).
shipment confirmation has not been sent and will create a shipment advice for
each of the deliveries shipped.
As an implementation step, system integrator can configure ODI maps or using published
APIs, create a concurrent program to read the shipment advice XML generated by a
distributed system using XML gateway. If XML gateway is not installed, then using the
existing shipping views, implementers can extract the required delivery and delivery
details data from the distributed system. The program should also update the transaction
status to ‘Sent’ in WSH_TRANSACTIONS_HISTORY table in the distributed system. The
shipment advice data should be populated in the shipping interface of the host system.
The shipment advice data can be populated in the shipping interface of the host system
using a new public API WSH_SHIPMENT_ADVICE_PUB.Shipment_Advice.
The above process assumes that the organization in the host system is Distributed
organization. This will enable to directly create and ship confirm the delivery without
having to call the APIs to reserve and pick release the delivery in the host system, which
otherwise can be a significant overhead in terms of processing the transactions.
You must ensure that on hand quantities are synchronized between the host and
distributed system before you playback the shipment advice in the host system. For
simplicity, negative balances can be allowed in the organization in the host system and a
negative balance will be an indicator or warning that the inventory has not been
synchronized between the two systems. If negative balances are not allowed in the
organization and sufficient inventory is not available, it will error out the shipment process
in the host system and on hand balances must be synchronized before transactions are
re-processed. After the sales orders are shipped in the host system, it can generate
invoices for the fulfilled orders.
Please refer to “Oracle Order Management Open Interfaces, APIs and Electronic Messaging
guide” for detailed information on how to use interface and APIs to update shipment information in
the host system.
Reservations - If the host system would like the distributed system to ship specific
material (lot) from a specific location then it can be done in either of the following ways -
• They can pass this information in the shipment request XML. When the orders are
pick released in the distributed system, inventory will honour this information when
move orders/tasks are created.
• Directly populate the reservation information into the reservation interface tables
of the distributed system. The reservation information should contain a reference
to the shipment request number and other mandatory inventory details like lot
numbers, location etc.
If item is serial controlled item, then reservations can only be created through the
reservations interfaces in the distributed system.
Sales Order Visibility and Status – The distributed system will allow the users to query
the sales order created against the shipment request sent by the host system using the
Sales Order and Order Organizer form. Distributed system can provide the information to
the host system using the host system’s shipment request number. The shipment request
number of the host is the sales order number in the distributed system. The distributed
system can also provide the status of an order based on host system’s sales order
number and sales order line number using the Shipping Transaction Form. Host system’
sales order number and sales order line number will be stored as reference number and
reference line number in the delivery details of the distributed system and will be
available in the shipment transaction form as query parameters.
The Sales order form can also be utilized to manually create a sales order in the
distributed system when the integration layer is down and shipment request can not be
sent or received. However it is recommended not to create orders manually in the
distributed system unless it is very critical since data will need to be reconciled between
manually created order in the distributed system and shipment request data generated in
the host, when systems are back up and running. This reconciliation might require
significant effort and update of data in the distributed and host system.
Please refer to Distributed WMS Technical Brief (Technical Implementation) on details of the
data elements which needs to be reconciled and other details
If the host system has modified or cancelled the shipment request (sales order/delivery)
after it has been sent to the distributed system, such changes can also be communicated
as an XML message using the XML gateway. When the XML message is received the
distributed system will verify if the document number already exists. If there are multiple
shipment requests for a given document number then the document number with the
latest or maximum revision will be processed and workflow for the previous revisions will
be closed. A shipment request can be cancelled provided none of the delivery details are
already ship confirmed.
If the host system is an EBS system and the organization is a Distributed organization,
then in order to reduce an order line quantity, the quantity should first be reduced in the
distributed system. Then, the WSH_SHIPMENT_BATCH_PUB.Cancel_Line public api
can be used to unassign the reduced quantity from the shipment request. Thereafter, the
order line quantity can be reduced in the host system.
Please refer to “Oracle Order Management Open Interfaces, APIs and Electronic Messaging
guide” for detailed information on how to process the shipping interface data.
For more details please refer to EBS Release 12.1 documentation on Oracle Metalink
(www.metalink.oracle.com).
Assumptions – Some of the key assumptions for the outbound flow described above are
summarized again –
1) All the required reference data must be created in advance in the distributed system
before shipment request is sent.
2) The organization in the host system is a Distributed organization.
3) The lines identified for shipment in the host system must be in ‘Ready to Release’ line
status.
4) The shipment request number sent to the distributed system must be a unique
number.
5) The SO lines for the shipment request in the host system will be identified and
extracted using a seeded concurrent program based on criteria like customer,
schedule ship dates etc. The resulting lines will be grouped by Customer, Bill-to
location, Ship-to location, Freight terms and FOB. Each group will represent one
shipment request and must be identified by a unique number.
6) If the host system wants the distributed system to ship specific material (lot) from a
specific location, they can provide the information in the shipment request XML.
However
- For serial controlled items, reservation interface needs to be used.
- Separate lines need to be created for each lot or locator. If for example
host system wants to ship 5 different lots for the same SO line, then each
lot has to be sent separately in the shipment request XML. This means
there will be 5 delivery lines (1 for each lot) created in the distributed
system each referring to same SO and SO line of the host system.
7) On hand balances must be synchronized between the two systems before the
shipment advice data is imported and played back in the host system.
Internal orders can be mapped using the inbound and outbound flows described in the
section 3.1 and 3.2. The following figure provides an overview of the steps involved in
internal material transfer process.
Process the
Process receipt
shipment advice transactions
Transfer shipment request to
standalone shipping instance.
Transform shipment request
into equivalent PO and Populate the
Import shipment
populate PO interface on receiving open
advice
standalone receiving instance. interface
Distributed Shipping
Instance (EBS 12.1)
Process shipment
request to create
shipment
Ship material to
Pick and stage receiving Close shipment
material instance and request
generate DSNO
Optional Flow
Distributed Receiving
Instance (EBS12.1)
In the above figure the host is assumed to be EBS 11.5.10 and the distributed system is
EBS 12.1. However the host system can be any other version of EBS, other ERP or
legacy system. The steps described below are applicable only for an EBS host and may
change for a different ERP or legacy system.
The internal transfer process can be achieved using a combination of outbound and
inbound flow described in earlier sections. This flow assumes that both the shipping and
receiving organization are on a separate distributed instance.
We can break down the internal order flow in the following steps:
1) Create and approve internal requisition/internal order in the host system.
2) Run ‘Create Shipment Batches for Fulfillment’ concurrent program to extract the internal
order lines from the host system and create shipment request.
3) Using ODI maps or published APIs insert the shipment request into shipping interface
tables of distributed shipping instance. Transform and Insert the internal order data into
purchasing interface tables of the distributed receiving instance to create an equivalent
purchase order.
4) Import shipment request and ship confirm the material from distributed shipping instance.
5) Use ODI maps or using published APIs create and schedule a concurrent program to
import shipment confirmation data from distributed shipping system and ship confirm the
corresponding internal order lines in the host instance
6) Import and process purchase order in the distributed receiving instance.
7) Receive the material in the distributed receiving instance.
8) Use ODI maps or using published APIs, create and schedule a concurrent program to
import and transform the PO receipt information from distributed receiving instance and
receive corresponding intransit shipment lines in the host system
Please refer to “Oracle Purchasing Users Guide” for detailed information on how to create internal
sales orders.
Please refer to the Outbound Material Flow section 3.2.2 for more details on how to
create shipment request and insert the data into distributed system.
3.3.3 Transfer Shipment Request to Distributed Shipping Instance and Purchase Order
Data to Receiving Distributed Instance
The shipment request can be inserted into shipping interface tables of the shipping
distributed instance using any of the following ways:
The shipment data from the host system should also be converted to populate the PO
interface tables of the distributed instance representing receiving organization to create
an equivalent purchase order. The purchase order number in the distributed receiving
instance should be same as internal requisition number in the host system to maintain the
reference between two systems. The shipping organization must be defined as a supplier
in the distributed receiving instance to facilitate the creation of PO. Please refer to the
inbound flow section 3.1.2 to get more details on the steps to send PO information to a
distributed system.
3.3.4 Import Shipment Request and Ship Material from Distributed Shipping Instance
Shipment request data can be imported using XML gateway (if installed) or by directly
populating the shipping interface tables of the distributed shipping instance. Once the
interface data is populated, users can run the ‘Process Shipment Requests’ program or
use public APIs to process the data. For more details please refer to Outbound Material
Flow section 3.2.4. To facilitate creation of sales order in shipping distributed instance,
the receiving organization must be defined as a customer.
Orders are released, tasks are created, and material is picked, packed, and shipped from
the warehouse to the destination organization. Optionally the shipping instance can also
send an ASN to the receiving organization.
Please refer to “Oracle Warehouse Management User guide” for detailed information on how to
process and ship a sales order using Oracle EBS WMS and refer to “Oracle E-Commerce
Shipping Implementation Guide” for detailed information on how to generate and send ASNs (EDI
856) to the customers.
• Create a concurrent program to read the shipment advice generated (if using XML
gateway) by shipping instance else the shipment data can be extracted from the
existing shipping views. The data should then be inserted into shipping interface
tables of the host system.
• Using ODI maps. Please refer to Distributed Warehouse Management System
Technical Brief (Integrations) for more details on how to create and configure
ODI maps.
After the data is loaded into the shipping interface tables of the host system, it can be
processed by scheduling the standard concurrent program which will create and ship
confirm the deliveries. For more details please refer to the Outbound Material Flow
section 3.2.7 and 3.2.8
Please refer to “Oracle Purchasing Open Interfaces and APIs manual” for detailed information on
what fields to populate for importing new purchase orders.
Please refer to “Oracle Warehouse Management Users Guide” for detailed information on how to
perform receiving transactions.
3.3.8 Populate Receiving Interface and Process Receipt Confirmation in Host System
As an implementation step, system integrators can query the Receipt Confirmation view
directly to fetch all the new receipts for which confirmation has not been sent to the host
system. They will then need to convert the PO receipt of the receiving instance into an
equivalent internal requisition receipt and insert the data into receiving interface tables of
the host system. This can be done using the dummy supplier setup as explained in step
3.3.3 so that any PO receipts of this supplier can be separated from normal PO receipt
and converted into internal requisition receipt.
The data can be sent from the receiving instance to the host system using any of the
following ways–
The host system should process the receipt information obtained from the distributed
system and update its inventory records so that the internal requisition or order can be
closed.
For more details on how to receive and process receipt information in the host system,
please refer to Inbound Material Flow section 3.1.5 and 3.1.6.
corresponding ISO number and order type in the host system and insert the records
in the interface table of the host system against the host ISO number.
5) The host system should run the standard program to process the shipment. For an
internal order this program should not validate the data against the shipment request.
Instead it should be validated against the internal requisition and internal order in the
host system.
6) After the material reaches the destination, the receiving organization will receive the
material against the internal requisition. The internal requisition intransit receipt
information can then be extracted using the receipt confirmation view from the
distributed system.
7) Using the published APIs, the system integrator can insert the data into receiving
interface tables of the host system.
8) Process the receipt transaction in the host system to update the inventory and close
the internal requisition.
If the host system decides to update the ISO after the requisition data has been sent to
the distributed instance, then the ISO and IR in the distributed system should be first
cancelled. The changes can be made in the host system and IR data should be sent
again to the distributed system.
Assumptions – Some of the key assumptions for the internal order flow described above
are summarized again:
1) All the required reference data must be created in advance in the distributed system
before purchase order is sent.
2) It is assumed that operating unit is same in the host and distributed system since
combination of operating unit and internal requisition number will be unique..
3) The purchase order number in the distributed receiving system should be same as
internal requisition number in the host system to maintain the reference between two
systems.
4) The customer should ensure that PO number sequence should not conflict with the
sequence for internal requisition of host as internal requisition number of host will
become PO number in the receiving instance. Document number entry method can
be set as Manual so that PO can be set programmatically to be same as internal
requisition number of the host system.
Process interface
Receive and Putaway
records to create
the material
RMA
Please refer to Distributed WMS technical Implementation Step Out of the box
brief for more details on implementation steps.
In the above figure the host is assumed to be EBS 11.5.10 and the distributed system is
EBS 12.1. However the host system can be any other version of EBS, other ERP or
legacy system. The steps described below are applicable only for an EBS host and may
change for a different ERP or legacy system.
Please refer to “Oracle Order Management Implementation Guide” for detailed information on how
to create RMAs.
• Create and schedule a concurrent program which will extract the RMA data from
the host system and populate the interface tables on distributed system.
• Using Oracle Data Integrator (ODI). For more details on how to create and
configure an ODI map, please refer to Distributed WMS Integrations Technical Brief.
Please refer to “Oracle Order Management Open Interfaces and APIs manual” for detailed
information on how to import orders into Oracle Order management.
Please refer to “Oracle Warehouse Management Users Guide” for detailed information on how to
perform RMA receiving transactions
3.4.5 Extract RMA Receipt Data from Distributed and Import into Host System
The system integrator can query all the RMA receipts from the Receipt Confirmation view
(‘RCV_RECEIPT_CONFIRMATION_V’) for which confirmation has not been sent to the host
system. They can then convert this information into appropriate format to populate the
receiving interface tables of the host system. This can be achieved in either of the
following ways –
has been sent. For more details on how to utilize Receipt Confirmation view please refer
to Inbound Material Flow section 3.1.5.
Assumptions – Some of the assumptions for the above flow are re-summarized:
1) All the required reference data must be created in advance in the distributed system
before the RMA is sent.
2) There will be one-to-one mapping of RMAs between host and distributed system i.e.
for every RMA in the host system, a corresponding RMA will be created in the
distributed system.
3) The RMA number in the distributed system should be same as RMA number in the
host system.
A. The manufacturing plant may operate on a legacy system while planning and
other functions are maintained in a central ERP or host system. Warehouse is
a separate organization using the Oracle Distributed WMS solution and after
the finished goods are manufactured in the plant, they are transferred to
warehouse or DC. The warehouse may also store raw materials and supply it
to the manufacturing plant.
B. When the finished goods are manufactured and stored in a dedicated storage
area for finished goods (subinventory within same organization or a separate
warehouse). In such a case customer might want to upgrade the storage area
to Oracle Distributed WMS so that they can utilize the latest features of the
EBS WMS and will need a mechanism to bring the finished goods inventory
into Oracle Distributed WMS system.
warehouse/DC
Process the
receipt
transactions
Receive and
Process PO interface putaway the
record to create PO product from
manufacturing
Please refer to Distributed WMS technical brief Implementation Step Out of the box
for more details on implementation steps.
The figure above displays how manufacturing to DC material flow can be mapped for
scenario A. In the figure the host is assumed to be EBS 11.5.10 and the distributed
system is EBS 12.1. However the host system can be any other version of EBS, other
ERP or legacy system.
Please refer to “Oracle Work in Process Users Guide” for detailed information on how to create job
orders.
3.5.3 Transform Intransit Shipment into Equivalent PO and Populate PO Interface Tables
of Distributed System.
As an implementation step, the system integrator needs to convert the inter org transfer
shipment data into an equivalent purchase order against which distributed warehouse
can receive the finished goods when it is received from the manufacturing plant. This can
be achieved by:
The data will be inserted into purchasing interface tables of the distributed system. The
PO number should be same as the intransit shipment number to maintain the reference
between the two systems.
Please refer to “Oracle Warehouse Management Users Guide” for detailed information on how to
perform receiving transactions.
• Using ODI Maps - For more details on how to create and configure an ODI map,
please refer to Distributed WMS Integrations Technical Brief
• Using published APIs - System integrator can create and schedule a concurrent
request to extract the receipt data from distributed system and insert into receiving
interface tables of the host system.
The host system should process the receipt information obtained from the distributed
system and update its inventory. Also the program distinguishes these PO receipts from
other supplier PO receipts which will be processed as PO receipts in the host system.
You can use the supplier to distinguish the receipts which are done for finished goods
received from the plant. These receipts will be played back as intransit shipment receipt
in the host system. For this you can either create a dummy supplier or setup plant as a
supplier. Any PO receipts queried from the view against this dummy supplier will then be
played back as intransit shipment receipt in the host system.
2. The distributed instance might perform an alias issue to issue out the raw
materials which should be imported as an internal order or intransit shipment
in the host system. Please refer to Internal Material Transfer Process flow
section 3.3 to get more details on how to create and process an internal order
to move material in a distributed scenario.
Assumptions – Some of the key assumptions for the manufacturing to DC material flow
described above are summarized again –
1) All the required reference data must be created in advance in the distributed system
before shipment request is sent.
2) The PO number in the receiving instance is same as the intransit shipment number of
the host system.
3) The manufacturing plant must be defined as supplier in the distributed system.
The view extracts the information for all the adjustment transactions for which
confirmation has not been sent. As an implementation step, system integrators will need
to extract the adjustment information from this view and transform it to populate the
material transaction interface (MTI) table in the host system. This can be done by either
of the following ways:
• Using ODI Maps - For more details on how to create and configure an ODI map,
please refer to Distributed WMS Integrations Technical Brief
• System integrator can create and schedule a concurrent request to extract the
adjustment data from distributed system and insert into interface tables of the host
system.
For simplicity, it is recommended that the host system creates an alias receipt or issues
against the adjustments done in the distributed system, e.g. creating an alias
issue/receipt for cycle count or physical inventory adjustments in warehouse. For greater
control and visibility, the host system can also have a one to one mapping of the
adjustment transactions e.g. populating the cycle count interface of the host with cycle
count adjustments done in warehouse and then processing these interface records.
Inventory Adjustments
Process the
Host System
adjustment
transactions
Populate adjustment
information into material
transaction interface
Distributed WMS
Perform adjustment
transactions e.g. cycle
count adjustment
If the on hand balances between the two systems are not same then users need to make
sure that all the receipt and shipment confirmations have been sent to the host along with
any adjustments transactions. If the discrepancies still persist then they might need to
compare the transactions history between the two systems and take appropriate actions
for the missing transactions.
Customers can use Oracle Data Integrator (ODI) for all data related integrations i.e. to
synchronize the reference data as well as transactional data like purchase and sales
order from the host system to distributed and receipt confirmations and shipment advices
from the distributed to host system. ODI can be used as data transfer tool because:
• ODI is designed for migrating and transforming data across database instances
• ODI has the ability to migrate data across different database technologies. This
means distributed instance and ERP do not need to be of identical Applications
version or RDBMS release.
• ODI has the ability to directly invoke web services if the customer wants to bypass the
open interface and perform the transactions in real time.
• ODI has a journalizing capability that discovers which transaction records are new.
This must be used to facilitate incremental synchronization.
For more details on ODI mappings and configurations in Oracle Distributed WMS, please
refer to Oracle Distributed WMS Integrations Technical Brief.
Host System
Use Oracle
B2B or Integration ODI or Create program to extract item,
Layer
supplier and customer data from the host system and
insert into Oracle Distributed WMS open interfaces
APIs
Oracle Distributed
WMS System
Figure 16: Overview of Reference Data Transfer from Legacy System to Oracle
Distributed WMS
When items are imported through the item open interface in distributed system, it can
create new item in item master organization, update existing item, or assign existing item
to additional organizations. You can specify values for all the item attributes, or you can
specify just a few attributes and let the remainder default or remain null. The Item
Interface also enables you to import revision details, including past and future revisions
and effectivity dates.
System Integrators must extract item information from the host system and insert the
records into the item and item category interface tables of distributed system. After you
load item, revision, and item category assignment records into these interface tables, you
can run the Item Interface program to import the data. The item interface assigns defaults
to missing data, validates the data, and imports the new items or modifies existing items.
For ease and simplicity, it is recommended to define the items as plain item and maintain
inventory at aggregate (subinventory) level in the host system while maintain specific
inventory controls such as lot or serial control for the item in the distributed system. In
certain scenarios, if the host system wants to maintain the exact details then the item and
location controls can be same in the host and distributed system. .
Please refer to “Oracle Inventory’s Open Interfaces and APIs manual” for information on
how to use “Item Open Interfaces” to update item information in distributed system.
Please refer to “Oracle Payable’s Open Interfaces and APIs manual” for detailed
information on how to use “Supplier Open Interface” to update Supplier information.
The distributed system requires mechanism to query the shipment requests and purchase
orders sent by the host system. For this, users in distributed system will have access to the
Order Organizer, Sales Order, Purchase Order Summary and Purchase Order forms.
Order Management
What is Supported
• Users can query the shipment request sent by the host system and its current
status using the shipment request number. The shipment request number is the
sales order number in the distributed system. They can also query the shipment
requests using other criteria such as customer, order date, ship to etc.
• Users can use the Sales Order form to manually create and book a sales order in
the distributed system when the integration layer is down and shipment request
cannot be sent or received. This enables the warehouse to create and process
orders which are critical.
• Users can pick release the booked sales order, perform pick and ship confirm the
delivery.
What is supported:
• No accounting or costing implications of the transactions performed in the
distributed system.
• Distributed system does not support advanced pricing.
• Users cannot invoice for the sales order created in a distributed system. These will
be a ship only sales order.
• Data reconciliation between manually created SO and actual shipment request
must be performed when system is up and running. It is not recommended to
create sales order manually in the distributed system as data reconciliation effort
could be significant.
Purchasing
What is Supported
• Users can query the purchase orders sent by the host system. The purchase order
number in the distributed system should be the same as purchase order number in
the host system. Purchase orders can also be queried using other criteria such as
supplier, item, ship to location etc.
• Users can use the Purchase Order form to manually create and approve a
purchase order in the distributed system when the integration layer is down and
purchase orders cannot be sent or received.
• Perform the receipts against the manually created purchase orders in the
distributed system.
What is supported:
• No accounting or costing implications of the transactions performed in the
distributed system.
• Users cannot initiate the Payables for the receipts performed in distributed system.
• Data reconciliation between manually created purchase order and actual purchase
order is not as high as in case of order management. Distributed system must
ensure that purchase order number in the distributed system is same as in the host
system.
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com