WMS White Paper

Standalone Warehouse Management
System
(Architecture and Solution Overview)
An Oracle White Paper
April 2009
TABLE OF CONTENTS
1 STANDALONE WMS SOLUTION THE NEED...................................................................4
SALIENT FEATURES ............................................................................................................................5
2 ARCHITECTURE AND BUSINESS FLOWS..........................................................................5
2.1 INBOUND MATERIAL FLOW ............................................................................................................7
2.2 OUTBOUND MATERIAL FLOW .........................................................................................................9
2.3 INTERNAL MATERIAL TRANSFER FLOW .........................................................................................10
2.4 RETURN MATERIAL AUTHORIZATION (RMA).................................................................................11
2.5 MANUFACTURING TO DISTRIBUTION CENTER MATERIAL FLOW..........................................................12
2.6 INVENTORY MANAGEMENT...........................................................................................................13
2.7 SYNCHRONIZATION OF REFERENCE DATA........................................................................................13
3 SOLUTION ...............................................................................................................................14
3.1 INBOUND MATERIAL FLOW...........................................................................................................14
3.1.1 Create and Approve PO in Host System........................................................................15
3.1.2 Populate PO Interface on Standalone Instance.............................................................16
3.1.3 Process Interface Data to Create PO in Standalone System..........................................16
3.1.4 Receipt of Material in the Warehouse...........................................................................17
3.1.5 Populate Receiving Open Interface in the Host System.................................................17
3.1.6 Process Receipt Information in Host System.................................................................18
3.1.7 Other Considerations ...................................................................................................18
3.2 OUTBOUND MATERIAL FLOW........................................................................................................21
3.2.1 Create and Book Sales Order in Host System................................................................22
3.2.2 Run Concurrent Program to Generate Shipment Batches.............................................22
3.2.3 Transfer Shipment Request to Standalone System.........................................................22
3.2.4 Process Shipment Request in Standalone System..........................................................23
3.2.5 Pick, Pack and Ship Material against Shipment Request in Standalone System............24
3.2.6 Generate Shipment Advice XML Message in the Standalone System (If using XML
Gateway)................................................................................................................................24
3.2.7 Import Shipment Advice in the Host System..................................................................25
3.2.8 Process Shipment Advice in the Host System.................................................................25
3.3 INTERNAL MATERIAL TRANSFER ...................................................................................................28
3.3.1 Create and Approve Internal Requisition/Internal Orders in Host System....................29
3.3.2 Run Concurrent Program to Generate Shipment Batches ............................................29
3.3.3 Transfer Shipment Request to Standalone Shipping Instance and Purchase Order Data
to Receiving Standalone Instance...........................................................................................29
3.3.4 Import Shipment Request and Ship Material from Standalone Shipping Instance.........30
3.3.5 Import and Process Shipment Advice in the Host System..............................................30
3.3.6 Import and Process PO in Standalone Receiving Instance............................................30
3.3.7 Receipt of Material in the Receiving Warehouse...........................................................31
3.3.8 Populate Receiving Interface and Process Receipt Confirmation in Host System.........31
3.4 RETURN MATERIAL AUTHORIZATION (RMA).................................................................................33
3.4.1 Create and Book RMA in Host System...........................................................................34
3.4.2 Populate Order Interface on Standalone System...........................................................34
Oracle Corporation
Confidential
Page 2 of 46
3.4.3 Process Interface Data to Create RMA in Standalone System.......................................34

3.4.5 Extract RMA Receipt Data from Standalone and Import into Host System...................34
3.4.6 Process RMA Receipt in the Host System......................................................................35
3.5 MANUFACTURING TO DISTRIBUTION CENTER MATERIAL FLOW..........................................................36
3.5.1 Create and Approve Job order in Host System..............................................................38
3.5.2 Create and Approve Internal Orders/Intransit Shipment in Host System......................38
3.5.3 Schedule Concurrent Program to Extract Shipment Data.............................................38
3.5.4 Transform Shipment Request to Equivalent PO and Populate PO Interface Tables of
Standalone System..................................................................................................................38
3.5.5 Import and Process PO in Standalone System...............................................................38
3.5.7 Import Receipt Confirmation in Host System.................................................................38
3.6 INVENTORY MANAGEMENT...........................................................................................................40
3.6.1 Inventory Adjustments...................................................................................................40
3.6.2 On Hand Balances.........................................................................................................42
3.7 SYNCHRONIZATION OF REFERENCE DATA .......................................................................................42
3.7.1 Import Item Information................................................................................................44
3.7.2 Import Supplier Information..........................................................................................44
3.7.3 Import Customer Information........................................................................................44
3.8 SALES ORDER AND PURCHASE ORDER MANAGEMENT ....................................................................45
Oracle Corporation
Confidential
Page 3 of 46
Oracle Standalone WMS Solution
1 Standalone WMS Solution The Need

The current Oracle EBS Warehouse Management System (WMS) is an integral part of
Oracle E-Business Suite and hence both the transaction source systems like 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 increasingly 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
soluti on that handles complexity and integration
with client systems ?
Standalone WMS
WMS - a wedge product

How can I use WMS to
manage my warehouse without
Oracle E - Business Suite host
system ?
WMS
instance
WMS
instance
decoupledfrom
fromERP
ERP
decoupled
Easilyintegrate
integrate with
with
Easily
host
system
anyany
host
system
Ensure high availability

How to ensure that a mission
critical application like WMS is
available 24*7?
Streamlinedprocesses
processes &&
Streamlined
visibility
visibility
Leverage best-in -class features

How can I use the features in the latest WMS
release without upgrading the whole application
suite?
Figure 1: Need for a Standalone WMS Solution

Customers or prospects who are considering a long-term transition to Oracle Supply
Chain, but who currently operate with (some) existing legacy transaction systems, will
tend to prefer a bolt-on WMS solution due to its integration flexibility. If a bolt-on solution
secures this business prior to full adoption of the suite, then it is likely that the WMS
component of the suite will be lost forever. This means that an Oracle EBS WMS
implementation can only be considered as an upgrade in an existing Oracle E-business
Suite implementation or when all of the transaction and execution systems are replaced
in a big bang. It cannot be used as a wedge product. This is a particularly severe problem
as many customers are looking to logistics and execution-based projects as preferred
investment areas due to their more immediate ROI.
Business like Logistics Service Providers (LSP) have thin transaction source system
requirements, but who integrate with a variety of transaction sources, will look for
simplicity of operation and setup, and so will tend to prefer bolt-ons.
There are customers who prefer to de-couple the execution systems from their main
ERP system so that mission critical applications like WMS are available 24 by 7 even
when the central ERP or host system is down for maintenance or other reasons.
Oracle Corporation
Confidential
Page 4 of 46

A standalone system capable of integrating with the host system will allow the customer
to leverage the best-in-class features of the latest Oracle EBS WMS release without
having to upgrade the whole application suite.
This white paper is an attempt to document and explain the EBS Standalone WMS solution
Oracle is planning to build, which will operate in a distributed environment. This is potentially
targeted for prospects that are inclined to have a bolt-on WMS solution instead of complete
transition to Oracle E-Business Suite. At a high level it also provides an insight as to how
customers can implement this solution. The target audience for this document is sales and
implementation consultants.
Salient Features
Some of the salient features of the Standalone WMS solution
Standalone WMS solution will be an independent ERP instance capable of serving
multiple independent warehouses or organizations.
Standalone WMS will be able to integrate with any host system including legacy systems,
other ERP system like SAP etc. or another Oracle ERP system.
Standalone system will be independent WMS solution with minimal set up requirements.
It will support all the routine warehouse and inventory functions available in the EBusiness suite today.
Standalone system will be a pure execution system and will not have any costing or
accounting implications of material transactions. The financial implications of the
transactions will be maintained in the host system.
Transaction sources like Sales Orders and Purchase Orders will be created in the host
instance and will be communicated to the standalone instance. The standalone system
will execute the transactions and provide 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 will also be supported in the Standalone
system.
Standalone WMS solution will provide a mechanism through which any inventory
adjustments or current on hand inventory snap shot can be sent to the host system as
needed.
A new profile option WMS: Deployment Mode will be provided to identify the instance as
standalone.
Detailed steps to configure a standalone WMS instance and its implementation will be
captured in a separate white paper.
2 Architecture and Business Flows

A typical business with the need for a standalone WMS solution will have a central ERP
system which will be responsible for planning, procurement, demand management and
Oracle Corporation
Confidential
Page 5 of 46

maintaining financial, HR and reference data. The warehouses or the organizations will
operate on a standalone instance and will be responsible for execution of transactions
like receipts and shipments. Oracle standalone WMS solution will communicate with any
host system through an integration framework to accomplish these transactions as shown
in the figure below
Host System (EBS or Non-EBS)

Order
Management
Procurement
``
Financial
s
Master Data
Management
Integration
Framewor
k
Integrated but decoupled WMS Instances
Raw
Material
Warehouse
Finished
Goods
Warehouse`
Distribution Center 1 Distribution Center 2
Figure 2: Standalone and Host System Integration

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 standalone system using the integration framework. Once the transactions are
completed in the standalone instance, they will be transmitted to the host system through
the integration layer. The actual steps to configure a standalone instance will be captured
in a separate white paper.
Below process flow diagram depicts the typical flow of documents between a distributed
warehouse, its host system, customers and suppliers.
Oracle Corporation
Confidential
Page 6 of 46

Payment
Invoice
Payment
Invoice For Goods
Purchase Order
Sales Order
EDI 856 ASN
Receiving
Lightweight
Purchasing
Inventory
Leightweight
Order
Management
WMS
EDI 856 ASN
Standalone Logistics
Customer C1
Customer
Ship Material
Shipment Confirmation
Shipment Request
Inventory Adjustments
Reference Data
Item, Customers,
Suppliers etc.
Onhand
synchronization
Receipt Confirmation
EDI 856 ASN
Physical Arrival of Goods
Supplier S1
Supplier
Purchase Order
Outsourcer O 1
Host System
Shipping
OTM
Figure 3: Process Flow involving a standalone system, its host, customers and suppliers.
In the above figure, distributed warehouse is using Oracle Standalone WMS solution for supply
chain execution, while the host system can be any of the following legacy system, other ERP
system, other best of breed solutions, or another Oracle ERP system.
In order to better understand these flows, lets classify them into following functional areas
2.1
Inbound Material Flow

The figure below depicts the steps involved in a typical inbound flow
Oracle Corporation
Confidential
Page 7 of 46
Supplier
9 Perform receipt,
close P O &
finish paym ent
8
co Send
nfi re
rm ce
ERation ipt
P to
2 Send PO details to
Standalone Instance
to
ds
goo one
end dal
7 S Stan tance
Ins
Create & update

PO
4 Send ASN to buyer

5 Forward to
Standalone Instance
1 Send PO details
to Supplier`
ER P
S uppliers
Standalone Instance
3 C reate &
update P O
6 C reate AS N on W arehouse execution

top of the P O (receipt/inspect/put
-aw ay)
N ote- Steps 4,5,6 are optional. O ne can receive

ectly
diragainst a PO w ithout getting a ASN
Figure 4: Inbound Material Flow in a Distributed Environment

1) The Host system plans for material and places purchase orders on its
suppliers to ship the material to the warehouse.
2) Once the supplier accepts the purchase order, host system is responsible to send the
information about these purchase orders to the warehouse so that material can be
received against the purchase order in the warehouse.
3) The standalone 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 standalone 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 standalone system.
5) Once the standalone system receives the ASN from the supplier, it can plan its labour
better and make receipts against these ASNs when material arrives.
6) The standalone warehouse imports ASNs based on the information sent by the host.
7) When material shows up at its door, warehouse receives the material against the
purchase order (or the ASN, if ASN information was sent).
8) After material is received, warehouse will provide a mechanism through which the
host system can pull the information about the receipt that was made against the
purchase order or the ASN.
Oracle Corporation
Confidential
Page 8 of 46

9)
2.2
The host system performs the receipt transactions and updates its account payable
system for the material received.
Outbound Material Flow

The figure below depicts the steps involved in a typical outbound flow
C ustom er
Create & u pdate

Sales O rder
2 Send O rders to ship to
S tandalone In stance via
S hipm ent A dvice (940)
3 C reate &
u pdate O rders
6S
co end s
nfi hi
rm pm
ERation ent
P to
ERP
to
ds ASN
g oo nd
hip / Se
5 Somer
st
Cu
1 Customer Orders
Material
C usto m ers
7 Perform
shipp ing , close
S O & finish
in vo icin g
4 Pick release orders to

prep are for shipp in g
W arehou se executio n
(pick/load/dro p/conso lidate)
Standalone Instance
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.
2) Host system performs sourcing optimization and determines that it needs to
ship the goods from this warehouse to the customer. Host system sends down
Shipment Request that can have information about one or more sales orders, to the
warehouse.
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 its accounts receivables for the goods shipped.
Oracle Corporation
Confidential
Page 9 of 46
2.3
Internal Material Transfer Flow

The figure below depicts the steps involved in an Internal Material Transfer flow assuming
the shipping and receiving warehouse are on separate standalone instances. This can be
achieved using the outbound and inbound flow described above
1 Create internal requisition/
internal order
8 Send receipt
confirmation
(944) to ERP
2 Send shipment
request (940) to
Instance 1
4 Send shipment
advice (945) to
ERP
5 Send PO (850) to
Instance 2
ERP
Create & update

purchase
order
Create & update

sales order
3 Warehouse
execution
(Pick/pack/Ship)
Standalone Instance 1
Step 6 is optional -
6 Ship Material
to instance 2
with
DSNO/ASN
Create ASN
on top of the
PO
7 Warehouse execution
(receipt/inspect/put
- away)
Standalone Instance 2
One can receive directly against a PO without getting a ASN
Figure 6: Internal Material Transfer Flow in a Distributed Environment

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 standalone 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, material is picked and shipped to the destination warehouse.
4) A shipment advice is sent to the host system once 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 standalone destination warehouse imports ASNs based on the
information sent.
7) When material shows up at its door, receiving warehouse receives the material
against the purchase order (or the ASN, if ASN information was sent).
8)
Once the material is received, the receiving instance will provide 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.
Oracle Corporation
Confidential
Page 10 of 46
2.4
Return Material Authorization (RMA)

The figure below depicts the steps involved in a typical RMA flow
Customers
o
st
od
go ne
nd alo
Se tand nce
S s ta
In
Create & update

RMA
2 Send RMA details to
Standalone Instance
3 Create & update RMA

from RMA Information
co 5 S
nf en
irm d
r
ER atio e ce
n t ipt
P
o
ERP
1 Customer Calls to
Return Material
Customer
6 Perform receipt ,
close RMA &
finish payment
away)
Standalone Instance
Figure 7: Return Material Authorization Flow in a Distributed Environment

1) Customer calls to return material and an RMA is created in the host system to receive
it.
2) RMA information from the host system is sent to the standalone system.
3) RMA is created in the standalone system. RMA number is same as the host system.
4) When the goods are received from the customer, it is received against the RMA.
RMA.
6) The host system performs the receipt transactions and updates its account payable
system for the material received.
Oracle Corporation
Confidential
Page 11 of 46
2.5
Manufacturing to Distribution Center Material Flow

The figure below depicts the steps involved in a flow of finished goods from a
manufacturing plant to a distribution Center. Manufacturing is either a separate system or
part of the host itself
Manufacturing
Plant
1 Send work order
details to plant
Plant
3 Create Internal
Order/Inter org
transfer to move
finished goods from
plant to warehouse
4 Send internal order details to

create PO in Standalone Instance
Create & update PO from

internal order information
s to
od
go o n e
nd al
S e tand ance
S
t
In s
Create & update

Work order
6
co S en
dr
n fi
ER rm a ece
ipt
P t io
n
to
ERP
2 Complete
Work Order
7 Perform receipt
and close
internal order
away)
Standalone 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 standalone 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 created in above step.
RMA.
7) The host system performs the intransit receipt transactions and updates the inventory
to close the internal order.
Oracle Corporation
Confidential
Page 12 of 46
2.6
Inventory Management
The host system needs to track inventory of material at different warehouses so that it
can plan and source material. This can be achieved if
1) The standalone warehouse management system would provide a mechanism through
which the host system can periodically derive a snapshot of inventory at the
warehouse. The host system can process these snapshots and update its snapshot of
the inventory.
2) Sometimes, inventory may be updated at the warehouse due to a variety of
reasons other than inbound and outbound shipments such as cycle count or
miscellaneous receipts/issues. The standalone warehouse system should be able to
provide a snapshot of these adjustments to the host system so that the inventory is
always synchronized between the standalone warehouse management system and
the host system.
2.7
Synchronization of Reference Data

In order to execute the above flows, reference data such as item, customers, and
suppliers need to be synchronized between the host system and the standalone system.
The host system is the owner of the reference data. The following flows are required
between the host and the standalone system
1) Whenever an item is created or modified in the host system, it should send that
2) The standalone system should process this information and create or modify that
item.
3) Whenever a vendor (or supplier) is created or modified in the host system, it should
send that information to the standalone system.
4) The standalone system should process this information and create or modify that
vendor.
5) Whenever a customer is created or modified in the host system, it should send that
6) The standalone system should process this information and create modify that
customer.
Reference data needs to be synchronized between the host system and the standalone
system so that transactions do not fail due to lack of reference data. In some cases such
as customer data, reference data can be created while processing the transactions (sales
orders) and therefore, in those cases, there may not be a need to synchronize that
reference data before attempting to process the transactions.
Oracle Corporation
Confidential
Page 13 of 46
3 Solution
This section focuses on the solution and implementation of Oracle Standalone WMS solution
for the distributed warehouse. This assumes that the host system can be any of the following
legacy system, other ERP system such as SAP, other best of breed solutions, or another
Oracle ERP system. The following picture describes the responsibility across Host and
Standalone system for various business functions to enable Oracle Standalone WMS solution
for the distributed warehouse.
Outbound
Logistics
Order Entry
Order
Release
Wave
Planning
Pick and
Pack
Ship
Confirm
AR
Process
Inbound
Logistics
Purchase
Order
ASN
Receive
and Inspect
Putaway
and Store
Cross
docking
AP
Process
Warehouse
Functions
Transfers
and Moves
Wave &
Labor Plan
Wave &
Labor Plan
Count and
Adjustment
Labeling &
Value Adds
GL Process
Setup &
Master Data
Products
Host Function
Customers
Vendors
Warehouse Function
Rules
Layout
Joint Function
Figure 9: Business Functions in Standalone and Host System
We will take individual flows identified in the earlier section and see how they can be fulfilled
using Oracle Standalone WMS solution for the distributed warehouse.
3.1
Inbound Material Flow
The steps involved in implementing information flow between the host system and the
standalone system for material inbound to the warehouse are described below
Oracle Corporation
Confidential
Page 14 of 46
Standalone
(EBS 12.1.1)
Host (EBS 11.5.10)
Inbound Process Flow

Initiate payables for
the material received
Create and Approve
Purchase Orders (PO)
Process the receipt

transactions
Populate PO interface on
standalone instance
Populate the
Receiving open
interface.
Process interface data to

create PO
Receive and Putaway

the material
Please refer to Standalone WMS technical white

paper for more details on implementation steps.
Implementation Step
Out of the box
Figure 10: Inbound Process Flow

In the above figures the host is assumed to be EBS 11.5.10 and the standalone system is
EBS 12.1.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.
We can break down the above flow in the following steps
1) Create and approve Purchase Order (PO) in the host system
2) Use Oracle Data Integrator (ODI) maps or using published APIs create and schedule
concurrent program to extract the PO lines to be received from the host system and
insert into interface tables of standalone system.
3) Import and process purchase order in the standalone system.
4) Receive and putaway the material in the warehouse.
5) Use ODI maps or using published APIs create and schedule concurrent program to
import receipt information from standalone system into Receiving Open interface of
the host system.
6) Process receipt transaction in the host system.
7) Initiate payables against the lines received.
3.1.1
Create and Approve PO in Host System

The host system creates and approves the purchase orders. If the host system is an
Oracle EBS system, purchase orders can be created using forms or purchasing open
interfaces.
Please refer to Oracle Purchasing Implementation Guide for detailed information on
how to create new purchase orders.
Oracle Corporation
Confidential
Page 15 of 46

3.1.2
Populate PO Interface on Standalone Instance

The host system is responsible for transmitting purchase order information to the
standalone system. If the host system is an Oracle EBS system, purchase orders can be
transmitted using ASC X12 850/EDIFACT ORDERS or its XML equivalent. Any changes
to purchase orders can be transmitted using ASC X12 860 or its EDI or XML equivalent.
During implementation, systems integrator will need to read or extract these purchase
orders from the host system and populate the PO interface tables in the standalone
system using the Purchasing Document Open Interfaces. This can be achieved by
Creating and scheduling a concurrent program Using published APIs and

processes, the system integrator can create a concurrent program to extract the
PO data from the host system and insert into PO interface of the standalone
system. It should also perform any code conversions as well as mapping required
to populate the interface tables in the standalone system.
Using Oracle Data Integrator (ODI). For more details on how to create and
configure an ODI map, please refer to Standalone WMS Integrations white paper.
The host can pass specific receiving controls like 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 standalone system for that
organization.
System Integrators will also be responsible to keep the information updated in the
standalone 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.
3.1.3
Process Interface Data to Create PO in Standalone System

The Purchasing Documents Open Interface uses Application Program Interfaces (APIs)
to process the data in the Oracle Applications interface tables to ensure that it is valid
before importing it into Oracle Purchasing. New Purchase orders can be imported into
distributed warehouse (operating on standalone WMS solution) by processing information
in the purchasing documents open interface. They cannot be imported through EDI or
XML gateway.
Once the interface tables have been loaded, the Import Standard Purchase Order
program must be run in the Standalone 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 saves or 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
Oracle Corporation
Confidential
Page 16 of 46

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 standalone 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 standalone system.
Please refer to Oracle Purchasing Open Interfaces and APIs manual for detailed information on
what fields to populate for importing new purchase orders.
3.1.4
Receipt of Material in the Warehouse

When material is physically received in the warehouse, it is received against the
purchase order (or the ASN) in the distributed warehouse. Users can configure the put
away rules using WMS rules engine to direct the users to put away the material to
appropriate locations based on the business constraints.
Please refer to Oracle Warehouse Management Users Guide for detailed information on how to
perform receiving transactions.
3.1.5
Populate Receiving Open Interface in the Host System

Once material is received in the warehouse, standalone system will provide a mechanism
such that the host system can update its inventory system with the receipts, procurement
system for the purchase order (or ASN) against which receipt is made, and the accounts
payable for the value of the material received. The host system may also use receipt and
inspection information to monitor supplier compliance.
Historical information about the receipts made and results of quality inspection etc. are
stored in RCV_TRANSACTIONS (RT) table in Oracle Purchasing. Standalone 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 will contain
information like source document number (PO#), line number, shipment number, item,
quantity received, unit of measure etc. and will contain 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
As an implementation step, using published APIs or views create and schedule a

concurrent program or
Create and configure ODI maps. For more details on how to create and configure
an ODI map, please refer to Standalone WMS Integrations white paper.
A new flag RECEIPT_CONFIRMATION_EXTRACTED in the RCV_TRANSACTIONS table has been created,

which can be updated to indicate the status if the receipt confirmation has been sent to
the host system or not. Once the confirmation is successfully sent to the host system, a
new public API will allow the users to update RECEIPT_CONFIRMATION_EXTRACTED flag in the
RT table. Customers can decide and update the flag with the any values which can
indicate any of the following statuses Oracle Corporation
Confidential
Page 17 of 46

NULL Receipt confirmation not sent to the host system
Sent Pending Confirmation Receipt confirmation sent to the host system but awaiting
confirmation from host.
Sent Confirmed - Receipt confirmation successfully received by the host system.
3.1.6
Process Receipt Information in Host System

The host system should process the receipt information obtained from the standalone
system and update its inventory records, procurement system for the purchase order (or
ASN) against which receipt is made, and the accounts payable for the value of the
material received.
If the host system is an Oracle E-Business Suite, then the information can directly be
written into the Receiving Documents Open Interface of the host system. System
integrator should load the receipt information of standalone system in the receiving
interface tables of the host system. Once 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.
how to make use of Receiving Documents Open Interface to update receipt information in the
host system.
3.1.7
Other Considerations
Change Management - Purchase Order Changes and Cancellations
If the host system has modified or cancelled the purchase order after it has been
downloaded in the standalone system, such changes can be transmitted to the
standalone system using the public APIs. All the PO change management supported
currently in the E-Business suite will be supported for the standalone system as well. The
purchase order change API allows you to update quantity, price or promise date on
standard purchase orders or cancel an existing purchase order. These APIs perform all
the necessary validation before updating the changes. The B2B or integration layer will
be responsible for transmitting and populating the change data or calling the appropriate
APIs.
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 will send the ASNs to the standalone system. One can import ASNs into Oracle
Standalone System 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. Once 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 Standalone
System by a variety of methods I-Supplier portal, EDI, or XML.
If the required data is not provided in the transaction, the Oracle e-Commerce Gateway
import process fails the transaction. Then 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
Oracle Corporation
Confidential
Page 18 of 46

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.
Purchase Order Visibility and Status

The standalone system will allow the users to query the purchase orders created against
the receipt advice sent by the host system using the Purchase Order and Purchase Order
summary form. The assumption is that the purchase order will be created in the
standalone system with the same number as the purchase order number in the host
system. So in the standalone system, users can directly query the purchase order using
the host systems purchase order number.
The Purchase order form can also be utilized to manually create a purchase order in the
standalone system when the integration layer is down and receipt advice can not be sent
or received. The purchase order number in the standalone system should be same as
purchase order number in the host system.
Reverse Logistics
Standalone system users can perform a Return to Receiving transaction to initiate a
return to vendor. Once the Return to Receiving transaction is done in the standalone
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 Standalone system has performed only Return to Receiving
transaction. This is necessary for inventory synchronization.
If for some reason, standalone system decides to put the material back into Inventory
(Deliver transaction), then a new receipt transaction will be created in the host system.
Mapping of Job Role, Responsibility and Flow Steps
Table below specifies who would execute the steps mentioned in the flow diagram and
maps it to their job role and application responsibility
Job Role
Responsibility
Order
Entry
clerk/Buyer
System Integrator
Purchasing User
Warehouse
user/receiving clerk
System Integrator
Distributed Warehouse
User
System Administrator
Implementation Step
Create Purchase order and submits for
approval in host system.
Creates the program to extract the purchase
order lines from host system and group them
by PO number. Insert the data into
purchasing interface tables of standalone
system.
Receives the item against the PO created in
the standalone system.
Creates the program to extract the receipt
information from standalone system using
receipt confirmation view and insert into
receiving interface tables of host system
Assumptions Some of the key assumptions for the inbound flow described above are
summarized again
Oracle Corporation
Confidential
Page 19 of 46

1) All the required reference data must be created in advance in the standalone system
before purchase order is sent.
2) There should be one to one mapping of purchase orders between host and
standalone system i.e. for every PO in the host system, a corresponding PO will be
created in the standalone system.
3) The purchase order in the standalone 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 wants specific receiving controls on a given PO line, then the
receiving controls must be passed to the standalone system along with the PO
information. Otherwise system will default the receiving controls from the Receiving
Parameters defined in the standalone 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 standalone system based on the requirements.
Oracle Corporation
Confidential
Page 20 of 46
3.2
Outbound Material Flow

standalone system for material outbound from the warehouse are described below -
Standalone
(EBS 12.1.1)
Host (EBS 11.5.10)
Outbound Process Flow
Create and book Sales

Order.
Invoice for material

shipped
Generate shipment
batches.
Process shipment advice
Transfer shipment
request to standalone
instance.
Import shipment advice
Process shipment
request to create
shipment
Pick and stage

material

Ship material
Implementation step
Out of the box
Figure 11: Outbound Process Flow

In the above figure the host is assumed to be EBS 11.5.10 and the standalone system is
Customers can transfer the shipment data from the host system to standalone system
and shipment advice from standalone system to the host system using any of the
following ways
1) Using Oracle Data Integrator (ODI) (Recommended approach) Customers can
configure the ODI maps to send shipment request to the standalone system and
process the shipment advice extracted from the standalone system.
2) Using Oracle Open Interfaces and Public Application Programming Interfaces (APIs) To insert shipment data into interface tables of the standalone system and to process
the shipment advice extracted from the standalone 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 standalone system
and invoke appropriate program to process this data.
Oracle Corporation
Confidential
Page 21 of 46

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
1) Create and book Sales Order in the host system
2) Run concurrent program Create Shipment Batches to group delivery details into
Shipment Request batches.
3) Transfer and insert shipment batches into interface tables of standalone system.
4) Process shipment request in standalone system.
5) Pick, pack and ship the sales order in the standalone system. For this customer can
use the latest features available in WMS in Oracle 12.1.1 like wave planning,
advanced replenishment to replenish your forward pick area, mobile personalization
to personalize the mobile screens, WMS-OTM integration for dock synchronization
and scheduling, rules engine to configure business rules, advance material status etc.
6) Generate the shipment advice message in the standalone system (If using XML
Gateway)
7) Use ODI maps or schedule published APIs to extract shipment advice data from
standalone system
8) Process shipment advices to ship confirm the corresponding SO lines in the host
system.
9) Create invoice against the fulfilled SO in the host system
3.2.1
Create and Book Sales Order in Host System

The host system creates and books the sales orders for customer order fulfilment. If the
host system is an Oracle EBS system, sales orders can be created using forms, EDI
transactions or Order Import open interface. The organization in the host system should
enable the Distributed Organization flag in Organization parameters which will enable
the Third Party Warehousing (TPW) functionality. This will prevent Orders from getting
Pick Released on the host instance and reduce the efforts (steps) when the shipment
advice is received from the standalone system and played back in the host system.
Please refer to Oracle Order Management Users Guide for detailed information on how
to create new sales orders.
3.2.2
Run Concurrent Program to Generate Shipment Batches

The host system should identify the SO lines to be shipped from standalone warehouse.
Based on the parameters entered, a new concurrent program Create Shipment Batches
will create batches for each group of eligible lines not already assigned to a shipment
batch. These lines will be grouped by customer, bill-to location, ship-to location, freight
terms and FOB. Each group will represent a shipment request and the program will
create a unique number to identify the group. This unique number will be the shipment
request number which will be passed to the standalone system.
3.2.3
Transfer Shipment Request to Standalone System

The shipment request can be sent to the standalone 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
standalone system. Please refer to Standalone Warehouse Management System
Integrations white paper for more details on how to create and configure ODI
maps.
Oracle Corporation
Confidential
Page 22 of 46
Directly populate the data into shipping interface tables on the standalone system
using public APIs
As an XML message If standalone 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 standalone 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.
3.2.4
Process Shipment Request in Standalone System

If the host system sends the shipment request as an XML message then Oracle XML
gateway must be installed and configured on Oracle Standalone system. The standalone
system organizations must be defined as a trading partner within the XML gateway. Once
the XML message is received from the host system, it is parsed in the XML gateway for
format and validity of the information. XML gateway also takes care of any code
conversion and mapping required to populate the shipping interface tables within the
standalone system based on the seeded schema. XML gateway will load data into
interface tables and will trigger shipment request processing
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 standalone system using
the public APIs. Once the records are loaded into the shipping interface tables, they can
be processed in any of the following ways
Using the Process Shipment Requests' concurrent program

Using the public APIs
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 standalone system before the
shipment request is received and processed. If not, the received shipment requests will
error out. However standalone system can create customer, customer addresses and
contacts on the fly if the customer data does not already exist in the standalone system
and is sent in the shipment request.
Any interface error records can be viewed and corrected in the Shipment Message
Corrections UI. Once the records are corrected, they can be re-submitted for processing.
Once the shipment request is processed successfully, delivery details are created or
modified in the standalone 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
(TXN_SRC_LINE_NUMBER in XML schema) for each shipment request line. The
Oracle Corporation
Confidential
Page 23 of 46

shipment request processing will automatically create a sales order in the standalone
system and the sales order number in the standalone system will be same as this
document number. The host system sales order and sales order line number will be
stored as reference number and reference line number attribute in the delivery details of
the standalone system. The standalone system will maintain the reference of the
shipment request number and shipment request line number and use it when sending the
shipment confirmation to 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.
3.2.5
Pick, Pack and Ship Material against Shipment Request in Standalone System
Orders are released, tasks are created, and material is picked, packed, and shipped from
the warehouse for the shipment requests. The host systems sales order and line number
information is stored in the delivery details in the standalone system. When the shipment
is done from the standalone system, all the shipping documents like packing slip or
customer labels generated, will contain the host system sales order number.
If required, the standalone system can send shipment information to the customer in the
form of EDI 856. This EDI document can be generated in Oracle Standalone 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 Standalone System (If using XML
Gateway)
Shipment advice can be generated in the standalone 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 standalone
system. The standalone 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, host SO and line number, item, quantity, customer, ship to address
etc. Shipment advice can be generated once the delivery is in Closed or In-transit status
in the standalone system. The standalone 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).
This can be used if confirmation is to be generated for an individual delivery.
Using the Automated Shipment Request / Shipment Advice concurrent

program for batch processing. Based on the parameters entered in the above
concurrent program, the system will look for all the transactions for which
Oracle Corporation
Confidential
Page 24 of 46

shipment confirmation has not been sent and will create a shipment advice for
each of the deliveries shipped.
3.2.7
Import Shipment Advice in the Host System

Periodically the host system should extract the shipment information from the standalone
system. This is required so that the host system can update its inventory system with the
shipments, Order management system with the sales order shipped, and the accounts
receivables for the value of the material 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
standalone 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 standalone system. The program should also update the transaction
status to Sent in WSH_TRANSACTIONS_HISTORY table in the standalone system.
The shipment advice data should be populated in the shipping interface of the host
system.
3.2.8
Process Shipment Advice in the Host System

Customer can schedule to run a concurrent program which will validate the imported
data. It will then group the lines for each delivery created in the standalone system and
for each delivery it will
-
Create a delivery in the host system using the public APIs.

ship confirm the delivery using public APIs
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
can be a significant overhead in terms of processing the transactions.
You must ensure that on hand quantities are synchronized between the host and
standalone 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. Once 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.
3.2.9
Reservations - If the host system would like the standalone 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 standalone system, inventory will honour this information
when move orders/tasks are created.
Oracle Corporation
Confidential
Page 25 of 46
Directly populate the reservation information into the reservation interface tables
of the standalone 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 standalone system.
Sales Order Visibility and Status The standalone 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. Standalone system can provide the information to
the host system using the host systems shipment request number. The shipment request
number of the host is the sales order number in the standalone system. The standalone
system can also provide the status of an order based on host systems 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 standalone 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
standalone 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
standalone system unless it is very critical since data will need to be reconciled between
manually created order in the standalone 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 standalone and host system.
Please refer to Standalone WMS technical white paper on details of the data elements which
needs to be reconciled and other details
Change Management - Shipment Request Changes or Cancellations

A shipment request can be cancelled or changed in the standalone system by populating
the shipping interface tables with the changed data and processing it using the public
APIs.
If the host system has modified or cancelled the shipment request (sales order/delivery)
after it has been sent to the standalone system, such changes can also be communicated
as an XML message using the XML gateway. When the XML message is received the
standalone 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.
Please refer to Oracle Order Management Open Interfaces, APIs and Electronic Messaging
guide for detailed information on how to process the shipping interface data.
Integration with Oracle Transportation Management (OTM)

The standalone system can integrate with OTM so that customers can plan the trips and
create dock appointments in OTM and send the information back to standalone WMS.
You define the dock doors in WMS and with 12.1.1 you can synchronize the dock door
information between WMS and OTM systems. You can also create deliveries in WMS
and interface the information to OTM using a concurrent request. OTM can then perform
Oracle Corporation
Confidential
Page 26 of 46

transportation planning and schedule a dock appointment. The information is then sent
back to the WMS system to create the trip and dock assignment.
For more details please refer to EBS Release 12.1 documentation on Oracle Metalink
(www.metalink.oracle.com).
Mapping of Job Role, Responsibility and Flow Steps

Table below specifies who would execute the steps mentioned in the flow diagram and
maps it to their job role and application responsibility
Job Role
Responsibility
Order Entry Clerk

System Integrator
Order Entry User

Warehouse Manager
Mana
Warehouse
user/shipping clerk
System Integrator
Management Superuser
User
Implementation Step
Create and Book Sales order in host system.
Creates the program to extract the sales
order lines from host system and group them
based on criteria specified. Insert the data
into interface tables of standalone system if
XML gateway is not used.
Pick release the sales order created in
standalone system.
Pick, pack and ship the material.
Creates the program to extract the shipment
advice information from standalone system
and insert into interface tables of host system
Assumptions Some of the key assumptions for the outbound flow described above are
summarized again
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 i.e. they should not be pick released.
4) The shipment request number generated by the Create Shipment Batches program
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 standalone 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 standalone
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.
Oracle Corporation
Confidential
Page 27 of 46
3.3
Internal Material Transfer

Internal orders can be mapped using the inbound and outbound flows described in the
section 3.1 and 3.2. Figure below provides an overview of the steps involved in internal
material transfer process.
Internal Transfer Process Flow
Standalone
Receiving Instance
Standalone Shipping
Instance
Generate
shipment
batches
Transfer shipment request to

standalone shipping instance.
Transform shipment into
equivalent PO and populate
PO interface on standalone
receiving instance .
Process
shipment advice
Process the
receipt
transactions
Import shipment
advice
Populate the
receiving open
interface
Process shipment
request to create
shipment
Pick and stage

material
Ship material to
receiving
instance and
generate DSNO
Close shipment
request
Optional Flow
Host
Create internal
orders to ship from
shipping instance to
receiving instance
Process interface
data to create PO

Populate receiving
interface with ASN
information..
-- -- -- Optional Flow
Receive and
create ASN
Implementation Step
Receive and
putaway the
products
received
Out of the box
Figure 12: Overview of Internal Material Transfer Process

In the above figures the host is assumed to be EBS 11.5.10 and the standalone system is
Oracle Corporation
Confidential
Page 28 of 46

1)
2)
3)
4)
5)
6)
7)
8)
3.3.1
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 separate standalone instance.
We can break down the internal order flow in the following steps
Create and approve internal requisition/internal order in the host system.
Run Create Shipment Batches concurrent program to extract the internal order lines
from the host system and create shipment request.
Using ODI maps or published APIs insert the shipment request into shipping interface
tables of standalone shipping instance. Insert the internal order data into purchasing
interface tables of the standalone receiving instance to create an equivalent purchase
order.
Import shipment request and ship confirm the material from standalone shipping instance.
Use ODI maps or using published APIs create and schedule a concurrent program to
import shipment confirmation data from standalone shipping system and ship confirm the
corresponding internal order lines in the host instance
Import and process purchase order in the standalone receiving instance.
Receive the material in the standalone receiving instance.
Use ODI maps or using published APIs, create and schedule a concurrent program to
import and transform the PO receipt information from standalone receiving instance and
receive corresponding intransit shipment lines in the host system
Create and Approve Internal Requisition/Internal Orders in Host System
The internal requisition or internal order will be created in the host instance. If the host
system is an Oracle EBS system, internal orders can be created using forms or Order
Import open interfaces.
Please refer to Oracle Purchasing Users Guide for detailed information on how to create internal
sales orders.
3.3.2
Run Concurrent Program to Generate Shipment Batches

The host system should extract the internal order lines to be shipped from shipping
warehouse and create shipment batches by running the Create Shipment Batches
concurrent program.
Please refer to the Outbound Material Flow section 3.2.2 to get more details on how to
create shipment request and insert the data into standalone system.
3.3.3
Transfer Shipment Request to Standalone Shipping Instance and Purchase Order

Data to Receiving Standalone Instance
The shipment request can be inserted into shipping interface tables of the shipping
standalone instance using any of the following ways
Using ODI maps. Please refer to Standalone Warehouse Management System

maps.
Directly populate the data into shipping interface tables within the standalone
shipping instance using public APIs.
If XML gateway is installed then using some XML tool convert the data from
shipping views into XML message and send it to XML gateway.
Oracle Corporation
Confidential
Page 29 of 46

The shipment data from the host system should also be converted to populate the PO
interface tables of the standalone instance representing receiving organization to create
an equivalent purchase order. The purchase order number in the standalone receiving
instance should be kept same as internal sales order number in the host system to
maintain the reference between two systems. The shipping organization must be defined
as a supplier in the standalone receiving instance to facilitate the creation of PO. Please
refer to the inbound flow section 3.2 to get more details on the steps to send PO
information to a standalone system.
3.3.4
Import Shipment Request and Ship Material from Standalone Shipping Instance
Shipment request data can be imported using XML gateway (if installed) or by directly
populating the shipping interface tables of the standalone shipping instance. Once the
interface data is populated, users can run the Process Shipment Request 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 standalone 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.
3.3.5
Import and Process Shipment Advice in the Host System

Periodically the host system should extract the shipment information from the shipping
standalone system. As an implementation step, system integrator can extract the
shipment data from the shipping standalone instance and insert it into shipping interface
tables of the host system in any of the following ways
Using published APIs and views, create a concurrent program to read the
shipment advice generated (if using XML gateway) by shipping instance else the
shipment data 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 Standalone Warehouse Management System
maps.
Once 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
3.3.6
Import and Process PO in Standalone Receiving Instance

Once the interface tables have been loaded as explained in section 3.3.3, the Import
Standard Purchase Order program must be run in the Standalone receiving instance to
import the data from the interface tables into Oracle Purchasing. The Purchasing
Documents Open Interface uses Application Program Interfaces (APIs) to process the
data and create a purchase order. For more details please refer to Inbound Material Flow
Oracle Corporation
Confidential
Page 30 of 46

section 3.1.3. The shipping organization must be defined as a supplier to facilitate the
creation of PO in receiving instance.
what fields to populate for importing new purchase orders
3.3.7
Receipt of Material in the Receiving Warehouse

purchase order (or the ASN). Users can configure the put away rules using WMS rules
engine to direct the users to put away the material to appropriate locations based on the
business constraints.
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 order 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 order receipt.
The data can be sent from the receiving instance to the host system using any of the
following ways

concurrent program which extracts the receipt data from the receiving instance
and populate the interface tables on the host system or
an ODI map, please refer to Standalone WMS Integrations white paper
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.
3.3.9
Multiple Organizations in Single Standalone Instance
The above flow assumed that the shipping and receiving organizations were on separate
standalone instances. Customers can also configure the standalone instance such that
all the warehouses could be on a single standalone instance. In this scenario, the internal
order flow can be mapped easily with host creating the internal order. As an
implementation step, the system integrator can extract the internal requisition data and
populate the requisition interface tables to create an internal requisition in standalone
instance. The internal requisition number in the standalone instance should be same as
in the host system to maintain the reference. You do not need to create an external order
and purchase order as both the shipping and receiving organization are on the same
instance. The shipping organization will ship the material against the internal order and
receiving organization will receive the material against the internal order. The internal
Oracle Corporation
Confidential
Page 31 of 46

order receipt information can then be extracted from the standalone system and inserted
into receiving interface tables of the host system with reference to the internal requisition
so that receipt can be processed and inventory can be updated.
Assumptions Some of the key assumptions for the internal order flow described above
are summarized again
before purchase order is sent.
2) The purchase order number in the standalone receiving system should be same as
internal order number in the host system to maintain the reference between two
systems.
3) Customer should make sure that PO number sequence should not conflict with the
sequence for Internal Sales order of host as internal order 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 order number
of the host system.
Oracle Corporation
Confidential
Page 32 of 46
3.4
Return Material Authorization (RMA)
standalone system for material returned from customer and inbound to the warehouse are
described below
Standalone Host (EBS 11.5.10)

(EBS 12.1.1)
RMA Process Flow

Create and Book Return
Material Authorization
(RMA)
Process the RMA

receipt transactions
Populate order import

interface on standalone
system
Populate the receiving

open interface
Process interface
records to create
RMA
Receive and Putaway

the material

Implementation Step
Out of the box
Figure 13: RMA Process Flow

In the above figure the host is assumed to be EBS 11.5.10 and the standalone system is
We can break down the above flow in the following steps
1) Create and book RMA in the host system
2) Use ODI maps or using published APIs create and schedule concurrent program to
extract the RMA lines to be received from the host system and insert into order
interface of standalone system.
3) Process interface data to create RMA in the standalone system.
4) Receive and putaway the material in the warehouse.
5) Use ODI maps or using published APIs or views, create and schedule a concurrent
program to import receipt information from standalone system
6) Process to receive corresponding RMA lines in the host system.
Oracle Corporation
Confidential
Page 33 of 46

3.4.1
Create and Book RMA in Host System

The host system creates and books the Return Material Authorization (RMA). If the host
system is an Oracle EBS system, RMA can be created using forms or EDI transactions or
order import open interfaces.
Please refer to Oracle Order Management Implementation Guide for detailed information on how
to create RMAs.
3.4.2
Populate Order Interface on Standalone System

As an implementation step, the system integrator will need to extract the RMA data and
insert into the interface tables of the standalone system. For simplicity and reference, the
RMA number in the standalone system should be same as RMA number in the host
system. This can be done in either of following ways
3.4.3
Using the public APIs, create and schedule a concurrent program which will
extract the RMA data from the host system and populate the interface tables on
standalone system.
Using Oracle Data Integrator (ODI). For more details on how to create and
configure an ODI map, please refer to Standalone WMS Integrations white paper.
Process Interface Data to Create RMA in Standalone System

Standalone system can import the RMA information using Order Import open interface.
Order import is an Order Management open interface that consists of open interface
tables and uses a set of APIs to process the data in the interface tables to ensure that it
is valid before importing it into Oracle Order management. Once the data is loaded in the
interface tables, one must schedule the Order Import concurrent program on a periodic
basis to import the data from the interface tables into Oracle Order management. Order
import program validates and defaults any missing data. If the Order Import program finds
errors in the interface tables, it can be corrected using the Order Import Corrections UI.
Please refer to Oracle Order Management Open Interfaces and APIs manual for detailed
information on how to import orders into Oracle Order management.
3.4.4

When material is physically received in the warehouse, it is received against the RMA in
the distributed warehouse. Users can configure the put away rules using WMS rules
engine to direct the users to put away the material to appropriate locations.
perform RMA receiving transactions
3.4.5
Extract RMA Receipt Data from Standalone 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

concurrent program which will extract the RMA receipt data from standalone
system and populate the receiving interface tables on host system or
an ODI map, please refer to Standalone WMS Integrations white paper.
Oracle Corporation
Confidential
Page 34 of 46

RECEIPT_CONFIRMATION_EXTRACTED flag in the RCV_TRANSACTIONS table of standalone system
should be updated using the public APIs for the records for which confirmation has been
sent. For more details on how to utilize Receipt Confirmation view please refer to Inbound
Material Flow section 3.1.5.
3.4.6
Process RMA Receipt in the Host System

Once the receiving interface tables are populated with RMA receipt data, the receipt
information can be processed in the host system. If the host system is an Oracle EBusiness Suite, then the information can directly be written into the Receiving
Documents Open Interface of the host system. System integrator should load the receipt
information of standalone system in the receiving interface tables of the host system.
Once the receipts have been imported into Receiving Documents Open Interface, one
can schedule the Receiving Transaction Processor to process these transactions and
create receipts in the host system.
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 standalone system
before the RMA is sent.
2) There will be one to one mapping of RMAs between host and standalone system i.e.
for every RMA in the host system, a corresponding RMA will be created in the
standalone system.
3) The RMA number in the standalone system should be same as RMA number in the
host system.
Oracle Corporation
Confidential
Page 35 of 46
3.5
Manufacturing to Distribution Center Material Flow

In a typical manufacturing environment, goods are manufactured in the plants and are
stored and distributed through finished goods (FG) warehouses or distribution centers
(DC). The customer demand is fulfilled through these FG warehouses or DC which in
turn drives the planning and production in the plants. This can be modelled in various
ways by the customers
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 standalone WMS solution and once 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 may want to upgrade the storage area
to standalone 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
standalone WMS system.
Oracle Corporation
Confidential
Page 36 of 46
Legacy Mfg
System
Mfg to DC Transfer Process Flow

Process interface
records to create
Work order
Host (EBS 11.5.10)
Populate WIP Interface

on Mfg system
Standalone Instance
(EBS 12.1.1)
Create Job Order
Complete work order

and send goods to
warehouse
Create Internal Order

or intransit shipment
to move goods from
plant to warehouse/
DC
Complete
work order
Process the
receipt
transactions
Generate Shipment
Batches
Transform shipment
request to equivalent
purchase order and
populate PO interface on
standalone instance
Transform PO receipt
into intransit receipt
and populate receiving
open interface.
Process PO interface
record to create PO
Receive and
putaway the
product from
manufacturing

Implementation Step
Out of the box
Figure 14: Overview of Manufacturing to DC Process Flow when Manufacturing operates

on a Legacy System
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 standalone
system is EBS 12.1.1. However the host system can be any other version of EBS, other
ERP or legacy system.
We can break down the flow in the following steps
1) Create and approve Job Order in the host system and send job information to legacy
manufacturing system.
2) Receive job completion information from legacy manufacturing system and create an
internal order/inter org transfer to move material from plant to DC.
3) Run concurrent program Create Shipment Batches to extract the internal order lines
from the host system.
4) Use ODI maps or using published APIs, schedule a concurrent program to convert
into an equivalent PO and insert into receiving interface tables of standalone system.
5) Import and process purchase order in the standalone system.
6) Receive and put away the material in the standalone system.
7) Use ODI maps or using published APIs create and schedule a concurrent program to
import and convert PO receipt information from standalone system into intransit
shipment receipt and receive corresponding shipment lines in the host system
Oracle Corporation
Confidential
Page 37 of 46

3.5.1
Create and Approve Job order in Host System

A manufacturing job order will be created in the host system. If host is an EBS system,
job orders can be created through forms or using WIP open interfaces. The job order is
sent to manufacturing system
Please refer to Oracle Work in Process Users Guide for detailed information on how to create job
orders.
3.5.2
Create and Approve Internal Orders/Intransit Shipment in Host System

When the job is completed in the legacy manufacturing system, the host needs to
complete the job order and create an internal order or inter org transfer to move the
finished goods from plant to warehouse or DC.
3.5.3
Schedule Concurrent Program to Extract Shipment Data

Customers can extract the internal order lines to be shipped by scheduling the Create
Shipment Batches concurrent program. For more details on the program please refer to
section 3.2.2. If the material is transferred using an inter org transfer transaction then the
data can directly be extracted from material transaction table of the host system.
3.5.4
Transform Shipment Request to Equivalent PO and Populate PO Interface Tables

of Standalone System.
As an implementation step, the system integrator will need to convert the shipment or
inter org transfer data into an equivalent purchase order against which standalone
warehouse can receive the finished goods when it is received from the manufacturing
plant. This can be achieved by
Using published APIs/Views - System integrator can create and schedule a

concurrent request to extract shipment data for internal orders or inter org data
from material transaction. The data should then be transformed into an equivalent
purchase order against which standalone system can receive the material.
Using ODI Maps - For more details on how to create and configure an ODI map,
please refer to Standalone WMS Integrations white paper
The data will be inserted into purchasing interface tables of the standalone system. The
PO number should be same as the internal order or intransit shipment number to
maintain the reference between the two systems.
3.5.5
Import and Process PO in Standalone System

Please refer to Inbound Material Flow Section 3.1.3 to get details on how to import and
process PO in a standalone system.
3.5.6

purchase order in the distributed warehouse. Users can configure the put away rules
using WMS rules engine to direct the users to put away the material to appropriate
locations based on the business constraints.
3.5.7
Import 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 standalone instance into an
Oracle Corporation
Confidential
Page 38 of 46

equivalent internal order/intransit shipment receipt and insert the data into receiving
interface tables of the host system. This can be achieved by
Using published APIs - System integrator can create and schedule a concurrent
request to extract the receipt data from standalone system and insert into
receiving interface tables of the host system.
system and update its inventory records so that internal order/intransit shipment can be
closed. Also the program should be able to distinguish 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 internal order receipt or 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 internal order or intransit shipment receipt in the host
system.
3.5.8
1. The standalone warehouse may also store and supply the raw material to the
plant. For this the host will have to create an internal order/ intransit shipment
to move the raw material from DC or warehouse to manufacturing plant. Since
the standalone system will not support any manufacturing transactions, the
plant organization will not be mapped into a standalone instance. The
standalone instance might perform an alias issue to issue out the raw material
which should be imported as an internal order or intransit receipt 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 standalone scenario.
2. For model B described above, if the dedicated storage area is a separate
warehouse then it will be an internal material transfer or inter-org scenario.
Please refer to Internal Material Transfer Process section 3.3 for more details.
3. For model B described above, if the dedicated storage area is a subinventory
within the plant organization, then it will be a subinventory transfer process
where finished goods are transferred to the dedicated subinventory once the
job is completed. As an implementation step, system integrators can create
program to perform Alias or Miscellaneous receipt into the finished goods
subinventory in the standalone system for all the subinventory transfers, which
happen between shop floor and finished goods area in the host system.
Assumptions Some of the key assumptions for the manufacturing to DC material flow
described above are summarized again
before shipment request is sent.
2) The organization in the host system is a Distributed organization.
3) The shipment request number generated by the Create Shipment Batches program
must be a unique number.
4) The PO number in the receiving instance is same as ISO number or intransit
shipment number of the host system.
Oracle Corporation
Confidential
Page 39 of 46

5) The manufacturing plant must be defined as supplier in the standalone system.
3.6
3.6.1
Inventory Management
In case of a distributed (or standalone) warehouse, the host system needs to track
inventory of material at different warehouses so that it can plan and source material.
Apart from receipts and shipments, there are some other processes which can update
inventory in a warehouse. This includes adjustments due to cycle counts, miscellaneous
receipts and miscellaneous issues etc. The warehouse needs to send such inventory
adjustments to the host system. Figure below gives an overview of the steps involved in
synchronizing inventory between the host system and the standalone warehouse system.
The standalone solution will provide a view (MTL_ADJUSTMENT_SYNC_UP_V), which will provide
all the detailed information for the following transactions cycle count and physical
inventory adjustments, miscellaneous issue and receipts, account alias issue and
receipts, sub inventory transfers, move order transactions, staging transfer transactions.
The view will extract 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
Oracle Corporation
Confidential
Page 40 of 46
Using published APIs - System integrator can create and schedule a concurrent
request to extract the adjustment data from standalone system and insert into
interface tables of the host system.
A new flag (TRANSACTION_EXTRACTED) in the MTL_MATERIAL_TRANSACTIONS (MMT) table has been

created, which can be updated using public APIs to indicate the status if the adjustment
confirmation has been sent to the host system or not. Customers can update the flag with
any values which can indicate any of the following statuses
NULL Adjustment confirmation not sent to the host system
Sent But Pending Confirmation Adjustment confirmation sent to the host system but
awaiting confirmation if host system received it successfully or not.
Sent Confirmed - Adjustment confirmation successfully received by the host system.
For simplicity, it is recommended that the host system creates an alias receipt or issues
against the adjustments done in the standalone 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.
In order to maintain a reference of adjustment transactions in the host system, it is
recommended to populate the transaction reference field in Material Transaction Interface
(MTI) of the host system with the transaction ID field of the MMT in the standalone
system for all the adjustment transactions which have been sent and successfully
received in the host system.
Oracle Corporation
Confidential
Page 41 of 46
Standalone
System
Host System
Process the
adjustment
transactions
Populate adjustment
information into material
transaction interface
Perform adjustment
transactions e.g.
Cycle count
adjustment
Please refer to Standalone WMS ODI white

paper for more details on how to use ODIs.
Implementation Step
Out of the box
Figure 15: Overview of Inventory Adjustments Synchronization

3.6.2
On Hand Balances
The host system needs to track accurate on hand balances in the standalone system.
This is required for order fulfilment and planning purposes. The standalone solution will
provide a view MTL_ONHAND_SYNC_UP_V that will provide the details about the on
hand quantity of items like total on hand quantity, lot and serial details, snapshot date etc.
As an implementation step, system integrators can extract the information from this view
and create a report to compare with on hand balances in the host system on a periodic
basis. On hand balance can be in the form of a flat file or XML file depending on the best
method that the host system can make use of. Any mismatch between the host and
standalone will indicate that transactions are not reconciled between the two systems and
can serve as a trigger to initiate the synchronization process.
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.
3.7
Synchronization of Reference Data

In order to execute above flows, reference data such as item, customers, and vendors (or
suppliers) needs to be synchronized between the host system and the standalone
system. Figure below gives an overview of the steps involved in synchronizing reference
data between the host system and the standalone system. It should be noted that the
host system is the owner of reference data.
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
Oracle Corporation
Confidential
Page 42 of 46

order from the host system to standalone and receipt confirmations and shipment advices
from the standalone to host system. ODI can be used as data transfer tool since
ODI is designed for migrating and transforming data across database instances
ODI has the ability to migrate data across different database technologies. This
means standalone 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 needs to be used to facilitate incremental synchronization.
For more details on ODI mappings and configurations in Standalone WMS, please refer
to Standalone WMS Integrations white paper.
Host System
Interface for the host system
Use Oracle
ODI or Create program to extract
B2B or Integration
Layer
item,
supplier and customer data from the host system and
insert into Oracle Standalone WMS open interfaces
Insert records in Oracle

standalone system open interface
Oracle Standalone WMS Open Interfaces

Customer Open
Interface
Item Open Interface
Supplier Open
Interface
APIs
Oracle Standalone
WMS System
Figure 16: Overview of reference data transfer from legacy system to oracle
standalone system
Oracle Corporation
Confidential
Page 43 of 46

3.7.1
Import Item Information

One can import items from any source into Oracle Standalone System using the item
open interfaces. It allows you to convert inventory Items from another inventory system,
migrate assembly and component items from a legacy manufacturing system, convert
purchased items from a custom purchasing system, and import new items from a Product
Data Management package. You can also import item category assignments. This can be
done simultaneously with process of importing items, or as a separate task of importing
item category assignments only.
When items are imported through the item open interface in standalone 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 lets you import revision details, including past and future revisions and
effectivity dates.
System Integrators must extract item information from the host system and inserts the
records into the item and item category interface tables of standalone 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 like lot or serial control for the item in the standalone 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 standalone system. .
Please refer to Oracle Inventorys Open Interfaces and APIs manual for information on
how to use Item Open Interfaces to update item information in standalone system.
3.7.2
Import Supplier Information

One can import suppliers, supplier sites and their contacts into Oracle Standalone
System using the Suppliers open interface. System Integrators must extract the supplier
information from the source system and inserts the records into the supplier interface
tables. After you load supplier, supplier sites, and supplier contact records into the
interface tables, you can run the Suppliers Interface program to import the data. The
Suppliers Interface assigns defaults to missing data, validates the data and then imports
the new suppliers or modifies existing suppliers in the standalone system.
Please refer to Oracle Payables Open Interfaces and APIs manual for detailed
information on how to use Supplier Open Interface to update Supplier information.
3.7.3
Import Customer Information

One can import customers from any source into Oracle Standalone system using the
Customer open Interface. With this interface, you can create new customers or update
existing customers. System Integrators must extract the customer data from the source
system. The data can then be transferred into customer interface tables. Once the import
data is loaded into the interface tables, you can run Customer Interface to validate the
data, default any missing data, and convert it into base customer tables.
Please refer to Oracle Receivables Open Interfaces and APIs manual for detailed
information on how to use Customer Open Interface to create and update Customer
information in the standalone warehouse system.
Oracle Corporation
Confidential
Page 44 of 46
3.8
Sales Order and Purchase Order Management

The standalone system will need a mechanism to query the shipment requests and
purchase orders sent by the host system. For this, users in standalone 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 will be
the sales order number in the standalone system. They can also query the
shipment requests using other criteria like customer, order date, ship to etc.
Users can use the Sales Order form to manually create and book a sales order in
the standalone system when the integration layer is down and shipment request
can not be sent or received. This will allow 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 will not be supported
No accounting or costing implications of the transactions performed in the

standalone system.
Standalone system will not support advanced pricing.
Users cannot invoice for the sales order created in a standalone system. These
will be a ship only sales order.
Data reconciliation between manually created SO and actual shipment request

needs to be done when system is up and running. It is not recommended to create
sales order manually in the standalone 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 standalone system should be the same as purchase order number in
the host system. Purchase orders can also be queried using other criteria like
supplier, item, ship to location etc.
Users can use the Purchase Order form to manually create and approve a
purchase order in the standalone system when the integration layer is down and
purchase orders can not be sent or received.
Perform the receipts against the manually created purchase orders in the
standalone system.
What will not be supported
No accounting or costing implications of the transactions performed in the

standalone system.
Users cannot initiate the Payables for the receipts performed in standalone
system.
Data reconciliation between manually created purchase order and actual

purchase order will not be as high as in case of order management. Standalone
Oracle Corporation
Confidential
Page 45 of 46

system needs to make sure that purchase order number in the standalone system
is same as in the host system.
Oracle Standalone WMS

April 2009
Author: Rahul Mehta (Rahul.Mehta@oracle.com)
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
Oracle Corporation provides the software that powers the Internet.

Oracle is a registered trademark of Oracle Corporation. Various
product and service names referenced herein may be trademarks
of Oracle Corporation. All other product and service names
mentioned may be trademarks of their respective owners.
Copyright 2009 Oracle Corporation
All rights reserved.
Oracle Corporation
Confidential
Page 46 of 46

WMS White Paper

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WMS White Paper

Uploaded by

Copyright:

Available Formats

Standalone Warehouse Management

3.4.3 Process Interface Data to Create RMA in Standalone System.......................................34

Oracle Standalone WMS Solution

1 Standalone WMS Solution The Need

WMS - a wedge product

Ensure high availability

Leverage best-in -class features

Figure 1: Need for a Standalone WMS Solution

Oracle Standalone WMS Solution

2 Architecture and Business Flows

Oracle Standalone WMS Solution

Host System (EBS or Non-EBS)

Distribution Center 1 Distribution Center 2

Figure 2: Standalone and Host System Integration

Oracle Standalone WMS Solution

Invoice For Goods

EDI 856 ASN

EDI 856 ASN

EDI 856 ASN

Physical Arrival of Goods

Inbound Material Flow

Oracle Standalone WMS Solution

Create & update

4 Send ASN to buyer

6 C reate AS N on W arehouse execution

N ote- Steps 4,5,6 are optional. O ne can receive

Figure 4: Inbound Material Flow in a Distributed Environment

Oracle Standalone WMS Solution

Outbound Material Flow

Create & u pdate

4 Pick release orders to

Figure 5: Outbound Material Flow in a Distributed Environment

Oracle Standalone WMS Solution

Internal Material Transfer Flow

Create & update

Create & update

One can receive directly against a PO without getting a ASN

Figure 6: Internal Material Transfer Flow in a Distributed Environment

Oracle Standalone WMS Solution

Return Material Authorization (RMA)

Create & update

3 Create & update RMA

Figure 7: Return Material Authorization Flow in a Distributed Environment

Oracle Standalone WMS Solution

Manufacturing to Distribution Center Material Flow

4 Send internal order details to

Create & update PO from

Create & update

Figure 8: Manufacturing to Distribution Center Material Flow

Oracle Standalone WMS Solution

Synchronization of Reference Data

Oracle Standalone WMS Solution

Figure 9: Business Functions in Standalone and Host System

Inbound Material Flow

Oracle Standalone WMS Solution

Host (EBS 11.5.10)

Inbound Process Flow

Process the receipt

Process interface data to

Receive and Putaway

Please refer to Standalone WMS technical white

Out of the box

Figure 10: Inbound Process Flow

Create and Approve PO in Host System