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

3. IMPLEMENTATION ................................................... 3
3.1. Distributed Order Capture .................................................................. 4
3.2. Distributed Order Fulfillment ............................................................. 5
3.2.1. Flow: POs To 3rd Party Systems, ASNs Back .......................... 6
3.2.2. Change Management................................................................... 37
3.2.3. Support For Configurations And Kits ..................................... 43
3.2.4. Accounting ................................................................................... 43
3.3. Frequently Asked Questions ............................................................. 55
3.3.1. Automating Requisition Import → PO Approval Flow ........ 55
3.3.2. Automating ASN Import → Logical Receipt Flow ................ 55
3.3.3. Arrival And Ship Sets .................................................................. 55
3.3.4. Item Setup For DOM ................................................................. 55
 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 Oracle’s E-Business Suite are explained in the technical
brief 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.

2. BUSINESS CASE
The promise of a DOM system is that is unifies customer fulfillment process across
company’s 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).

Implementing Distributed Order Management Page 1

 Figure 1 Oracle’s 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
o Brokering orders to 3rd Party Systems (SAP, Peoplesoft, Legacy)

• External Fulfillment Flows o Brokering orders

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

Internal fulfillment flows using Oracle’s 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.

Implementing Distributed Order Management Page 2

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.

Implementing Distributed Order Management Page 3

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 Suite’s 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.

Implementing Distributed Order Management Page 4

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.

Implementing Distributed Order Management Page 5

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

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 E-

Business Suite)

Implementing Distributed Order Management Page 6

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

Implementing Distributed Order Management Page 7

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.

Implementing Distributed Order Management Page 8

Note that the source type is ‘External’ to invoke the OM’s 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:

Implementing Distributed Order Management Page 9

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

Implementing Distributed Order Management Page 10

 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)

Implementing Distributed Order Management Page 11

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.

Implementing Distributed Order Management Page 12

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

Implementing Distributed Order Management Page 13

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

Implementing Distributed Order Management Page 14

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.

Implementing Distributed Order Management Page 15

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.

Implementing Distributed Order Management Page 16

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.

Implementing Distributed Order Management Page 17

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.

Implementing Distributed Order Management Page 18

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 User’s Guide and Oracle e–Commerce Gateway User’s
Guide.

Implementing Distributed Order Management Page 19

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

Implementing Distributed Order Management Page 20

Excerpts from the generated PO XML are shown below.

Implementing Distributed Order Management Page 21

Implementing Distributed Order Management Page 22
 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)

Implementing Distributed Order Management Page 23

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.

The imported Sales Order can be found in the 3rd Party System by querying for the
PO generated in the central DOM instance.

Implementing Distributed Order Management Page 24

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.

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

Implementing Distributed Order Management Page 25

 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)

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.

Implementing Distributed Order Management Page 26

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.

Implementing Distributed Order Management Page 27

Implementing Distributed Order Management Page 28
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.

Implementing Distributed Order Management Page 29

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.

Implementing Distributed Order Management Page 30

Step 10: Perform Logical Receipt
Based on ASN
(Central Instance)

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.

Implementing Distributed Order Management Page 31

Receipts form will open with item and quantities specified on the imported ASN.

Implementing Distributed Order Management Page 32

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.

Implementing Distributed Order Management Page 33

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.

Implementing Distributed Order Management Page 34

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

Implementing Distributed Order Management Page 35

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.

Implementing Distributed Order Management Page 36

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.

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

Implementing Distributed Order Management Page 37

 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 When Allowed (Validation Req. Approved PO Comments
Change Conditions) Interface Req.

Update will be allowed under the Requisitio Requisition PO Shipment If multiple Supply Source exists
following conditions: n Interface Line and and Distribution (Example: Multiple Requisitions/POs
row will be Distribution quantity will be linked to the same Sales Order Line),
Requisition: not canceled or finally updated will be updated with the then special logic is used to select
closed with updated revised quantity. Requisitions that need to be changed.
PO Line quantity Special Logic:
revised with revised
will be updated - First, change the Requisitions
PO Header: must not be in canceled, quantity. quantity. to reflect the new that do not have PO's
frozen, finally closed or In Process
shipment - Second, change the PO's that
quantity. are not approved or partially received or
PO Line: must not be canceled, finally ASN received.
closed. - Last, change the PO's for
Quantity PO revision
number will be which the changes are allowed. Note that
Increase/ PO Shipment: must not be canceled. there could be earlier quantity decreases
incremented.
Decrease that could have resulted in canceled
Additional Validation for Quantity Requisitions.
If the PO was
Decrease: originally in an
New quantity must be greater than or approved state, OM added a removable constraint that
equal to the greater of quantity received disallows a change if the PO or Release is
Change Order
or quantity billed or quantity approved. If there are multiple Req’s
workflow will be and PO’s, then change is not allowed if
shipped(ASN received) for the shipment.
invoked to all the PO’s or Releases are approved.
approve and
communicate
change to the 3rd
Party System.
Same as above. Requisitio Requisition PO Shipment If multiple Supply Source exists(
n interface line will be will be canceled. Multiple Requisitions/POs linked to the
PO Header: can be in approved, rejected, row will be canceled same Sales Order Line) , then all of them
Complete are canceled.
frozen, reserved, closed for receiving or deleted. PO revision
Cancellation closed for invoicing state number will be OM added a removable constraint that
incremented. disallows a change if any one of the
PO Shipment and Distribution: The related PO’s or Releases is approved.

Implementing Distributed Order Management Page 38

 greater of quantity received or quantity New PO revision
billed is lesser than or equal to quantity will be
ordered. communicated to
the supplier.
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: Requisitio n Requisition Need-by date will If multiple Sources exist, then all existing
interface line will be be updated on the Requisition and PO supply linked to the
Requisition: not canceled or finally closed row will be updated with PO shipment. Sales Order Line will be updated with the
updated new Need By new need by date.
Date. PO revision
PO Header: must not be canceled, frozen, with new
finally closed or In Process Need by number will be OM added a removable constraint that
Date. incremented. disallows a change if any one of the
Schedule Ship related PO’s or Releases is approved.
Date PO Line: must not be canceled, finally
closed. Source document referenced must Change Order
be valid. workflow will be
invoked to
If Partial or full quantity is Received, approve and
changes should not be allowed. communicate
If ASN received for Partial or Full change to the
Quantity, change should not be allowed. supplier.
Allowed under following conditions: Interface Requisition PO revision If multiple Sources exist, then all existing
record will line will be number will be Requisition and PO supply linked to the
Requisition: not canceled or finally closed. be updated updated with incremented. Sales Order Line will be updated with the
with new new deliver- new ship to location.
PO Header: must not be canceled, frozen, deliver-to to location. If the PO was
finally closed or In Process location. originally in an OM added a removable constraint that
approved state, disallows a change if any one of the
Ship To Location PO Line: must not be canceled, finally Change Order related PO’s or Releases is approved.
closed. Source document referenced must workflow will be
be valid. invoked to
approve and
If Partial or full quantity is Received, communicate
changes should not be allowed. change to the
If ASN received for Partial or Full supplier.
Quantity, Change should not be allowed.
Shipping Instr, Validation: No Impact No Impact If PO is not OM added a removable constraint that
Packing Instr. approved, No disallows a change if any one of the
Shipto Contact, PO should not be Frozen or Finally Impact. related PO’s or Releases is approved.
Deliver to Closed.
Address , If PO is approved,
Deliver to If Partial or full quantity is Received, OM
Contact, changes should not be allowed. will call a PO API
If ASN received for Partial or Full to trigger the
Customer PO
Change PO
Number, Quantity, Change should not be allowed.
process.
Customer PO
Line Number,
Customer PO
Shipment
Number ,
Customer/User
Item Desc,
Shipping
Method

Implementing Distributed Order Management Page 39

Warehouse Warehouse changes are not allowed once Not allowed Not allowed Not allowed
the line is interfaced to Purchasing.
Ordered UOM Ordered UOM changes are on allowed Not allowed Not allowed Not allowed
once the line is interfaced to Purchasing.
SO Line split User initiated Sales Order Line Split is not Not Not Not Allowed.
allowed once the line is interfaced to Allowed. Allowed.
Purchasing.
Sales Order Line Deletion not allowed Not Not Not Allowed.
once the line is interfaced to Purchasing. Allowed. Allowed.

Delete Lines 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 User’s Guide, and Oracle e–Commerce Gateway User’s 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

Implementing Distributed Order Management Page 40

 • 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

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

Implementing Distributed Order Management Page 41

 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.
Purchase Order When Allowed (Validation Sales Order Approved Comments
Change Conditions) Requisition

Create new PO from Not Applicable because a No impact Autocreate form

Sourcing Award Requisition line tied to a Drop
Ship Sales Order Line cannot
be selected for negotiation.
Not Allowed on the Enter PO
Shipment Quantity form or via PO Change API.
Not allowed via Supplier
increase/Shipment
Initiated Change Request.
Quantity Decrease
Allowed, based on existing
validations on the Enter PO
Promise Date form, PO Change API, Supplier
Change order.
should not allow
selecting RFQ as
document type, if
Requisition line is
associated with a
drop ship Sales
Order.
Notification will be sent to the No impact. Note that PO treats
Requisition preparer. The Quantity decrease different
assumption is that the CSR is the from Cancellation. Users
Requisition preparer. can either completely cancel
the line or cancel the
remaining quantity after
partial quantity is received.
There is no partial
cancellation.
Notification will be sent to the No impact. Promise Date will be
Requisition preparer. The displayed in the Drop Ship
assumption is that the CSR is the Tab in OM. Sales Order
Requisition preparer. Line is not updated.

Not allowed on PO Shipments No impact. No impact.

with backing Sales Order
Need-by date demand.

Not allowed from the Enter PO No impact No impact

form if the Shipment is linked
Ship-to Location to a Drop Ship Sales Order.

Allowed, when Purchase Order PO references to be removed as a Requisition returned

is not approved, Requisition source for the Sales Order to Buyer’s
returned to Requisition pool. Demand. Requisition pool.
Delete Lines Can be sourced
through a new
Purchase Order.

Implementing Distributed Order Management Page 42

 PO Header, Line or Shipment
cancellation is Allowed from
the PO Summary form and via
Supplier Initiated Change
Order.
Requisition lines should be
returned to the Requisition
Pool, if Sales Order Line is not
PO, Line or Shipment fulfilled or closed. OM API to
Cancellation 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.
Notification will be sent to CSR. PO/Line Note that PO treats
cancellation: Backing Quantity decrease different
Partial PO Receipt(delivery) of a Requisition will be from Cancellation. Users
sent back to the can either completely cancel
Drop Ship Order causes the Sales
Requisition pool. the line or cancel the
Order Line to be split. A new
Sales Order Line is created for the remaining quantity after
unfulfilled order quantity. PO Shipment: if partial quantity is received.
partially received, the There is no partial
original Requisition
If PO shipment is canceled after cancellation.
line will be split. The
partial receipt, the backing
quantity in the
Requisition gets split. A new
original line will be
Requisition line is created and sent
reduced to quantity
back to the pool with the
received. The.
unfulfilled quantity.
remaining quantity
will be placed on a
The only open Sales Order Line new Requisition line.
linked to the PO Shipment will
now reference the new
Requisition line from the split.

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.

3.2.4. Accounting

Implementing Distributed Order Management Page 43

 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 Inventory’s Inter Company
relations functionality to automate I/C accounting. See Figure 4 and Figure 5.
COGS (3PS): $5
$10
Fulfillment Org (FO) FulfillmentOrg(FO)
$20 Transfer in Oracle Central I. $5
Sales Org (SO) in 3rd PartySystem
Customer
Price list price representing PO price
OracleCentralI . Fulfillment Org in 3rd
(modeled as a
SOB1/LE1/OU1 Party System LogicalSupplier)
SOB2/LE2/OU2 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
purposes, and (2) a Sales Org in the Oracle Central Instance that captures the
Customer’s 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

Implementing Distributed Order Management Page 44

 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 Inventory’s 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, let’s examine accounting entries in the DOM flow that are logged for the
Fulfillment Org and the Sales Org (Figure 5).
Time Transaction Description Sales Org Fulfillment Org Fulfillment Org
Accounting – OU1 Accounting – OU2 Accounting – OU2
(Oracle Central (Oracle Central Inst.) (3rd Party System)
Inst.)
T1 Sale and Shipment Dr OU2 Internal Receivable 5
in the Fulfillment Cr OU2 Internal Revenue 5
Org 3rd Party
Dr OU2 Internal COGS 5
System
Cr OU2 Inventory 5
T2 Receipt in RT: Receive in (Receiving Processor)
Dr OU2 Clearing 5
Fulfillment Org Fulfillment Org
Cr OU2 Internal Accrual 5
Oracle Central Inst Oracle Central
Receiving Desktop Instance
Form
T3 Deliver in RT: Deliver in
Fulfillment Org Fulfillment Org
Oracle Central Inst Oracle Central Inst
Receiving Desktop
Form MMT: PO receipt in
Fulfillment Org
(Accounting txn) (Cost processor)
(Logical PO receipt) Dr OU2 Inventory 5
Cr OU2 Clearing 5

MMT: Fulfillment
Org → Sales Org
(Accounting txn)
(I/C Invoicing)
(Logical I/C (Cost Processor) Dr I/C Receivable 10
shipment) Dr OU1 Inventory 10 Cr I/C Revenue 10
(Logical I/C receipt) Cr I/C Accrual 10
(Cost processor)
(I/C Invoicing) Dr I/C COGS 5
Dr I/C Accrual 10 Cr OU2 Inventory 5
Cr I/C Payable 10

Implementing Distributed Order Management Page 45

 MMT: Sales Org ->
Customer (Cost Processor)
(Accounting txn) Dr OU1 COGS 10
Cr OU1 Inventory 10
(Logical Sales Order
Issue)
(AR Invoice)
Dr OU1 Receivable 20
Cr OU1 Revenue 20

OU1 Reconciliation OU2 Reconciliation

Dr COGS 10 Dr Internal COGS 5
Dr Receivable 20 Dr I/C COGS 5
Cr I/C Payable 10 Dr Internal Receivable 5
Cr Revenue 20 Dr I/C Receivable 10
Cr Inventory 5
Cr Internal Accrual 5
Cr Internal Revenue 5
Cr I/C Revenue 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 company’s
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 company’s 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).

Implementing Distributed Order Management Page 46

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
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 company’s overall liabilities.
It should be setup as a separate natural account and should not be included in
summary accounts or account hierarchies for company’s 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

Implementing Distributed Order Management Page 47

• (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.

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

Implementing Distributed Order Management Page 48

 Customer. The associated financial flow includes one additional node: a Sales Org in
the Oracle Central Instance that captures the Customer’s order.
COGS (3PS): $5
$20 $5 FulfillmentOrg(FO)
Sales Org (SO)
in 3rd PartySystem
Customer
Price list is also a selling org PO price (modeled as a
OracleCentralI .
LogicalSupplier)
SOB1/LE1/OU1
SOB1/LE1/OU1

Logical receipt

Financial Flow
Physical Flow

Figure 6 Intra Company Accounting Flow

Now, let’s examine accounting entries in the Intra Company DOM flow (Figure 7).
Time Transaction Description Sales Org Fulfillment Org
Accounting – OU1 Accounting – OU1
(Oracle Central Inst.) (3rd Party System)
T1 Sale and Shipment Dr OU1 Internal Receivable 5
in the Fulfillment Cr OU1 Internal Revenue 5
Org 3rd Party
Dr OU1 Internal COGS 5
System
Cr OU1 Inventory 5
T2 Receipt in Sales RT: Receipt in (Receiving Processor)
Sales Org Dr OU1 Clearing 5
Org Oracle Central
Cr OU1 Internal Accrual 5
Inst - Receiving Oracle Central Inst
Desktop Form
T3 Deliver in Sales RT: Deliver in
Org Oracle Central Sales Org
Inst - Receiving Oracle Central
Desktop Form Inst

MMT: PO receipt
in Sales Org
(Accounting txn) (Cost processor)
(Logical PO Dr OU1 Inventory 5
receipt) Cr OU1 Clearing 5

MMT: Sales Org >

Customer
(Accounting txn)
(Logical Sales (Cost Processor)
Order Issue) Dr OU1 COGS 5
Cr OU1 Inventory 5

(AR Invoice)

Implementing Distributed Order Management Page 49

 Dr OU1 Receivable 20
Cr OU1 Revenue 20

OU1 Reconciliation
Dr Internal COGS 5
Dr COGS 5
Dr Internal Receivable 5
Dr Receivable 20
Cr Inventory 5
Cr Internal Accrual 5
Cr Internal Revenue 5
Cr Revenue 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
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 company’s
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 company’s 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

Implementing Distributed Order Management Page 50

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 company’s overall liabilities. It
should be setup as a separate natural account and should not be included in
summary accounts or account hierarchies for company’s 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)

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.

Implementing Distributed Order Management Page 51

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
$20 Sales Org (SO)
Customer
Price list designated as 3PW
OracleCentralI .
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 Description Sales Org
Accounting – OU1
(Oracle Central Inst.)
T1 Sale and
Shipment in the Dr OU1 Receivable 20
Sales Org Cr OU1 Revenue 20
Oracle Central
Dr OU1 COGS 5
Instance
Cr OU1 Inventory 5
Figure 9 Intra Company Accounting Entries (3PW Based DOM Flow)

Transaction T1 - Sale and Shipment in the Sales Org (Oracle Central Instance)

Implementing Distributed Order Management Page 52

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
o 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 Oracle’s Outbound 940/Inbound 945 implementation

o Changes on 3PW orders not permitted (cancellations only)
o No automatic transactions to maintain 3PW on-hand inventory in
the Oracle Central Instance o Reservations on the 3PW inventory
not supported

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

Implementing Distributed Order Management Page 53

Response (945), performs only shipments from the warehouse based on the requests
from the Oracle Central Instance, and maintains no accounting entries.

Implementing Distributed Order Management Page 54

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)

Implementing Distributed Order Management Page 55

 • Invoice Close Tolerance set to 100% (PO)
• 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)

Implementing Distributed Order Management Page 56

Implementing Distributed Order Management
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