Implementing Distributed Order Management: An Oracle Topical Essay January 2004 by Tarik Alatovic/Daniel Soosai Manickam

Implementing
Distributed Order Management

An Oracle Topical Essay
January 2004
by Tarik Alatovic/Daniel Soosai Manickam
Implementing Distributed Order Management
Table Of Contents
1. INTRODUCTION .......................................................1
2. BUSINESS CASE ......................................................... 2
3. IMPLEMENTATION .............................................. 4
3.1. Distributed Order Capture................................................................. 5
3.2. Distributed Order Fulfillment ........................................................... 6
3.2.1. Flow: POs To 3rd Party Systems, ASNs Back ........................ 7
3.2.2. Change Management................................................................. 39
3.2.3. Support For Configurations And Kits.................................... 45
3.2.4. Accounting.................................................................................. 46
3.3. Frequently Asked Questions............................................................ 58
3.3.1. Automating Requisition Import PO Approval Flow...... 58
3.3.2. Automating ASN Import Logical Receipt Flow ............. 58
3.3.3. Arrival And Ship Sets................................................................ 58
3.3.4. Item Setup For DOM ............................................................... 58
Distributed Order Management
1. INTRODUCTION
A Distributed Order Management system integrates the fragmented demand and supply
chains to capture demand from all channels, brokers the demand to multiple internal and
external fulfillment systems, and monitors and manages the fulfillment process across the
supply chain. Oracle E-Business Suite fully supports Distributed Order Management.
The benefits of the Distributed Order Management (DOM), the problems it solves, and an
overview of support for DOM in Oracles E-Business Suite are explained in the white paper
titled Distributed Order Management. This topical essay is more detailed and is targeted
towards customers and consultants implementing DOM systems. The document explains the
capabilities Oracle E-Business Suite provides to solve Distributed Order Management
requirements.
Page 1
2. BUSINESS CASE
The promise of a DOM system is that is unifies customer fulfillment process across
companys fragmented systems (ERP systems, legacy systems) and across transactions with
trading partners (Drop Ship, 3PLs, Carriers). The E-Business Suite delivers on this promise
(Figure 1 - DOM architecture).
Figure 1 Oracles Distributed Order Management Architecture
Oracle supports capturing orders from all channels and decomposing them into purchase,
manufacturing, service, and distribution orders. Once an order is decomposed, it can be
fulfilled in a number of ways. Accordingly, fulfillment flows are divided into:
Internal Fulfillment Flows

o
Using Oracle E-Business Suite Modules
Brokering orders to 3rd Party Systems (SAP, Peoplesoft,

Legacy)
External Fulfillment Flows

o
Brokering orders to Trading Partners (Drop Ship, 3PLs, Carriers)
Page 2
Internal fulfillment flows using Oracles E-Business Suite modules are already well
documented, as are external fulfillment flows, such as Drop Ship, where orders are brokered
to trading partners for fulfillment. This topical essay addresses the requirements of a typical
DOM system for internal fulfillment by brokering orders to 3rd Party Systems. The essay
shows how Oracle E-Business Suite framework for drop ship orders can be used to model a
Distributed Order Management flow.
Page 3
3. IMPLEMENTATION
This document focuses on the internal fulfillment flows where orders are brokered to 3rd
Party Systems (SAP, Peoplesoft, Legacy). We first explain how E-Business suite captures
orders from all demand channels. Then, we examine in detail the most common DOM
fulfillment flow where Oracle E-Business instance captures the order, generates a Purchase
Order (PO), sends it for a fulfillment to a 3rd Party System using industry standard XML, and
tracks its progress. Finally, we explain change management features in the DOM fulfillment
flow, support for configurations and kits, accounting issues, and address some frequently
asked questions.
Page 4
3.1. Distributed Order Capture

As shown in Figure 1, E-Business Suite supports capturing orders from all channels. There is
a built-in integration for orders captured through E-Business Suite front-ends Call Center,
iStore, Sales. In addition, the orders may be captured from 3rd Party System front-ends
(Siebel, SAP, legacy) or directly from customers and distributors through either EDI or
OAGI-compliant XML using standard Order Import feature of Oracle Order Management.
The Order Import together with E-Business Suites central repository of all customer and
items (see data layer in Figure 1) enables capturing orders from any channel.
For more information on Order Import and central repository of customers and items, please
refer to Oracle Order Management, Oracle Trading Community Architecture, and Oracle
Inventory documentation.
Page 5
3.2. Distributed Order Fulfillment

In this section, we discuss in detail the most common DOM flow where Oracle E-Business
instance captures the order, generates a Purchase Order (PO), sends it for a fulfillment to a
3rd Party System using industry standard XML, and tracks its progress. The minimum
requirement for these flows is Oracle E-Business Suite 11i.9. In the document, we note
enhancement introduced in 11i.10.
We start the section with a flow that covers capturing an order from a customer and sending it
for fulfillment to a 3rd Party System in the form of a PO. Then, we explain change
management features, support for configurations and kits, and accounting issues.
Page 6
3.2.1. Flow: POs To 3rd Party Systems, ASNs Back

Customers can view order status in Order
Information Portal
Customers can view order status in Order

Information Portal
Customer Order from iStore, Call Center, Sales

Order Pad, EDI/XML, Legacy, 3 rd Party
7'"
Distributed Order Management - the basic flow without ATP and CTP capability
Purchasing
(Core, iSP)
Ord. Mgmt.
(OM, OIP)
Receive the Order.

3
Setup
In Order Information Portal
If the item belongs to one of the 3 rd Party

Applications, then the Source Type of the
line is defaulted to External to make it a
drop ship, based on the Item/Org or Line
based defaulting rules.
PS: We can default the logical Org for
Supplier if needed
y
y
y
1 y
Run the Requisition Import Process. As

a part of this process the correct
Supplier is defaulted based on :
1. Sourcing Rules
2. Blanket Orders
and
3. ASL.
The changes to the Scheduled Ship

Dates from Supplier are made to the
Expected Ship Date of the OIP.
The OE Line Wflow

then completes the INV
txns - a receipt into the
logical Org and a Ship
to Customer, so that
COGs allign up properly
7"
11
10
Create the Purchase Order

y
y
5
On approval the PO is created.

The PO is then communicated
to the Supplier (3 rd party
instance) using EDI, XML,
Email
In iSupplier Portal
The changes to the Scheduled Ship Date
from the Supplier can be made using the
Supplier Change Order functionality.
On receipt of the ASN

or the Shipment
Receipt, purchasing
updates the relevant
PO tables and activates
the OE Line Workflow
9
7'
Model each 3 rd Party Module as a

Separate Supplier - S1, S2
Set up a Validation Organization - VO
Set up items corresponding to these
suppliers in VO
Set up the sourcing rules
Setup Blanket Statements in Purchasing
to create Reqs and POs
6
Purchase Order from Oracle
Applications Instance is received
as a Sales Order in the 3 rd Party
Application.
All the Regular Processing is
done
Any Changes to the Ship Date and

Quantities are made in Supplier
System and then made in the
iSupplier portal
8
On completion of the Sales
Order either a Shipment
Receipt or an ASN is send
to Oracle Applications
Figure 2 Overview Of DOM Flow
The Figure 2 shows the DOM flow where orders are captured from multiple channels and
brokered for fulfillment in a form of a PO to 3rd Party Systems. Note that the flow is
modeled using standard Drop Ship flow of Oracle Order Management. The only difference
is that 3rd Party System is modeled as a supplier.
To demonstrate this flow, we setup two ERP instances (Figure 3):
Central DOM Instance running E-Business Suite
3rd Party System Instance (simulated by running another instance of EBusiness Suite)
Page 7
Figure 3 DOM Flow Steps
The flow consists of 13 steps:

1.
(Central Instance) Create/Import Sales Order
2.
(Central Instance) Import Requisition
3.
(Central Instance) Create Purchase Order
4.
(Central Instance) Approve Purchase Order
5.
(Central Instance) Transmit PO
6.
(3rd Party Instance) Import PO
7.
(3rd Party Instance) Fulfill Purchase Order
8.
(3rd Party Instance) Send ASN
9.
(Central Instance) Import ASN
10. (Central Instance) Perform Logical Receipt Based On ASN

11. (Central Instance) Generate Customer Invoice
12. (Central Instance) Close Order
13. (Customer) Check Order Progress In Order Information Portal
Page 8
Step 1: Create/Import Sales Order

(Central Instance)
The order can be either created through one of E-Business Suite front-ends, or it
can be imported through EDI/XML from customers, distributors, or 3rd Party
Systems. For demo purposes, we create the order using standard Oracle Order
Management UI.
Order quantity 1 of 00 Drop Ship Item on 14-OCT-2003.
Page 9
Note that the source type is External to invoke the OMs Drop Ship flow on which
DOM flow is based.
For items shipped through DOM/Drop Ship flow, the source type can be defaulted
to External by setting organizational item attribute Default SO Source Type to
External (Organization Item window, Order Management Tab). The initial
sequence for defaulting the Source Type is:
Page 10
1.
The organizational item attribute, Default SO Source Type
2.
If the value of Default SO Source Type is NULL, it defaults to Internal
If you do not wish to default a value for the Source Type field for Sales Order Lines,
you must disable the seeded defaulting rules for the order line attribute Source Type.
Order Management seeded constraints will prevent you from making changes to the
Source Type value if the branch on source type workflow activity within the Create
Supply - Line workflow subprocess has completed.
In our example, M1 defaulted as the Receiving Organization where supplier sourcing
rules are defined and where logical receipt is performed once an ASN is received
from the supplier (3rd Party System). M1 is a logical warehouse because it performs
logical receipt of 3rd Party System shipments. Making M1 a separate logical
warehouse isolates the costs of items shipped by the 3rd Party System from the
items that are physically stocked. Order Management does not require the use of a
special shipping organization for 3rd party shipments, but it is recommended to do
so. The logical warehouse should be defined as a shipping org and items shipped
from 3rd Party Systems should be enabled for Drop Ship.
Now, we book the order and examine the workflow of the order line we just created:
The workflow stopped at the Create Supply Line subprocess. The Create Supply
Line subprocess below shows that the workflow proceeded down the Drop Ship
branch because the order line source type was External.
Page 11
Drop ship flow on which DOM flow is based proceeds until the Purchase Release
Deferred activity, which needs to be run by the Workflow Background process. At
customer sites, Workflow Background process should be setup to run in regular time
intervals. In our demo, we manually run the Workflow Background process for the
OM Order Line as shown below.
Step 2: Import Requisition

(Central Instance)
Page 12
In the previous step, the order was created and the order line workflow proceeded
down the Drop Ship flow branch, which in turn created records in Requisitions
interface table (PO_REQUISITIONS_INTERFACE_ALL).
The next step is to import the Requisition from the Requisitions interface table.
Concurrent program Requisition Import needs to be run. At customer sites,
Requisition Import should be setup to run in regular time intervals. In our demo,
we show how to manually run the Requisition Import in the screenshot below.
After Requisition Import concurrent program completes, the Requisition is created

in PO_REQUISITION_HEADERS_ALL and PO_REQUISITION_LINES_ALL
tables. We can find the Requisition number by navigating to Drop Ship Tab of the
Additional Line Information Action as shown below.
Page 13
Note that the supplier Star Gate Ltd, which in our setup represents the 3rd Party
System, defaulted on the Requisition. PO determined the supplier (3rd Party
System) based on the sourcing rules setup for the 00 Drop Ship Item in the logical
DOM organization M1 (see screenshots below).
Page 14
The profile option MRP: Default Sourcing Assignment Set sets the assignment set
used in drop ship / DOM flows. In our demo, we set this profile option to ASETASCP.
Page 15
Step 3: Create Purchase Order

(Central Instance)
The next step after Requisition is imported is to create Purchase Order from the
Requisition. Navigate to Purchasing AutoCreate form and type in the
Requisition number.
After the Requisition is found, creating PO is straightforward as shown below. Note

that the supplier and supplier site (3rd Party System) default from the Requisition.
Page 16
Take note of the addresses that have been defaulted on the PO from the Sales
Order. At the header level, the bill-to and ship-to are the addresses of the company
itself (Central Instance) and not the addresses of the customer (Business World).
However, at the line level the address of the customer is defaulted on the PO.
Page 17
In 11i.10, support for Requisitions and Purchase Orders generated from

DOM/Drop Ship Sales Orders has been significantly enhanced. Following
attributes are now cascaded from the Sales Order to the Requisition and Purchase
Order and are included in XML/EDI PO documents sent to the 3rd Party System:
Ship To Customer Name
Ship To Customer Contact Name
Ship To Customer Contact Phone Number
Ship To Contact Fax Number
Ship To Customer Contact E-mail
Shipping Instructions
Packing Instructions
Shipping Method (= Freight Carrier + Mode of Transport + Service Level)
Customer PO
Customer PO Number
Customer PO Line Number
Customer PO Shipment Number
Customer Item Description
Deliver To Customer Name
Deliver To Customer Address
Deliver To Customer Contact Name
Deliver To Customer Contact Phone Number
Deliver To Customer Contact Fax Number
Deliver To Customer Contact E-mail
Accordingly, 11i.10 features a new Drop Ship tab in the Shipments block of the PO
form (not shown) with the following information: Sales Order Number, Sales Order
Line Number, Sales Order Line Order Quantity, Sales Order Line Shipped Quantity,
Sales Order Line Status, Ship To Customer Name, Ship To Customer Contact. In
addition, new menu option View Sales Order enables users to view Sales Order
information, such as, customer or shipping details, for Purchase Order s that
reference DOM/Drop Ship order lines.
Page 18
Step 4: Approve Purchase Order

(Central Instance)
The next step is to approve the PO (screenshots below). Note that steps 2-4, from
Requisition Import to PO Approval can be automated as explained in section 3.3.1.
Page 19
Step 5: Transmit PO
(Central Instance)
Once the PO is approved, the next step is to transmit the PO document to the 3rd
Party System. PO supports both industry standard XML (OAGI
PROCESS_PO_007) and EDI (850) as delivery mechanisms. For more information
see Oracle XML Gateway Users Guide and Oracle eCommerce Gateway Users
Guide.
Page 20
For demo purposes we chose XML delivery. When XML is chosen as PO delivery
mechanism, the PO starts the Send XML Document Workflow process to deliver
the PO XML document to the 3rd Party System.
The 3rd Party System needs to be setup in the XML Gateway in order to be able to
receive Purchase Orders. Like in the case of the Drop Ship flow, we model the 3rd
Party System as a supplier Star Gate Ltd in the XML Gateway setup (screenshots
below).
Page 21
Excerpts from the generated PO XML are shown below.
Page 22
Page 23
As noted earlier, the ship-to address of the customer is specified at the line level.
However, the unique identifier of the customer site at the line level (PARTNRIDX
field) is not populated in the generated PO XML document. This is a gap in the
current implementation because some 3rd Party Systems may not process the PO
XML correctly if PARTNRIDX field is not populated.
Step 6: Import PO
(3rd Party System)
Page 24
Once the PO XML is sent, the flow continues in the 3rd Party System. The first
step in the 3rd Party System is to import the PO XML document. In our demo, we
used another Oracle instance as the 3rd Party System, and we used standard Oracle
Import feature of Oracle Order Management to import the PO generated in the
central DOM instance. We setup the XML gateway in the 3rd Party System to
receive the XML PO (screenshot below). In SAP, Peoplesoft, or legacy systems,
equivalent XML setups would be needed.
Note that in the 3rd Party System, the central DOM instance is modeled as a
customer Vision Operations.
With the correct XML Gateway setup, Oracle Order Import can import Purchase
Orders as shown in the workflow below.
Page 25
The imported Sales Order can be found in the 3rd Party System by querying for the
PO generated in the central DOM instance.
As specified in the PO XML document, the header level ship-to address is not that
of the end customer Business World, but that of the company in Central Instance
that is modeled as a customer Vision Operations in the 3rd Party Systems.
Page 26
Note that the Order Import incorrectly defaults the ship-to address at the line level
to the address at the header level (screenshot below). As explained earlier, this is
caused by the missing PARTNRIDX field in the generated PO XML document.
This problem needs to be fixed in the Purchasing. Note, however, that other 3rd
Party Systems and future versions of Oracle E-Business Suite may be able to able to
import the PO XML document even if PARTNRIDX field is missing. In this case,
the customer name and the address on the PO XML document should be matched
against the list of existing customers and addresses specified for that customer (this
includes addresses of the end customers if customer relations are setup). If there is a
match with customer only but not with address, then a new address should be
created on the fly for that customer. If there is no match for either customer or the
address, then both customer and address should be created on the fly.
Step 7: Fulfill Purchase Order

(3rd Party System)
Page 27
In this step, 3rd Party System fulfills the order. This may include getting the items
from stock or manufacturing them or any other form of fulfillment. The items on
the order are then shipped to the customer (Business World) and an ASN is sent to
the central DOM instance to inform it of the items shipped.
Step 8: Send ASN

(3rd Party System)
Oracle Purchasing supports several ways for importing ASNs from 3rd Party
Systems: XML, EDI, iSupplier Portal. The ASN is used to perform a logical receipt
for invoicing and costing purposes. The receipt is a logical receipt because the items
are not physically sent to the central DOM instance but to the end customer.
For the demo of ASN functionality, we used Oracle iSupplier Portal. Note,
however, that for real DOM implementation you may want to use EDI of XML in
order to eliminate the need for users of 3rd Party Systems to interact with the
iSupplier Portal running on the Central DOM Instance. Following screenshots
show how ASNs are created in the iSupplier portal.
Page 28
Page 29
Page 30
Once an ASN is created in the iSupplier Portal, its status can be reviewed as shown
below. Initially, the processing status will be Pending until the Receiving
Transaction Processor is run that transfers records from Receiving interface table to
Receiving headers and lines tables.
Page 31
Step 9: Import ASN

(Central Instance)
Once an ASN is received through either XML, EDI, or iSupplier Portal and stored
in Receiving interface tables, the Receiving Transaction Processor needs to be run to
transfer records from Receiving interface table to headers and lines table. At
customer sites, Receiving Transaction Processor should be setup to run in regular
time intervals. In our demo, we manually run the Receiving Transaction Processor
(with Purchasing responsibility) as shown below.
Step 10: Perform Logical Receipt

Based on ASN
(Central Instance)
Page 32
After ASN has been imported into the central DOM instance, a logical receipt can
be performed in the Receiving. The receipt is logical because physical transfer of
items is performed from the 3rd Party System to the customer and not from the 3rd
Party System to the Central DOM Instance.
Open Find Expected Receipts form by navigating to Purchasing Receiving
Receipts and search by PO number in logical DOM organization M1.
Page 33
Receipts form will open with item and quantities specified on the imported ASN.
Page 34
Specify logical subinventory and accept the receipt.
Note that steps 10-11, from ASN Import to Logical Receipt can be automated as
explained in section 3.3.2.
Drop Ship Tab of the Additional Line Information Action shows that quantity 1 of
00 Drop Ship Item has been received.
Page 35
Step 11: Generate Customer Invoice

(Central Instance)
Invoicing of DOM orders works in the same way as invoicing of standard orders
because the same order line workflow is used.
Currently, there is no support for importing freight charges incurred by the supplier
(3rd Party System) and any such charges would need to be manually entered in OM
as standard charges.
Page 36
Step 12: Close Order

(Central Instance)
After invoicing is done, the Order Line workflow closes the order line, which in turn
triggers the closing of the whole order (once all the lines are closed).
Page 37
Step 13: Check Order Progress In

Order Information Portal
(Customer)
While we put checking of the order progress as the last step in the flow, the
customer (Business World) can check the order progress in the Oracle Order
Information Portal at any point in the flow as soon as the order is entered.
Note that Shipment details are currently not available in the Order Information
Portal for Drop Ship flow and consequently for the DOM flow. This gap should be
fixed in one of the subsequent releases.
This was the last step of the DOM flow. In the next section, we explain how Oracle
Order Management supports change management for DOM orders.
Page 38
3.2.2. Change Management

In this section, we explain the change management features that are available with
11i.9 and 11i.10 for each of the four possible change management scenarios in
Distributed Order Management flows:
Customer Sales Order Purchase Order (Central Instance)
Purchase Order (Central Instance) 3rd Party System
3rd Party System Purchase Order (Central Instance)
Purchase Order (Central Instance) Customer Sales Order
3.2.2.1. Customer Sales Order Purchase Order (Central

Instance)
In 11i.9, data changes are not synchronized between Order Management and
Purchasing. All changes, except split and delete operations, are allowed on the Sales
Order Line irrespective of the status of the Requisition or PO in the Purchasing
system. Similarly, Purchasing allows most of the changes on the Requisitions and
Purchase Orders. Order Management Sales Order and Purchase Order
Discrepancy Report is used to view the difference between Sales Orders and
associated Purchase Orders in order to identify where manual changes need to be
made.
In 11i.10, the time consuming manual process of changing both the Sales Order and
Purchase Order (PO) is replaced with the automated change management where
user initiated changes on the Sales Order trigger changes on the associated
Requisitions and POs. For example, changes made on Sales Order Lines, such as
Ship To Location and Quantity, are propagated to Requisitions and Purchase
Orders. If a change cannot be performed on the Requisition or Purchase Order due
to the document status, then the user change will be rejected and a message
explaining the reason for failure will be issued. Sales Order changes are supported as
long as the Purchase Order can be changed. If the Requisition import is not run and
the Requisition request is still in the Requisition interface, then the interface record
will be updated. If a Requisition or Purchase Order exists for the Order Line, OM
will call a PO API that will accept the updated data elements and cascade the change
to the Requisition or PO.
Page 39
In 11i.10, Purchasing allows changes on a Purchase Orders even if it is approved.

Changes on approved Purchase Orders will re-trigger the approval process and the
changes may or may not be approved. If changes are not approved, a notification
will be sent to the customer service representative (CSR). If the PO changes are
approved, then the changed PO will be sent to the 3rd Party System. The 3rd Party
System can always reject the changes if the Sales Order cannot be changed or if the
goods have shipped. For DOM orders this could cause a problem as the Sales
Order Lines in the 3rd Party System could have been canceled already. To avoid
this potential problem, OM introduced new constraint to restrict the Sales Order
Line changes once the Purchase Order is approved. Depending on the business
flows supported and the integration with 3rd Party Systems, customers may choose
to disable this constraint to allow more flexibility for Sales Order changes provided
they also take the responsibility for handling any exceptions.
Note that in the 11i.10, there is no need for users to run the Sales Order Purchase
Discrepancy Report because Sales Orders and associated Purchase Orders are
always synchronized. Consequently, the Sales Order Purchase Discrepancy Report
is no longer available.
The following table shows how data changes are handled on the Sales Order:
Sales Order
Change
When Allowed (Validation

Conditions)
Update will be allowed under the
following conditions:
Requisition: not canceled or finally
closed
PO Header: must not be in canceled,
frozen, finally closed or In Process
Quantity
Increase/
Decrease
Approved
Req.
PO
Requisitio
n Interface
row will be
updated
with
revised
quantity.
Requisition
Line and
Distribution
will be
updated
with revised
quantity.
PO Shipment
and Distribution
quantity will be
updated with the
revised quantity.
PO Line quantity
will be updated
to reflect the new
shipment
quantity.
PO Line: must not be canceled, finally

closed.
PO revision
number will be
incremented.
PO Shipment: must not be canceled.

Additional Validation for Quantity
Decrease:
New quantity must be greater than or
equal to the greater of quantity received
or quantity billed or quantity
shipped(ASN received) for the shipment.
Same as above.
Complete
Cancellation
Req.
Interface
PO Header: can be in approved,

rejected, frozen, reserved, closed for
receiving or closed for invoicing state
PO Shipment and Distribution: The
Requisitio
n interface
row will be
deleted.
Requisition
line will be
canceled
If the PO was
originally in an
approved state,
Change Order
workflow will be
invoked to
approve and
communicate
change to the 3rd
Party System.
PO Shipment
will be canceled.
PO revision
number will be
incremented.
Comments
If multiple Supply Source exists
(Example: Multiple Requisitions/POs
linked to the same Sales Order Line),
then special logic is used to select
Requisitions that need to be changed.
Special Logic:
- First, change the Requisitions that do
not have PO's
- Second, change the PO's that are not
approved or partially received or ASN
received.
- Last, change the PO's for which the
changes are allowed. Note that there
could be earlier quantity decreases that
could have resulted in canceled
Requisitions.
OM added a removable constraint that
disallows a change if the PO or Release
is approved. If there are multiple Reqs
and POs, then change is not allowed if
all the POs or Releases are approved.
If multiple Supply Source exists(

Multiple Requisitions/POs linked to the
same Sales Order Line) , then all of
them are canceled.
disallows a change if any one of the
related POs or Releases is approved.
Page 40
New PO revision
will be
communicated to
the supplier.
greater of quantity received or quantity

billed is lesser than or equal to quantity
ordered.
Cancel date needs to be within effective
dates of the accounting period. If Partial
or full quantity is Received, changes are
not allowed. If ASN received for Partial
or Full Quantity, change is not allowed.
Allowed under following conditions:
closed
PO Header: must not be canceled,
Schedule Ship
Date

closed.
PO Header: must not be canceled,
Shipping Instr,
Packing Instr.
Shipto Contact,
Deliver to
Address ,
Deliver to
Contact,
Customer PO
Number,
Customer PO
Line Number,
Customer PO
Shipment
Number ,
Customer/User
Item Desc,
Shipping
Method
Warehouse
Requisition
line will be
updated
with new
Need By
Date.

closed. Source document referenced
must be valid.
If Partial or full quantity is Received,
changes should not be allowed.
If ASN received for Partial or Full
Quantity, change should not be allowed.
Allowed under following conditions:
Ship To
Location
Requisitio
n interface
row will be
updated
with new
Need by
Date.
Interface
record will
be updated
with new
deliver-to
location.
Requisition
line will be
updated
with new
deliver-to
location.
No Impact
No Impact

closed. Source document referenced
must be valid.
Quantity, Change should not be allowed.
Validation:
PO should not be Frozen or Finally
Closed.
If multiple Sources exist, then all

existing Requisition and PO supply
linked to the Sales Order Line will be
updated with the new need by date.
PO revision
number will be
incremented.

Change Order
workflow will be
invoked to
approve and
communicate
change to the
supplier.
PO revision
number will be
incremented.
If the PO was
originally in an
approved state,
Change Order
workflow will be
invoked to
approve and
communicate
change to the
supplier.
If PO is not
approved, No
Impact.
If multiple Sources exist, then all

existing Requisition and PO supply
linked to the Sales Order Line will be
updated with the new ship to location.

If PO is
approved, OM
will call a PO
API to trigger
the Change PO
process.

Quantity, Change should not be allowed.
Warehouse changes are not allowed once

the line is interfaced to Purchasing.
Need-by date
will be updated
on the PO
shipment.
Not
allowed
Not allowed
Not allowed
Page 41
Ordered UOM
SO Line split
Delete Lines
Ordered UOM changes are on allowed

once the line is interfaced to Purchasing.
User initiated Sales Order Line Split is
not allowed once the line is interfaced to
Purchasing.
Sales Order Line Deletion not allowed
once the line is interfaced to Purchasing.
Not
allowed
Not
Allowed.
Not allowed
Not allowed
Not
Allowed.
Not Allowed.
Not
Allowed.
Not
Allowed.
Not Allowed.
Exception is the Configured Item

Deletions. Configured Item is a special
case, where constraints are not checked
when Configured Item is deleted.
3.2.2.2. Purchase Order (Central Instance) 3rd Party System

In 11i.9, Purchasing can communicate Purchase Order changes to 3rd Party System
through either iSupplier portal or XML/EDI Change PO transactions. For more
information refer to the following documentation: Oracle Purchasing User Guide,
Oracle Purchasing 11i XML Transaction Delivery Setup Guide, Oracle XML
Gateway Users Guide, and Oracle eCommerce Gateway Users Guide.
In 11i.10, the change management functionality has been enhanced to incorporate
new attributes propagated to Purchase Order from the associated DOM or Drop
Ship Sales Order:
Ship To Customer Name
Ship To Customer Contact Name
Ship To Customer Contact Phone Number
Ship To Contact Fax Number
Ship To Customer Contact E-mail
Shipping Instructions
Packing Instructions
Shipping Method (= Freight Carrier + Mode of Transport + Service Level)
Customer PO
Customer PO Number
Customer PO Line Number
Customer PO Shipment Number
Customer Item Description
Deliver To Customer Name
Deliver To Customer Address
Deliver To Customer Contact Name
Page 42
Deliver To Customer Contact Phone Number
Deliver To Customer Contact Fax Number
Deliver To Customer Contact E-mail
3.2.2.3. 3rd Party System Purchase Order (Central Instance)

Once a 3rd Party System agrees to fulfill the Purchase Order by sending PO
Acknowledgement, it cannot directly modify the Purchase Order in the central
instance. Instead, all Purchase Order changes need to be made to the original Sales
Order Line.
3.2.2.4. Purchase Order (Central Instance) Customer Sales

Order
In 11i.9, data changes are not synchronized between Order Management and
Purchasing, and Purchasing allows most of the changes on Requisitions and
Purchase Orders. Order Management Sales Order and Purchase Order Discrepancy
Report is used to view the difference between Sales Orders and associated Purchase
Orders in order to identify where manual changes need to be made.
In 11i.10, DOM/Drop Ship Sales Orders and associated Purchase Orders are
synchronized, and certain types of changes like Ship To Location are no longer
allowed. Changes to the Purchase Order in DOM/Drop Ship flows should be made
indirectly by modifying the associated Sales Order and having the changes propagate
to the Purchase Order.
Buyer cannot change the following data elements on Requisitions and Purchase
Orders that are linked to a Drop Ship Sales Order:
Inventory Item
Ship To Location (Deliver to in PO)
UOM
Quantity
Need By Date
Warehouse (Ship To Org)
Project and Task Information
Splitting of the Requisition is not allowed, and Requisitions linked to a Sales Order
cannot be canceled or finally closed. In addition, Requisitions cannot be returned to
the Requestor. Normally, Buyers can return the Requisitions to the Requestor and
no action will be performed.
Following table shows how the change management is handled for the Drop Ship
Purchase Orders. Note that the same change logic applies to Releases as well.
Page 43
Purchase Order
Change
When Allowed (Validation

Conditions)
Sales Order
Approved
Requisition
Create new PO from

Sourcing Award
Not Applicable because a

Requisition line tied to a Drop
Ship Sales Order Line cannot
be selected for negotiation.
No impact
Not Allowed on the Enter PO

form or via PO Change API.
Not allowed via Supplier
Initiated Change Request.
Notification will be sent to the

Requisition preparer. The
assumption is that the CSR is the
Requisition preparer.
Autocreate form
should not allow
selecting RFQ as
document type, if
Requisition line is
associated with a
drop ship Sales
Order.
No impact.
Allowed, based on existing

validations on the Enter PO
form, PO Change API,
Supplier Change order.
Notification will be sent to the

Requisition preparer. The
assumption is that the CSR is the
Requisition preparer.
No impact.
Not allowed on PO Shipments

with backing Sales Order
demand.
No impact.
No impact.
Not allowed from the Enter

PO form if the Shipment is
linked to a Drop Ship Sales
Order.
No impact
No impact
Allowed, when Purchase Order

is not approved, Requisition
returned to Requisition pool.
PO references to be removed as a
source for the Sales Order
Demand.
PO Header, Line or Shipment

cancellation is Allowed from
the PO Summary form and via
Supplier Initiated Change
Order.
Notification will be sent to CSR.
Requisition returned
to Buyers
Requisition pool.
Can be sourced
through a new
Purchase Order.
PO/Line
cancellation: Backing
Requisition will be
sent back to the
Requisition pool.
Shipment Quantity
increase/Shipment
Quantity Decrease
Promise Date
Need-by date
Ship-to Location
Delete Lines
PO, Line or
Shipment
Cancellation
Requisition lines should be

returned to the Requisition
Pool, if Sales Order Line is not
fulfilled or closed. OM API to
be called to validate Sales
Order Line status. (Sales Order
Line could be fulfilled or closed
if quantity received is within
shipping tolerance).
Canceling Requisition lines
during PO Cancellation not
allowed.
Partial PO Receipt(delivery) of a
Drop Ship Order causes the Sales
Order Line to be split. A new
Sales Order Line is created for the
unfulfilled order quantity.
If PO shipment is canceled after
partial receipt, the backing
Requisition gets split. A new
Requisition line is created and
sent back to the pool with the
unfulfilled quantity.
The only open Sales Order Line
linked to the PO Shipment will
now reference the new
Requisition line from the split.
PO Shipment: if
partially received, the
original Requisition
line will be split. The
quantity in the
original line will be
reduced to quantity
received. The.
remaining quantity
will be placed on a
new Requisition line.
Comments
Note that PO treats

Quantity decrease different
from Cancellation. Users
can either completely cancel
the line or cancel the
remaining quantity after
partial quantity is received.
There is no partial
cancellation.
Promise Date will be
displayed in the Drop Ship
Tab in OM. Sales Order
Line is not updated.
Note that PO treats

Quantity decrease different
from Cancellation. Users
can either completely cancel
the line or cancel the
remaining quantity after
partial quantity is received.
There is no partial
cancellation.
Page 44
3.2.3. Support For Configurations And Kits

Support for PTO Models, ATO Models, and Kits for Distributed Order
Management flows is the same as for the Drop Ship flows.
Individual lines under PTO Models and Kits can be sourced and shipped from
different suppliers (3rd Party Systems) or shipped internally based on the sourcing
rules for each of the items.
However, Ship Model Complete PTO Models are not supported for two reasons:
Since each line may be sourced from a different supplier (3rd Party System),
directly to the customer, it is not possible to enforce the Ship Model Complete
constraint
Schedule date on each line may be different if some lines are sourced internally
and some externally; Ship Model Complete lines by definition need to be
scheduled for the same date.
For ATO Models, the configured item (either created or matched to an existing one)
follows its own seeded flow. Like the standard item flow, configured item flow is
Drop Ship/DOM enabled making it possible for 3rd Party Systems to fulfill orders
that contain configured items. Communicating configuration details to the supplier
(3rd Party System) is supported through iSupplier Portal, EDI, and XML.
For ATO Models, changes to the source type are always done at the top level Model
line, and are then cascaded to the child lines. Changes of the source type for the
option /class level lines are not allowed. The source type for the top level ATO
Model line is defaulted as specified by the defaulting rules.
Page 45
3.2.4. Accounting
In this section, we discuss how accounting is handled in a DOM flow. The DOM
flow is based on the Drop Ship flow and accounting is similar to Drop Ship
accounting. However, there are some important differences. The way accounting is
done depends on whether the Sales Organization in the Oracle Central Instances
and the Fulfillment Organization in the 3rd Party System are in the same company
(Operating Unit) or not. Accordingly, accounting flows are divided in Inter
Company and Intra Company flows.
3.2.4.5. Inter Company Accounting Flows

Inter Company accounting flows apply to the case where the Sales Organization and
Fulfillment Organization are in different Operating Units and need to log accounting
entries in Inter Company accounts for Payables, Receivables, Revenues, and COGS.
The following functionality is needed for Inter Company (I/C) accounting flows:
I/C Payables, Receivables, Revenues, and COGS recorded in I/C accounts
I/C invoices generated
I/C profits eliminated at GL period close consolidation
All three of these requirements can be met by using Inventorys Inter Company
relations functionality to automate I/C accounting. See Figure 4 and Figure 5.
Customer
$20
Price list
Sales Org (SO)

Oracle Central I.
SOB1/LE1/OU1
$10
Transfer
price
COGS (3PS): $5
Fulfillment Org (FO)
in Oracle Central I.
representing
Fulfillment Org in 3rd
Party System
SOB2/LE2/OU2
$5
PO price
in 3rd Party System

(modeled as a
Logical Supplier)
SOB2/LE2/OU2
Logical receipt
Financial Flow
Physical Flow
Figure 4 Inter Company Accounting Flow
In this flow, the physical transfer of goods occurs between the 3rd Party System
modeled as a Logical Supplier and the Customer. The associated financial flow
includes two additional nodes: (1) a Fulfillment Org in the Oracle Central Instance
setup to represent the Fulfillment Org in the 3rd Party System for I/C accounting
Page 46
purposes, and (2) a Sales Org in the Oracle Central Instance that captures the
Customers order.
In order to enable I/C transactions and I/C invoicing in the Inter Company DOM
flow, I/C Relations need to be setup in Intercompany Relations form (Inventory >
Setup > Organizations > Intercompany Relations). An I/C relation needs to be
setup between the OU2/Fulfillment Org and OU1/Sales Org in the Oracle Central
Instance. With this setup, liability and revenue are automatically transferred from
OU2/Fulfillment Org to OU1/Sales Org after the logical delivery of goods in the
Fulfillment Org in the Oracle Central Instance (a concurrent program needs to be
run to perform logical I/C accounting between Fulfillment and Sales Orgs).
In 11.5.10, accounting scenarios more complex than the one shown in Figure 4 are
supported with Inventorys new Transaction Flow functionality. With Transaction
Flows, any number of intermediate financial nodes can be added between the Source
and Destination OUs. Transaction flows map the financial path identifying all the
Operating Units/Inventory Orgs that are involved in the transfer of assets from the
point of procurement through to the final selling organization.
Now, lets examine accounting entries in the DOM flow that are logged for the
Fulfillment Org and the Sales Org (Figure 5).
Time
Transaction
T1
Sale and Shipment

in the Fulfillment
Org 3rd Party
System
Receipt in
Fulfillment Org
Oracle Central Inst
Receiving Desktop
Form
Deliver in
Fulfillment Org
Oracle Central Inst
Receiving Desktop
Form
T2
T3
Description
Sales Org
Accounting OU1
(Oracle Central
Inst.)
Fulfillment Org
Accounting OU2
(Oracle Central Inst.)
Fulfillment Org
Accounting OU2
(3rd Party System)
Dr OU2 Internal Receivable 5
Cr OU2 Internal Revenue 5
Dr OU2 Internal COGS
Cr OU2 Inventory
(Receiving Processor)
Dr OU2 Clearing
5
Cr OU2 Internal Accrual 5
RT: Receive in
Fulfillment Org
Oracle Central
Instance
RT: Deliver in
Fulfillment Org
Oracle Central Inst
MMT: PO receipt in
Fulfillment Org
(Accounting txn)
(Logical PO receipt)
MMT: Fulfillment
Org Sales Org
(Accounting txn)
(Logical I/C
shipment)
(Logical I/C receipt)
(Cost processor)
Dr OU2 Inventory 5
Cr OU2 Clearing
(Cost Processor)
Dr OU1 Inventory 10
Cr I/C Accrual
10
(I/C Invoicing)
Dr I/C Receivable
Cr I/C Revenue
10
(I/C Invoicing)
Dr I/C Accrual 10
Cr I/C Payable
10
(Cost processor)
Dr I/C COGS
5
Cr OU2 Inventory
10
Page 47
5
5
MMT: Sales Org ->

Customer
(Accounting txn)
(Logical Sales
Order Issue)
OU1 Reconciliation
OU2 Reconciliation
Dr COGS
Dr Receivable
Cr I/C Payable
Cr Revenue
Dr Internal COGS
5
Dr I/C COGS
5
Dr Internal Receivable 5
Dr I/C Receivable
10
Cr Inventory
Cr Internal Accrual
Cr Internal Revenue
Cr I/C Revenue
10
20
10
20
(Cost Processor)
Dr OU1 COGS
10
Cr OU1 Inventory 10
(AR Invoice)
Dr OU1 Receivable 20
Cr OU1 Revenue
20
5
5
5
10
Figure 5 Inter Company Accounting Entries

Transaction T1 - Sale and Shipment in the Fulfillment Org OU2 (3rd Party System)
At the time of sale and shipment in the 3rd Party System, OU2 Inventory account is
credited and an Internal COGS account debited with the amount of cost of goods
sold. In addition, an Internal Receivable account is debited and an Internal Revenue
account credited at the PO price. Note that accounts for COGS, Receivables, and
Revenues need to be specially designated as Internal accounts because the sale is
made within the same OU from Fulfillment Org in the 3rd Party System to
Fulfillment Org in the Oracle Central Instance. For the same reason, the PO price
should always be the same as the COGS in the 3rd Party System.
Internal COGS, Receivables, and Revenues should not be included in the companys
overall COGS, Receivables, and Revenue accounts. They should be setup as
separate natural accounts and should not be included in summary accounts or
account hierarchies for companys COGS, Receivables, and Revenues.
Transaction T2 - Receipt in Fulfillment Org OU2 (Oracle Central Instance)
The Fulfillment Org in the Oracle Central Instance is a logical organization

representing the actual Fulfillment Org in the 3rd Party System. It is necessary to
have this logical Fulfillment Org in order to enable the automatic Inter Company
accounting and invoicing. The logical Fulfillment Org in the Oracle Central Instance
and the actual Fulfillment Org in the 3rd Party System should use the same value for
the company segment in their accounts and accounting entries should be imported
into the same Set of Books (sharing the same Chart of Accounts and Accounting
Calendar).
Once an ASN is received from the 3rd Party System or a logical receipt is manually
performed in the Fulfillment Organization (Oracle Central Instance), accounting
Page 48
entry is made by the Receiving Processor in the Oracle Central Instance to debit
OU2 Clearing account and credit the Internal Accrual account at the PO price.
Note that the Accrual account needs to be designated as an Internal account because
no actual liability is incurred against another company or external entity. Internal
Accrual account balance should not be counted towards companys overall liabilities.
It should be setup as a separate natural account and should not be included in
summary accounts or account hierarchies for companys liabilities. Purchasing
Account Generator Workflow needs to be customized to default the A/P Accrual
account to the Internal Accruals account for receipts in the logical Fulfillment Org.
There is one important difference between Drop Ship and DOM flows with regards
to accounting. In the Drop Ship flow, the liability accrued in the Accruals account is
transferred to the Payables account once an invoice is received from the Supplier
and matched against the Purchase Order. In the DOM flow, there should be no
invoicing between the Fulfillment Org in the 3rd Party System and its representation
Fulfillment Org in the Oracle Central Instance. This can be achieved by setting the
item attribute Invoice Close Tolerance to 100% (Master Items form, Purchasing
tab) for DOM items in the Fulfillment Org. With Invoice Close Tolerance set to
100%, Purchase Orders will be automatically closed after receipt without waiting for
an invoice to be matched in the Payables. In the DOM, balance in the Internal
Accruals account is never transferred to the Payable account since invoices are never
received. Instead, it is eliminated against balances in the Internal Receivables
account during the manual consolidation process at the GL period close. Internal
Accruals and Internal Receivables can be mapped to the same natural account to
facilitate the elimination process. Similarly, Internal COGS and Internal Revenues
can be mapped to the same natural account.
Transaction T3 Deliver in Fulfillment Org OU2 (Oracle Central Instance)
At deliver transaction in Receiving, several accounting transactions occur. First,

OU2 Clearing Account is credited and Inventory account debited at the PO price.
At this point, the goods are logically transferred from the 3rd Party System to the
Oracle Central Instance (remember that at transaction T1, the same Inventory
account was credited when goods were physically shipped).
Next, a Concurrent Program is run to perform automatic Inter Company accounting
between the Fulfillment Org and the Sales Org in the Oracle Central Instance based
on the I/C Relations setup:
(Cost Processor) OU2 Inventory account credited and I/C COGS account
debited at the PO price.
(Cost Processor) OU1 Inventory debited and I/C Accrual account credited at
the Transfer price
(I/C Invoicing) OU2 I/C Revenues credited and I/C Receivables debited at
Transfer price
Page 49
(I/C Invoicing) OU1 I/C Accruals debited and I/C Payables credited at the
Transfer price
Note that the accounting entry for OU2 I/C COGS is recorded at the correct
amount of PO price, which was set to be the same as the COGS in the Fulfillment
Org in the 3rd Party System. OU2 I/C Receivables match the OU1 I/C Payables at
the Transfer price, and OU2 I/C Revenue is recognized at the Transfer price as well.
Depending on the legal arrangement between the Sales Org and Fulfillment Org,
taxes may or may not need to be charged on the I/C invoices.
Finally, accounting entries for transfer of goods from the Sales Org to the Customer
are made. OU1 Inventory account is credited and COGS account debited at the
Transfer price, while OU1 Revenue account is credited and Receivables debited at
the Sales Order Price List price.
Accounting entries in the Fulfillment Org (3rd Party System) may be recorded in the
same Set of Books as accounting entries in the Sales Org (Oracle Central Instance)
or in a separate Set Of Books in the same Oracle GL. Both of these cases are
supported by setting up the Fulfillment Org in the Oracle Central Instance to record
its accounting entries in the same Set of Books as the Fulfillment Org in the 3rd
Party System (shared Chart of Accounts and Accounting Calendar). Accounting
entries in the Fulfillment Org (3rd Party System) can also be recorded in a nonOracle GL, but in this case accounting entries made in the Fulfillment Org in the
Oracle Central Instance need to be imported into the same non-Oracle GL and Set
of Books.
Page 50
3.2.4.6. Intra Company Accounting Flows

Intra Company accounting flows apply to the case where the Sales Organization and
Fulfillment Organization are in the same Operating Unit and there are no Inter
Company Payables, Receivables, Revenues, or COGS. Intra Company flows are
further divided based on whether accounting entries in the 3rd Party System are
recorded or not:
Accounting entries recorded in the 3rd Party System
Accounting entries not recorded in the 3rd Party System
Accounting Entries Maintained In The 3rd Party System
In this scenario, accounting entries are recorded in the Fulfillment Org (3rd Party
System) and are imported into the same General Ledger and Set of Books as the
accounting entries of the Sales Org (Oracle Central Instance). The accounting
entries need to be imported into the same General Ledger because Fulfillment Org
and Sales Org belong to the same Operating Unit.
In the Intra Company accounting flow shown in the Figure 6, physical transfer of
goods occurs between the 3rd Party System (modeled as a Logical Supplier) and the
Customer. The associated financial flow includes one additional node: a Sales Org in
the Oracle Central Instance that captures the Customers order.
COGS (3PS): $5
Customer
$20
Price list
Sales Org (SO)

is also a selling org
Oracle Central I.
SOB1/LE1/OU1
$5
PO price
in 3rd Party System

(modeled as a
Logical Supplier)
SOB1/LE1/OU1
Logical receipt
Financial Flow
Physical Flow
Figure 6 Intra Company Accounting Flow
Page 51
Now, lets examine accounting entries in the Intra Company DOM flow (Figure 7).
Time
Transaction
T1
Sale and Shipment

in the Fulfillment
Org 3rd Party
System
Receipt in Sales
Org Oracle Central
Inst - Receiving
Desktop Form
Deliver in Sales
Org Oracle Central
Inst - Receiving
Desktop Form
T2
T3
Description
Sales Org
Accounting OU1
Fulfillment Org
Accounting OU1
(3rd Party System)
Dr OU1 Internal Receivable 5
Cr OU1 Internal Revenue
5
Dr OU1 Internal COGS
Cr OU1 Inventory
RT: Receipt in
Sales Org
Oracle Central
Inst
RT: Deliver in
Sales Org
Oracle Central
Inst
MMT: PO receipt
in Sales Org
(Accounting txn)
(Logical PO
receipt)
MMT: Sales Org > Customer
(Accounting txn)
(Logical Sales
Order Issue)
5
5
(Receiving Processor)
Dr OU1 Clearing
5
Cr OU1 Internal Accrual 5
(Cost processor)
Dr OU1 Inventory 5
Cr OU1 Clearing
(Cost Processor)
Dr OU1 COGS
5
Cr OU1 Inventory 5
(AR Invoice)
Cr OU1 Revenue
20
OU1 Reconciliation
Dr Internal COGS
5
Dr COGS
5
Dr Internal Receivable 5
Dr Receivable
20
Cr Inventory
Cr Internal Accrual
Cr Internal Revenue
Cr Revenue
5
5
5
20
Figure 7 Intra Company Accounting Entries

Transaction T1 - Sale and Shipment in the Fulfillment Org (3rd Party System)
At the time of sale and shipment in the 3rd Party System Fulfillment Org, Inventory
account is credited and an Internal COGS account debited with the amount of cost
of goods sold. In addition, an Internal Receivable account is debited and an Internal
Revenue account credited at the PO price. Note that accounts for COGS,
Receivables, and Revenues need to be specially designated as Internal accounts
because the sale is made within the same Operating Unit from Fulfillment Org in
the 3rd Party System to Sales Org in the Oracle Central Instance. For the same
Page 52
reason, the PO price should always be the same as the COGS in the 3rd Party
System.
Internal COGS, Receivables, and Revenues should not be included in the companys
overall COGS, Receivables, and Revenue accounts. They should be setup as
separate natural accounts and should not be included in summary accounts or
account hierarchies for companys COGS, Receivables, and Revenues.
Transaction T2 - Receipt in Sales Org (Oracle Central Instance)
Since Sales Org in the Oracle Central Instance and the Fulfillment Org in the 3rd
Party System are in the same Operating Unit, they should use the same value for the
company segment in their accounts. In addition, accounting entries in the Sales Org
and Fulfillment Org should be imported into the same Set of Books (sharing the
same Chart of Accounts and Accounting Calendar).
Once an ASN is received from the 3rd Party System or a logical receipt is manually
performed in the Sales Org (Oracle Central Instance), accounting entry is made by
the Receiving Processor in the Oracle Central Instance to debit OU1 Clearing
account and credit the Internal Accrual account at the PO price. Note that the
Accrual account needs to be designated as an Internal account because no actual
liability is incurred against another company or external entity. Internal Accrual
account balance should not be counted towards companys overall liabilities. It
should be setup as a separate natural account and should not be included in
summary accounts or account hierarchies for companys liabilities. Purchasing
Account Generator Workflow needs to be customized to default the A/P Accrual
account to the Internal Accruals account for logical receipts in the Sales Org.
There is one important difference between Drop Ship and DOM flows with regards
to accounting. In the Drop Ship flow, the liability accrued in the Accruals account is
transferred to the Payables account once an invoice is received from the Supplier
and matched against the Purchase Order. In the DOM flow, there should be no
invoicing between the Fulfillment Org in the 3rd Party System and the Sales Org in
the Oracle Central Instance since they are in the same Operating Unit. This can be
achieved by setting the item attribute Invoice Close Tolerance to 100% (Master
Items form, Purchasing tab) for DOM items in the Sales Org. With Invoice Close
Tolerance set to 100%, Purchase Orders will be automatically closed after receipt
without waiting for an invoice to be matched in Payables. In the DOM, balance in
the Internal Accruals account is never transferred to the Payable account since
invoices are never received. Instead, it is eliminated against balances in the Internal
Receivables account during the manual consolidation process at the GL period close.
Internal Accruals and Internal Receivables can be mapped to the same natural
account to facilitate the elimination process. Similarly, Internal COGS and Internal
Revenues can be mapped to the same natural account.
Transaction T3 Deliver in Sales Org (Oracle Central Instance)
Page 53
At deliver transaction in Receiving, several accounting transactions occur. First,

OU1 Clearing Account is credited and Inventory account debited at the PO price.
At this point, the goods are logically transferred from the 3rd Party System to the
Oracle Central Instance (remember that at transaction T1, the same Inventory
account was credited when goods were physically shipped). Then, accounting
entries for transfer of goods from the Sales Org to the Customer are made. OU1
Inventory account is credited and COGS debited at the Transfer price while OU1
Revenue account is credited and Receivables debited at the Sales Order Price List
price.
Note that Fulfillment Org in the 3rd Party System does not charge taxes to the Sales
Org in Oracle Central Instance because they are in the same Operating Unit and no
I/C invoices are generated.
Page 54
Accounting entries not maintained in the 3rd Party System

It is possible for the 3rd Party System to maintain no accounting entries. This is
typically a case with the 3rd Party Warehouse systems (3PWs). 3PWs provide the
warehouse storage space and manage the transportation process but do not own the
Inventory. Consequently, they do not keep the track of Receivable, Revenues of
COGS. The Sales Org in the Oracle Central Instance is the one that owns the
Inventory and maintains all associated accounting entries.
The communication between the Oracle Central Instance and 3PWs is different
from the typical Drop Ship based DOM flow communication because it does not
use Purchase Order and ASN documents. Instead, Oracle Central Instance and
3PWs communicate through XML Shipment Requests (equivalent of X12 940) and
XML Shipment Responses (equivalent of X12 945). In this case, the DOM flow is
not based on the Drop Ship flow but on the 3PW flow supported by the Oracle
Shipping and Transportation applications.
In the Intra Company accounting flow shown in the Figure 8, the physical transfer
of goods occurs between the 3rd Party System (modeled as an Inventory Org) and
the Customer. In this scenario, 3rd Party System does not log any accounting entries
and the associated financial flow is between the Sales Org in the Oracle Central
Instance and the Customer. Accounts for the inventory kept in the 3PW and
associated COGS are maintained in the Sales Org (Oracle Central Instance).
COGS: $5
Customer
$20
Price list
Sales Org (SO)

designated as 3PW
Oracle Central I.
SOB1/LE1/OU1
Financial Flow
Physical Flow
3rd Party System

(modeled as
Inventory Org)
Figure 8 Intra Company Accounting Flow (For 3PW Based DOM Flow)
The accounting entries made in the Sales Org are the same as for the case of
shipping from an internal warehouse (Figure 9).
Time
Transaction
T1
Sale and
Shipment in the
Sales Org
Oracle Central
Instance
Description
Sales Org
Accounting OU1
Cr OU1 Revenue
20
Dr OU1 COGS
5
Cr OU1 Inventory
Figure 9 Intra Company Accounting Entries (3PW Based DOM Flow)
Page 55
Transaction T1 - Sale and Shipment in the Sales Org (Oracle Central Instance)
At the time of sale and shipment in the 3rd Party System, Oracle Central Instance
credits OU1 Inventory account and debits the OU1 COGS account. In addition,
OU1 Receivable account is debited and OU1 Revenue account credited at the Sales
Order Price List price.
3PW does not charge taxes to Sales Org in the Oracle Central Instance since no I/C
invoices are generated.
While the 3PW-based DOM flow is simpler than the Drop Ship based DOM flow,
its use is restricted by several limitations:
940/945 Documents not as universally supported as POs and ASNs

o
Many ERP vendors (including Oracle Applications) do not

support Inbound Shipment Request (940) and Outbound
Shipment Response (945) required to model a 3rd Party System as a
3rd Party Warehouse System
Even if the 3rd Party System supports inbound Shipment Requests

and outbound Shipment responses, using Purchase Orders and
ASNs may be preferable to reuse the existing 3rd Party System
implementation. Existing 3rd Party System implementation would
more likely be setup to receive Purchase Orders and return ASNs
than to receive Shipment Requests and return Shipment
Responses.
3PW based DOM flow is not suitable for scenarios where 3rd Party System
needs to perform functions in addition to shipping items from the warehouse
o
In many scenarios, 3rd Party Systems will perform activities in

addition to shipping the goods from the warehouse. For example,
3rd Party System may be responsible for manufacturing the item or
providing additional services based on the original Customer order.
Typically, 3rd Party Systems would start order management
workflows to perform these additional activities upon receiving a
Purchase Order. In contrast, receiving Shipment Request (940)
will typically trigger only shipping of the goods that already exist in
the warehouse.
Limitation of Oracles Outbound 940/Inbound 945 implementation

o
Changes on 3PW orders not permitted (cancellations only)
No automatic transactions to maintain 3PW on-hand inventory in

the Oracle Central Instance
Reservations on the 3PW inventory not supported
Page 56
Given these limitations, the 3PW based DOM flow is most suitable for situations
where the 3rd Party System already supports Shipment Requests (940) and Shipment
Response (945), performs only shipments from the warehouse based on the requests
from the Oracle Central Instance, and maintains no accounting entries.
Page 57
3.3. Frequently Asked Questions

3.3.1. Automating Requisition Import PO Approval Flow
Requisition Import PO Approval flow steps can be automated by setting up a
blanket Purchase Order. If the order is for a configuration, the profile option
BOM: CTO Default Blanket PO Release needs to be set to Automatic Release.
Please refer to the Purchasing documentation on automatic source document
generation.
3.3.2. Automating ASN Import Logical Receipt Flow

In 11i.9, PO receipt and delivery transactions need to be performed separately for
logical receipt of DOM and Drop Ship orders. The only way to automate this flow
is to set the AUTO_TRANSACT_CODE to DELIVER in the Receiving interface
table. However, this would require a customization, as EDI and XML ASN
documents do not support the AUTO_TRANSACT_CODE field.
In 11i.10, automating receipt and delivery transactions for DOM and Drop Ship
orders is controlled by the new profile option PO: Automatically Deliver Drop Ship
ASNs:
Yes Automatically creates Receive and Deliver transactions in
Purchasing when an inbound ASN is received via iSupplier Portal or the Receiving
Open Interface, which includes ASNs sent through EDI and XML.
No Receiver needs to manually create receipt and delivery transactions for
the ASN.
3.3.3. Arrival And Ship Sets

Arrival and ship sets are not supported for Drop Ship/DOM orders.
3.3.4. Item Setup For DOM

All DOM items must be defined in the organization entered in the profile option
OE: Item Validation Organization and in the Receiving Organization.
Mandatory Item Attributes:
Purchased (PO)
Purchasable (PO)
Invoice Close Tolerance set to 100% (PO)
Page 58
Transactable (INV)
Stockable (INV)
Customer Ordered (OM)
Customer Orders Enabled (OM)
OE Transactable (OM)
Shippable (OM)
Optional Item Attributes:
Reservable (INV)
Inventory Item (INV)
Internal Ordered (OM)
Internal Orders Enabled (OM)
Page 59

November 2003
Author: Tarik Alatovic, Daniel Soosai Manickam
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
Web: www.oracle.com
This document is provided for informational purposes
only and the information herein is subject to change
without notice. Please report any errors herein to
Oracle Corporation. Oracle Corporation does not
provide any warranties covering and specifically
disclaims any liability in connection with this document.
Oracle is a registered trademark, and Oracle E-Business Suite,
Oracle Order Management, Oracle Order Information Portal,
Oracle Inventory, Oracle Purchasing, Oracle Trading Community
Architecture, Oracle iSupplier Portal, Oracle XML Gateway,
and Oracle e-Commerce Gateway are trademarks or registered
trademarks of Oracle corporation. All other names
may be trademarks of their respective owners.
Copyright Oracle Corporation 2003
All Rights Reserved

Implementing Distributed Order Management: An Oracle Topical Essay January 2004 by Tarik Alatovic/Daniel Soosai Manickam

Uploaded by

Document Information

Original Title

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

Implementing Distributed Order Management: An Oracle Topical Essay January 2004 by Tarik Alatovic/Daniel Soosai Manickam

Uploaded by

Copyright:

Available Formats

Implementing

Distributed Order Management

Implementing Distributed Order Management

Distributed Order Management

Implementing Distributed Order Management

Figure 1 Oracles Distributed Order Management Architecture

Internal Fulfillment Flows

Using Oracle E-Business Suite Modules

Brokering orders to 3rd Party Systems (SAP, Peoplesoft,

External Fulfillment Flows

Brokering orders to Trading Partners (Drop Ship, 3PLs, Carriers)

Implementing Distributed Order Management

Implementing Distributed Order Management

Implementing Distributed Order Management

3.1. Distributed Order Capture

Implementing Distributed Order Management

3.2. Distributed Order Fulfillment

Implementing Distributed Order Management

3.2.1. Flow: POs To 3rd Party Systems, ASNs Back

Customers can view order status in Order

Customer Order from iStore, Call Center, Sales

Receive the Order.

In Order Information Portal

If the item belongs to one of the 3 rd Party

Run the Requisition Import Process. As

The changes to the Scheduled Ship

The OE Line Wflow

Create the Purchase Order

On approval the PO is created.

On receipt of the ASN

Model each 3 rd Party Module as a

Any Changes to the Ship Date and

Figure 2 Overview Of DOM Flow

Central DOM Instance running E-Business Suite

Implementing Distributed Order Management

Figure 3 DOM Flow Steps

The flow consists of 13 steps:

(Central Instance) Create/Import Sales Order

(Central Instance) Import Requisition

(Central Instance) Create Purchase Order

(Central Instance) Approve Purchase Order

(Central Instance) Transmit PO

(3rd Party Instance) Import PO

(3rd Party Instance) Fulfill Purchase Order

(3rd Party Instance) Send ASN

(Central Instance) Import ASN

10. (Central Instance) Perform Logical Receipt Based On ASN

Implementing Distributed Order Management

Step 1: Create/Import Sales Order

Order quantity 1 of 00 Drop Ship Item on 14-OCT-2003.

Implementing Distributed Order Management

Implementing Distributed Order Management

The organizational item attribute, Default SO Source Type

If the value of Default SO Source Type is NULL, it defaults to Internal

Implementing Distributed Order Management

Step 2: Import Requisition

Implementing Distributed Order Management

After Requisition Import concurrent program completes, the Requisition is created

Implementing Distributed Order Management

Implementing Distributed Order Management

Implementing Distributed Order Management

Step 3: Create Purchase Order

After the Requisition is found, creating PO is straightforward as shown below. Note