Implement Distributed Order management

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

Implementing Distributed Order Management Page 1

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

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.


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.


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.


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.


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

Distributed Order Management - the basic flow without ATP and CTP capability

Pur

chas

ing

(Cor

e, iS

P)S

etup

Ord

. M

gmt.

(OM

, OIP

)

Receive the Order.

If the item belongs to one of the 3rd PartyApplications, then the Source Type of theline is defaulted to “External” to make it adrop ship, based on the “Item/Org” or “Line”based defaulting rules.PS: We can default the logical Org forSupplier if needed

Customer Order from iStore, Call Center, SalesOrder Pad, EDI/XML, Legacy, 3rd Party

Model each 3rd Party Module as aSeparate Supplier - S1, S2…Set up a Validation Organization - VOSet up items corresponding to thesesuppliers in VOSet up the sourcing rulesSetup Blanket Statements in Purchasingto create Reqs and POs

Run the Requisition Import Process. Asa part of this process the correctSupplier is defaulted based on :

1. Sourcing Rules2. Blanket Orders

and 3. ASL.

1

3

2

4

Create the Purchase Order

On approval the PO is created.The PO is then communicatedto the Supplier (3rd partyinstance) using EDI, XML,Email…

Purchase Order from OracleApplications Instance is receivedas a Sales Order in the 3rd Party

Application.All the Regular Processing is

done

6

On completion of the SalesOrder either a Shipment

Receipt or an ASN is sendto Oracle Applications

8

5

In iSupplier Portal

The changes to the Scheduled Ship Datefrom the Supplier can be made using theSupplier Change Order functionality.

7 Any Changes to the Ship Date andQuantities are made in SupplierSystem and then made in the

iSupplier portal

In Order Information Portal

The changes to the Scheduled ShipDates from Supplier are made to theExpected Ship Date of the OIP.

Customers can view order status in OrderInformation Portal

7'

7"

7'"

On receipt of the ASNor the Shipment

Receipt, purchasingupdates the relevant

PO tables and activatesthe OE Line Workflow

9

The OE Line Wflowthen completes the INVtxns - a receipt into thelogical Org and a Shipto Customer, so that

COGs allign up properly 10

11

Customers can view order status in OrderInformation Portal

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)


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


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.


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:


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


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)


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.


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


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 ‘ASET-ASCP’.


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.


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.


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.


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.


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.


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


Excerpts from the generated PO XML are shown below.



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)


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.

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

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.




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.


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)


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.


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


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.


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.


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


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.


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

Interface Approved

Req. PO Comments

Quantity Increase/ Decrease

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 PO Line: must not be canceled, finally closed. 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.

Requisition 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 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 3rd Party System.

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 Req’s and PO’s, then change is not allowed if all the PO’s or Releases are approved.

Complete Cancellation

Same as above. PO Header: can be in approved, rejected, frozen, reserved, closed for receiving or closed for invoicing state PO Shipment and Distribution: The

Requisition interface row will be deleted.

Requisition line will be canceled

PO Shipment will be canceled. PO revision number will be incremented.

If multiple Supply Source exists( Multiple Requisitions/POs linked to the same Sales Order Line) , then all of them are canceled. OM added a removable constraint that disallows a change if any one of the related PO’s or Releases is approved.


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.

New PO revision will be communicated to the supplier.

Schedule Ship Date

Allowed under following conditions: Requisition: not canceled or finally closed PO Header: must not be canceled, frozen, finally closed or In Process PO Line: must not be canceled, finally 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.

Requisition interface row will be updated with new Need by Date.

Requisition line will be updated with new Need By Date.

Need-by date will be updated on the PO shipment. PO revision number will be incremented. Change Order workflow will be invoked to approve and communicate change to the supplier.

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. OM added a removable constraint that disallows a change if any one of the related PO’s or Releases is approved.

Ship To Location

Allowed under following conditions: Requisition: not canceled or finally closed. PO Header: must not be canceled, frozen, finally closed or In Process PO Line: must not be canceled, finally 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.

Interface record will be updated with new deliver-to location.

Requisition line will be updated with new deliver-to location.

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 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. OM added a removable constraint that disallows a change if any one of the related PO’s or Releases is approved.

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

Validation: PO should not be Frozen or Finally Closed. 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.

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

OM added a removable constraint that disallows a change if any one of the related PO’s or Releases is approved.

Warehouse Warehouse changes are not allowed once the line is interfaced to Purchasing.

Not allowed

Not allowed Not allowed


Ordered UOM Ordered UOM changes are on allowed once the line is interfaced to Purchasing.

Not allowed

Not allowed Not allowed

SO Line split

User initiated Sales Order Line Split is not allowed once the line is interfaced to Purchasing.

Not Allowed.

Not Allowed.

Not Allowed.

Delete Lines

Sales Order Line Deletion not allowed once the line is interfaced to Purchasing. Exception is the Configured Item Deletions. Configured Item is a special case, where constraints are not checked when Configured Item is deleted.

Not Allowed.

Not Allowed.

Not Allowed.

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

• 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 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 Change

When Allowed (Validation Conditions)

Sales Order Approved Requisition

Comments

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 Autocreate form should not allow selecting RFQ as document type, if Requisition line is associated with a drop ship Sales Order.

Shipment Quantity increase/Shipment Quantity Decrease

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.

No impact. 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

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. Promise Date will be displayed in the Drop Ship Tab in OM. Sales Order Line is not updated.

Need-by date

Not allowed on PO Shipments with backing Sales Order demand.

No impact. No impact.

Ship-to Location

Not allowed from the Enter PO form if the Shipment is linked to a Drop Ship Sales Order.

No impact No impact

Delete Lines

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.

Requisition returned to Buyer’s Requisition pool. Can be sourced through a new Purchase Order.

PO, Line or Shipment Cancellation

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

Notification will be sent to CSR. 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/Line cancellation: Backing Requisition will be sent back to the Requisition pool. 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.

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.


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

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.

Sales Org (SO)Oracle Central I.SOB1/LE1/OU1

Fulfillment Org (FO)in Oracle Central I.

representingFulfillment Org in 3rd

Party SystemSOB2/LE2/OU2

Customer

Financial FlowPhysical Flow

$5PO price

$10Transfer

price$20

Price list

Logical receipt

COGS (3PS): $5Fulfillment Org (FO)in 3rd Party System

(modeled as aLogical Supplier)SOB2/LE2/OU2

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 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 Accounting – OU1 (Oracle Central Inst.)

Fulfillment Org Accounting – OU2 (Oracle Central Inst.)

Fulfillment Org Accounting – OU2 (3rd Party System)

T1 Sale and Shipment in the Fulfillment Org 3rd Party System

Dr OU2 Internal Receivable 5 Cr OU2 Internal Revenue 5 Dr OU2 Internal COGS 5 Cr OU2 Inventory 5

T2 Receipt in Fulfillment Org Oracle Central Inst Receiving Desktop Form

RT: Receive in Fulfillment Org Oracle Central Instance

(Receiving Processor) Dr OU2 Clearing 5 Cr OU2 Internal Accrual 5

T3 Deliver in Fulfillment Org Oracle Central Inst Receiving Desktop Form

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 OU1 Inventory 10 Cr I/C Accrual 10 (I/C Invoicing) Dr I/C Accrual 10 Cr I/C Payable 10

(Cost processor) Dr OU2 Inventory 5 Cr OU2 Clearing 5 (I/C Invoicing) Dr I/C Receivable 10 Cr I/C Revenue 10 (Cost processor) Dr I/C COGS 5 Cr OU2 Inventory 5


MMT: Sales Org -> Customer (Accounting txn) (Logical Sales Order Issue)

(Cost Processor) Dr OU1 COGS 10 Cr OU1 Inventory 10 (AR Invoice) Dr OU1 Receivable 20 Cr OU1 Revenue 20

OU1 Reconciliation OU2 Reconciliation Dr COGS 10 Dr Receivable 20 Cr I/C Payable 10 Cr Revenue 20

Dr Internal COGS 5 Dr I/C COGS 5 Dr Internal Receivable 5 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).

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


• (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 non-Oracle 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 Customer. The associated financial flow includes one additional node: a Sales Org in the Oracle Central Instance that captures the Customer’s order.

Sales Org (SO)is also a selling org

Oracle Central I.SOB1/LE1/OU1

Customer


$5PO price

$20Price list

Logical receipt

COGS (3PS): $5Fulfillment Org (FO)in 3rd Party System

(modeled as aLogical Supplier)SOB1/LE1/OU1

Figure 6 Intra Company Accounting Flow


Now, let’s examine accounting entries in the Intra Company DOM flow (Figure 7).


Fulfillment Org Accounting – OU1 (3rd Party System)

T1 Sale and Shipment in the Fulfillment Org 3rd Party System

Dr OU1 Internal Receivable 5 Cr OU1 Internal Revenue 5 Dr OU1 Internal COGS 5 Cr OU1 Inventory 5

T2 Receipt in Sales Org Oracle Central Inst - Receiving Desktop Form

RT: Receipt in Sales Org Oracle Central Inst

(Receiving Processor) Dr OU1 Clearing 5 Cr OU1 Internal Accrual 5

T3 Deliver in Sales Org Oracle Central Inst - Receiving Desktop Form

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)

(Cost processor) Dr OU1 Inventory 5 Cr OU1 Clearing 5 (Cost Processor) Dr OU1 COGS 5 Cr OU1 Inventory 5 (AR Invoice) 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 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.


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

Sales Org (SO)designated as 3PW

Oracle Central I.SOB1/LE1/OU1

Customer


$20Price list

COGS: $5

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


T1 Sale and Shipment in the Sales Org Oracle Central Instance

Dr OU1 Receivable 20 Cr OU1 Revenue 20 Dr OU1 COGS 5 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)

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 Response (945), performs only shipments from the warehouse based on the requests from the Oracle Central Instance, and maintains no accounting entries.


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)


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