Академический Документы
Профессиональный Документы
Культура Документы
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
1. INTRODUCTION
A Distributed Order Management system integrates the fragmented demand and supply chains to capture demand from all channels, brokers the demand to multiple internal and external fulfillment systems, and monitors and manages the fulfillment process across the supply chain. Oracle E-Business Suite fully supports Distributed Order Management. The benefits of the Distributed Order Management (DOM), the problems it solves, and an overview of support for DOM in Oracles E-Business Suite are explained in the white paper titled Distributed Order Management. This topical essay is more detailed and is targeted towards customers and consultants implementing DOM systems. The document explains the capabilities Oracle E-Business Suite provides to solve Distributed Order Management requirements.
Page 1
2. BUSINESS CASE
The promise of a DOM system is that is unifies customer fulfillment process across companys fragmented systems (ERP systems, legacy systems) and across transactions with trading partners (Drop Ship, 3PLs, Carriers). The E-Business Suite delivers on this promise (Figure 1 - DOM architecture).
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 o Using Oracle E-Business Suite Modules Brokering orders to 3rd Party Systems (SAP, Peoplesoft, Legacy)
External Fulfillment Flows o Brokering orders to Trading Partners (Drop Ship, 3PLs, Carriers)
Page 2
Internal fulfillment flows using Oracles E-Business Suite modules are already well documented, as are external fulfillment flows, such as Drop Ship, where orders are brokered to trading partners for fulfillment. This topical essay addresses the requirements of a typical DOM system for internal fulfillment by brokering orders to 3rd Party Systems. The essay shows how Oracle E-Business Suite framework for drop ship orders can be used to model a Distributed Order Management flow.
Page 3
3. IMPLEMENTATION
This document focuses on the internal fulfillment flows where orders are brokered to 3rd Party Systems (SAP, Peoplesoft, Legacy). We first explain how E-Business suite captures orders from all demand channels. Then, we examine in detail the most common DOM fulfillment flow where Oracle E-Business instance captures the order, generates a Purchase Order (PO), sends it for a fulfillment to a 3rd Party System using industry standard XML, and tracks its progress. Finally, we explain change management features in the DOM fulfillment flow, support for configurations and kits, accounting issues, and address some frequently asked questions.
Page 4
Page 5
Page 6
Customer Order from iStore, Call Center, Sales Order Pad, EDI/XML, Legacy, 3 rd Party 2
7'"
Distributed Order Management - the basic flow without ATP and CTP capability
Receive the Order.
If the item belongs to one of the 3 rd Party Applications, then the Source Type of the line is defaulted to External to make it a drop ship, based on the Item/Org or Line based defaulting rules. PS: We can default the logical Org for Supplier if needed Run the Requisition Import Process. As a part of this process the correct Supplier is defaulted based on : 1. Sourcing Rules 2. Blanket Orders and 3. ASL. Create the Purchase Order
In Order Information Portal The changes to the Scheduled Ship Dates from Supplier are made to the Expected Ship Date of the OIP. 7"
The OE Line Wflow then completes the INV txns - a receipt into the logical Org and a Ship to Customer, so that COGs allign up properly
11
10
On approval the PO is created. The PO is then communicated to the Supplier (3 rd party instance) using EDI, XML, Email
In iSupplier Portal The changes to the Scheduled Ship Date from the Supplier can be made using the Supplier Change Order functionality.
On receipt of the ASN or the Shipment Receipt, purchasing updates the relevant PO tables and activates the OE Line Workflow 9
Model each 3 rd Party Module as a Separate Supplier - S1, S2 Set up a Validation Organization - VO Set up items corresponding to these suppliers in VO Set up the sourcing rules Setup Blanket Statements in Purchasing to create Reqs and POs Any Changes to the Ship Date and Quantities are made in Supplier System and then made in the iSupplier portal
7'
Setup
6 Purchase Order from Oracle Applications Instance is received as a Sales Order in the 3 rd Party Application. All the Regular Processing is done
8 On completion of the Sales Order either a Shipment Receipt or an ASN is send to Oracle Applications
The Figure 2 shows the DOM flow where orders are captured from multiple channels and brokered for fulfillment in a form of a PO to 3rd Party Systems. Note that the flow is modeled using standard Drop Ship flow of Oracle Order Management. The only difference is that 3rd Party System is modeled as a supplier. To demonstrate this flow, we setup two ERP instances (Figure 3): Central DOM Instance running E-Business Suite 3rd Party System Instance (simulated by running another instance of EBusiness Suite)
Page 7
The flow consists of 13 steps: 1. 2. 3. 4. 5. 6. 7. 8. 9. (Central Instance) Create/Import Sales Order (Central Instance) Import Requisition (Central Instance) Create Purchase Order (Central Instance) Approve Purchase Order (Central Instance) Transmit PO (3rd Party Instance) Import PO (3rd Party Instance) Fulfill Purchase Order (3rd Party Instance) Send ASN (Central Instance) Import ASN
10. (Central Instance) Perform Logical Receipt Based On ASN 11. (Central Instance) Generate Customer Invoice 12. (Central Instance) Close Order 13. (Customer) Check Order Progress In Order Information Portal
Page 8
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.
Page 9
Note that the source type is External to invoke the OMs Drop Ship flow on which DOM flow is based.
For items shipped through DOM/Drop Ship flow, the source type can be defaulted to External by setting organizational item attribute Default SO Source Type to External (Organization Item window, Order Management Tab). The initial sequence for defaulting the Source Type is:
Page 10
1. 2.
The organizational item attribute, Default SO Source Type If the value of Default SO Source Type is NULL, it defaults to Internal
If you do not wish to default a value for the Source Type field for Sales Order Lines, you must disable the seeded defaulting rules for the order line attribute Source Type. Order Management seeded constraints will prevent you from making changes to the Source Type value if the branch on source type workflow activity within the Create Supply - Line workflow subprocess has completed. In our example, M1 defaulted as the Receiving Organization where supplier sourcing rules are defined and where logical receipt is performed once an ASN is received from the supplier (3rd Party System). M1 is a logical warehouse because it performs logical receipt of 3rd Party System shipments. Making M1 a separate logical warehouse isolates the costs of items shipped by the 3rd Party System from the items that are physically stocked. Order Management does not require the use of a special shipping organization for 3rd party shipments, but it is recommended to do so. The logical warehouse should be defined as a shipping org and items shipped from 3rd Party Systems should be enabled for Drop Ship. Now, we book the order and examine the workflow of the order line we just created:
The workflow stopped at the Create Supply Line subprocess. The Create Supply Line subprocess below shows that the workflow proceeded down the Drop Ship branch because the order line source type was External.
Page 11
Drop ship flow on which DOM flow is based proceeds until the Purchase Release Deferred activity, which needs to be run by the Workflow Background process. At customer sites, Workflow Background process should be setup to run in regular time intervals. In our demo, we manually run the Workflow Background process for the OM Order Line as shown below.
Page 12
In the previous step, the order was created and the order line workflow proceeded down the Drop Ship flow branch, which in turn created records in Requisitions interface table (PO_REQUISITIONS_INTERFACE_ALL). The next step is to import the Requisition from the Requisitions interface table. Concurrent program Requisition Import needs to be run. At customer sites, Requisition Import should be setup to run in regular time intervals. In our demo, we show how to manually run the Requisition Import in the screenshot below.
After Requisition Import concurrent program completes, the Requisition is created in PO_REQUISITION_HEADERS_ALL and PO_REQUISITION_LINES_ALL tables. We can find the Requisition number by navigating to Drop Ship Tab of the Additional Line Information Action as shown below.
Page 13
Note that the supplier Star Gate Ltd, which in our setup represents the 3rd Party System, defaulted on the Requisition. PO determined the supplier (3rd Party System) based on the sourcing rules setup for the 00 Drop Ship Item in the logical DOM organization M1 (see screenshots below).
Page 14
The profile option MRP: Default Sourcing Assignment Set sets the assignment set used in drop ship / DOM flows. In our demo, we set this profile option to ASETASCP.
Page 15
The next step after Requisition is imported is to create Purchase Order from the Requisition. Navigate to Purchasing AutoCreate form and type in the Requisition number.
After the Requisition is found, creating PO is straightforward as shown below. Note that the supplier and supplier site (3rd Party System) default from the Requisition.
Page 16
Take note of the addresses that have been defaulted on the PO from the Sales Order. At the header level, the bill-to and ship-to are the addresses of the company itself (Central Instance) and not the addresses of the customer (Business World). However, at the line level the address of the customer is defaulted on the PO.
Page 17
In 11i.10, support for Requisitions and Purchase Orders generated from DOM/Drop Ship Sales Orders has been significantly enhanced. Following attributes are now cascaded from the Sales Order to the Requisition and Purchase Order and are included in XML/EDI PO documents sent to the 3rd Party System: Ship To Customer Name Ship To Customer Contact Name Ship To Customer Contact Phone Number Ship To Contact Fax Number Ship To Customer Contact E-mail Shipping Instructions Packing Instructions Shipping Method (= Freight Carrier + Mode of Transport + Service Level) Customer PO Customer PO Number Customer PO Line Number Customer PO Shipment Number Customer Item Description Deliver To Customer Name Deliver To Customer Address Deliver To Customer Contact Name Deliver To Customer Contact Phone Number Deliver To Customer Contact Fax Number Deliver To Customer Contact E-mail
Accordingly, 11i.10 features a new Drop Ship tab in the Shipments block of the PO form (not shown) with the following information: Sales Order Number, Sales Order Line Number, Sales Order Line Order Quantity, Sales Order Line Shipped Quantity, Sales Order Line Status, Ship To Customer Name, Ship To Customer Contact. In addition, new menu option View Sales Order enables users to view Sales Order information, such as, customer or shipping details, for Purchase Order s that reference DOM/Drop Ship order lines.
Page 18
The next step is to approve the PO (screenshots below). Note that steps 2-4, from Requisition Import to PO Approval can be automated as explained in section 3.3.1.
Page 19
Once the PO is approved, the next step is to transmit the PO document to the 3rd Party System. PO supports both industry standard XML (OAGI PROCESS_PO_007) and EDI (850) as delivery mechanisms. For more information see Oracle XML Gateway Users Guide and Oracle eCommerce Gateway Users Guide.
Page 20
For demo purposes we chose XML delivery. When XML is chosen as PO delivery mechanism, the PO starts the Send XML Document Workflow process to deliver the PO XML document to the 3rd Party System.
The 3rd Party System needs to be setup in the XML Gateway in order to be able to receive Purchase Orders. Like in the case of the Drop Ship flow, we model the 3rd Party System as a supplier Star Gate Ltd in the XML Gateway setup (screenshots below).
Page 21
Page 22
Page 23
As noted earlier, the ship-to address of the customer is specified at the line level. However, the unique identifier of the customer site at the line level (PARTNRIDX field) is not populated in the generated PO XML document. This is a gap in the current implementation because some 3rd Party Systems may not process the PO XML correctly if PARTNRIDX field is not populated.
Page 24
Once the PO XML is sent, the flow continues in the 3rd Party System. The first step in the 3rd Party System is to import the PO XML document. In our demo, we used another Oracle instance as the 3rd Party System, and we used standard Oracle Import feature of Oracle Order Management to import the PO generated in the central DOM instance. We setup the XML gateway in the 3rd Party System to receive the XML PO (screenshot below). In SAP, Peoplesoft, or legacy systems, equivalent XML setups would be needed.
Note that in the 3rd Party System, the central DOM instance is modeled as a customer Vision Operations. With the correct XML Gateway setup, Oracle Order Import can import Purchase Orders as shown in the workflow below.
Page 25
The imported Sales Order can be found in the 3rd Party System by querying for the PO generated in the central DOM instance.
As specified in the PO XML document, the header level ship-to address is not that of the end customer Business World, but that of the company in Central Instance that is modeled as a customer Vision Operations in the 3rd Party Systems.
Page 26
Note that the Order Import incorrectly defaults the ship-to address at the line level to the address at the header level (screenshot below). As explained earlier, this is caused by the missing PARTNRIDX field in the generated PO XML document. This problem needs to be fixed in the Purchasing. Note, however, that other 3rd Party Systems and future versions of Oracle E-Business Suite may be able to able to import the PO XML document even if PARTNRIDX field is missing. In this case, the customer name and the address on the PO XML document should be matched against the list of existing customers and addresses specified for that customer (this includes addresses of the end customers if customer relations are setup). If there is a match with customer only but not with address, then a new address should be created on the fly for that customer. If there is no match for either customer or the address, then both customer and address should be created on the fly.
Page 27
In this step, 3rd Party System fulfills the order. This may include getting the items from stock or manufacturing them or any other form of fulfillment. The items on the order are then shipped to the customer (Business World) and an ASN is sent to the central DOM instance to inform it of the items shipped.
Oracle Purchasing supports several ways for importing ASNs from 3rd Party Systems: XML, EDI, iSupplier Portal. The ASN is used to perform a logical receipt for invoicing and costing purposes. The receipt is a logical receipt because the items are not physically sent to the central DOM instance but to the end customer. For the demo of ASN functionality, we used Oracle iSupplier Portal. Note, however, that for real DOM implementation you may want to use EDI of XML in order to eliminate the need for users of 3rd Party Systems to interact with the iSupplier Portal running on the Central DOM Instance. Following screenshots show how ASNs are created in the iSupplier portal.
Page 28
Page 29
Page 30
Once an ASN is created in the iSupplier Portal, its status can be reviewed as shown below. Initially, the processing status will be Pending until the Receiving Transaction Processor is run that transfers records from Receiving interface table to Receiving headers and lines tables.
Page 31
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.
Page 32
After ASN has been imported into the central DOM instance, a logical receipt can be performed in the Receiving. The receipt is logical because physical transfer of items is performed from the 3rd Party System to the customer and not from the 3rd Party System to the Central DOM Instance. Open Find Expected Receipts form by navigating to Purchasing Receiving Receipts and search by PO number in logical DOM organization M1.
Page 33
Receipts form will open with item and quantities specified on the imported ASN.
Page 34
Note that steps 10-11, from ASN Import to Logical Receipt can be automated as explained in section 3.3.2. Drop Ship Tab of the Additional Line Information Action shows that quantity 1 of 00 Drop Ship Item has been received.
Page 35
Invoicing of DOM orders works in the same way as invoicing of standard orders because the same order line workflow is used.
Currently, there is no support for importing freight charges incurred by the supplier (3rd Party System) and any such charges would need to be manually entered in OM as standard charges.
Page 36
After invoicing is done, the Order Line workflow closes the order line, which in turn triggers the closing of the whole order (once all the lines are closed).
Page 37
While we put checking of the order progress as the last step in the flow, the customer (Business World) can check the order progress in the Oracle Order Information Portal at any point in the flow as soon as the order is entered.
Note that Shipment details are currently not available in the Order Information Portal for Drop Ship flow and consequently for the DOM flow. This gap should be fixed in one of the subsequent releases. This was the last step of the DOM flow. In the next section, we explain how Oracle Order Management supports change management for DOM orders.
Page 38
Page 39
In 11i.10, Purchasing allows changes on a Purchase Orders even if it is approved. Changes on approved Purchase Orders will re-trigger the approval process and the changes may or may not be approved. If changes are not approved, a notification will be sent to the customer service representative (CSR). If the PO changes are approved, then the changed PO will be sent to the 3rd Party System. The 3rd Party System can always reject the changes if the Sales Order cannot be changed or if the goods have shipped. For DOM orders this could cause a problem as the Sales Order Lines in the 3rd Party System could have been canceled already. To avoid this potential problem, OM introduced new constraint to restrict the Sales Order Line changes once the Purchase Order is approved. Depending on the business flows supported and the integration with 3rd Party Systems, customers may choose to disable this constraint to allow more flexibility for Sales Order changes provided they also take the responsibility for handling any exceptions. Note that in the 11i.10, there is no need for users to run the Sales Order Purchase Discrepancy Report because Sales Orders and associated Purchase Orders are always synchronized. Consequently, the Sales Order Purchase Discrepancy Report is no longer available. The following table shows how data changes are handled on the Sales Order:
Sales Order Change When Allowed (Validation Conditions) Update will be allowed under the following conditions: Requisition: not canceled or finally closed PO Header: must not be in canceled, frozen, finally closed or In Process 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. Req. Interface Requisitio n Interface row will be updated with revised quantity. Approved Req. Requisition Line and Distribution will be updated with revised quantity. PO 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. PO Shipment will be canceled. PO revision number will be incremented. Comments If multiple Supply Source exists (Example: Multiple Requisitions/POs linked to the same Sales Order Line), then special logic is used to select Requisitions that need to be changed. Special Logic: - First, change the Requisitions that do not have PO's - Second, change the PO's that are not approved or partially received or ASN received. - Last, change the PO's for which the changes are allowed. Note that there could be earlier quantity decreases that could have resulted in canceled Requisitions. OM added a removable constraint that disallows a change if the PO or Release is approved. If there are multiple Reqs and POs, then change is not allowed if all the POs or Releases are approved.
Same as above. Complete Cancellation PO Header: can be in approved, rejected, frozen, reserved, closed for receiving or closed for invoicing state PO Shipment and Distribution: The
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 POs or Releases is approved.
Page 40
greater of quantity received or quantity billed is lesser than or equal to quantity ordered. Cancel date needs to be within effective dates of the accounting period. If Partial or full quantity is Received, changes are not allowed. If ASN received for Partial or Full Quantity, change is not allowed. Allowed under following conditions: Requisition: not canceled or finally closed PO Header: must not be canceled, frozen, finally closed or In Process Schedule Ship Date 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. Allowed under following conditions: Requisition: not canceled or finally closed. PO Header: must not be canceled, frozen, finally closed or In Process Ship To Location 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. 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.
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. PO revision number will be incremented. If the PO was originally in an approved state, Change Order workflow will be invoked to approve and communicate change to the supplier. If PO is not approved, No Impact. If PO is approved, OM will call a PO API to trigger the Change PO process.
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 POs or Releases is approved.
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 POs 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 Warehouse
No Impact
No Impact
OM added a removable constraint that disallows a change if any one of the related POs or Releases is approved.
Warehouse changes are not allowed once the line is interfaced to Purchasing.
Not allowed
Not allowed
Not allowed
Page 41
Ordered UOM changes are on allowed once the line is interfaced to Purchasing. User initiated Sales Order Line Split is not allowed once the line is interfaced to Purchasing. Sales Order Line Deletion not allowed once the line is interfaced to Purchasing. Exception is the Configured Item Deletions. Configured Item is a special case, where constraints are not checked when Configured Item is deleted.
Delete Lines
Page 42
Deliver To Customer Contact Phone Number Deliver To Customer Contact Fax Number Deliver To Customer Contact E-mail
Splitting of the Requisition is not allowed, and Requisitions linked to a Sales Order cannot be canceled or finally closed. In addition, Requisitions cannot be returned to the Requestor. Normally, Buyers can return the Requisitions to the Requestor and no action will be performed. Following table shows how the change management is handled for the Drop Ship Purchase Orders. Note that the same change logic applies to Releases as well.
Page 43
When Allowed (Validation Conditions) Not Applicable because a Requisition line tied to a Drop Ship Sales Order Line cannot be selected for negotiation.
Approved Requisition Autocreate form should not allow selecting RFQ as document type, if Requisition line is associated with a drop ship Sales Order. No impact.
Comments
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.
Promise Date
Allowed, based on existing validations on the Enter PO form, PO Change API, Supplier Change order. Not allowed on PO Shipments with backing Sales Order demand. Not allowed from the Enter PO form if the Shipment is linked to a Drop Ship Sales Order. Allowed, when Purchase Order is not approved, Requisition returned to Requisition pool.
Notification will be sent to the Requisition preparer. The assumption is that the CSR is the Requisition preparer. No impact.
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 will be displayed in the Drop Ship Tab in OM. Sales Order Line is not updated.
No impact.
Need-by date
No impact
No impact
Ship-to Location
Delete Lines
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.
Requisition returned to Buyers Requisition pool. Can be sourced through a new Purchase Order. PO/Line cancellation: Backing Requisition will be sent back to the Requisition pool. 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.
Page 44
Page 45
3.2.4. Accounting
In this section, we discuss how accounting is handled in a DOM flow. The DOM flow is based on the Drop Ship flow and accounting is similar to Drop Ship accounting. However, there are some important differences. The way accounting is done depends on whether the Sales Organization in the Oracle Central Instances and the Fulfillment Organization in the 3rd Party System are in the same company (Operating Unit) or not. Accordingly, accounting flows are divided in Inter Company and Intra Company flows.
All three of these requirements can be met by using Inventorys Inter Company relations functionality to automate I/C accounting. See Figure 4 and Figure 5.
$10 Transfer price COGS (3PS): $5
Fulfillment Org (FO) in Oracle Central I. representing Fulfillment Org in 3rd Party System SOB2/LE2/OU2
Customer
$5 PO price
Logical receipt
In this flow, the physical transfer of goods occurs between the 3rd Party System modeled as a Logical Supplier and the Customer. The associated financial flow includes two additional nodes: (1) a Fulfillment Org in the Oracle Central Instance setup to represent the Fulfillment Org in the 3rd Party System for I/C accounting
Page 46
purposes, and (2) a Sales Org in the Oracle Central Instance that captures the Customers order. In order to enable I/C transactions and I/C invoicing in the Inter Company DOM flow, I/C Relations need to be setup in Intercompany Relations form (Inventory > Setup > Organizations > Intercompany Relations). An I/C relation needs to be setup between the OU2/Fulfillment Org and OU1/Sales Org in the Oracle Central Instance. With this setup, liability and revenue are automatically transferred from OU2/Fulfillment Org to OU1/Sales Org after the logical delivery of goods in the Fulfillment Org in the Oracle Central Instance (a concurrent program needs to be run to perform logical I/C accounting between Fulfillment and Sales Orgs). In 11.5.10, accounting scenarios more complex than the one shown in Figure 4 are supported with Inventorys new Transaction Flow functionality. With Transaction Flows, any number of intermediate financial nodes can be added between the Source and Destination OUs. Transaction flows map the financial path identifying all the Operating Units/Inventory Orgs that are involved in the transfer of assets from the point of procurement through to the final selling organization. Now, lets examine accounting entries in the DOM flow that are logged for the Fulfillment Org and the Sales Org (Figure 5).
Time Transaction Description Sales Org Accounting OU1 (Oracle Central Inst.) Fulfillment Org Accounting OU2 (Oracle Central Inst.) Fulfillment Org Accounting OU2 (3rd Party System)
Dr OU2 Internal Receivable 5 Cr OU2 Internal Revenue 5 Dr OU2 Internal COGS Cr OU2 Inventory 5 5
T1
T2
T3
Sale and Shipment in the Fulfillment Org 3rd Party System Receipt in Fulfillment Org Oracle Central Inst Receiving Desktop Form Deliver in Fulfillment Org Oracle Central Inst Receiving Desktop Form
RT: Receive in Fulfillment Org Oracle Central Instance RT: Deliver in Fulfillment Org Oracle Central Inst MMT: PO receipt in Fulfillment Org (Accounting txn) (Logical PO receipt) MMT: Fulfillment Org Sales Org (Accounting txn) (Logical I/C shipment) (Logical I/C receipt)
(Cost Processor) Dr OU1 Inventory 10 Cr I/C Accrual 10 (I/C Invoicing) Dr I/C Accrual 10 Cr I/C Payable 10
10 10
Page 47
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
Dr COGS Dr Receivable Cr I/C Payable Cr Revenue 10 20 10 20
OU2 Reconciliation
Dr Internal COGS 5 Dr I/C COGS 5 Dr Internal Receivable 5 Dr I/C Receivable 10 Cr Inventory Cr Internal Accrual Cr Internal Revenue Cr I/C Revenue
5 5 5 10
Figure 5 Inter Company Accounting Entries Transaction T1 - Sale and Shipment in the Fulfillment Org OU2 (3rd Party System)
At the time of sale and shipment in the 3rd Party System, OU2 Inventory account is credited and an Internal COGS account debited with the amount of cost of goods sold. In addition, an Internal Receivable account is debited and an Internal Revenue account credited at the PO price. Note that accounts for COGS, Receivables, and Revenues need to be specially designated as Internal accounts because the sale is made within the same OU from Fulfillment Org in the 3rd Party System to Fulfillment Org in the Oracle Central Instance. For the same reason, the PO price should always be the same as the COGS in the 3rd Party System. Internal COGS, Receivables, and Revenues should not be included in the companys overall COGS, Receivables, and Revenue accounts. They should be setup as separate natural accounts and should not be included in summary accounts or account hierarchies for companys COGS, Receivables, and Revenues.
Transaction T2 - Receipt in Fulfillment Org OU2 (Oracle Central Instance)
The Fulfillment Org in the Oracle Central Instance is a logical organization representing the actual Fulfillment Org in the 3rd Party System. It is necessary to have this logical Fulfillment Org in order to enable the automatic Inter Company accounting and invoicing. The logical Fulfillment Org in the Oracle Central Instance and the actual Fulfillment Org in the 3rd Party System should use the same value for the company segment in their accounts and accounting entries should be imported into the same Set of Books (sharing the same Chart of Accounts and Accounting Calendar). Once an ASN is received from the 3rd Party System or a logical receipt is manually performed in the Fulfillment Organization (Oracle Central Instance), accounting
Page 48
entry is made by the Receiving Processor in the Oracle Central Instance to debit OU2 Clearing account and credit the Internal Accrual account at the PO price. Note that the Accrual account needs to be designated as an Internal account because no actual liability is incurred against another company or external entity. Internal Accrual account balance should not be counted towards companys overall liabilities. It should be setup as a separate natural account and should not be included in summary accounts or account hierarchies for companys liabilities. Purchasing Account Generator Workflow needs to be customized to default the A/P Accrual account to the Internal Accruals account for receipts in the logical Fulfillment Org. There is one important difference between Drop Ship and DOM flows with regards to accounting. In the Drop Ship flow, the liability accrued in the Accruals account is transferred to the Payables account once an invoice is received from the Supplier and matched against the Purchase Order. In the DOM flow, there should be no invoicing between the Fulfillment Org in the 3rd Party System and its representation Fulfillment Org in the Oracle Central Instance. This can be achieved by setting the item attribute Invoice Close Tolerance to 100% (Master Items form, Purchasing tab) for DOM items in the Fulfillment Org. With Invoice Close Tolerance set to 100%, Purchase Orders will be automatically closed after receipt without waiting for an invoice to be matched in the Payables. In the DOM, balance in the Internal Accruals account is never transferred to the Payable account since invoices are never received. Instead, it is eliminated against balances in the Internal Receivables account during the manual consolidation process at the GL period close. Internal Accruals and Internal Receivables can be mapped to the same natural account to facilitate the elimination process. Similarly, Internal COGS and Internal Revenues can be mapped to the same natural account.
Transaction T3 Deliver in Fulfillment Org OU2 (Oracle Central Instance)
At deliver transaction in Receiving, several accounting transactions occur. First, OU2 Clearing Account is credited and Inventory account debited at the PO price. At this point, the goods are logically transferred from the 3rd Party System to the Oracle Central Instance (remember that at transaction T1, the same Inventory account was credited when goods were physically shipped). Next, a Concurrent Program is run to perform automatic Inter Company accounting between the Fulfillment Org and the Sales Org in the Oracle Central Instance based on the I/C Relations setup: (Cost Processor) OU2 Inventory account credited and I/C COGS account debited at the PO price. (Cost Processor) OU1 Inventory debited and I/C Accrual account credited at the Transfer price (I/C Invoicing) OU2 I/C Revenues credited and I/C Receivables debited at Transfer price
Page 49
(I/C Invoicing) OU1 I/C Accruals debited and I/C Payables credited at the Transfer price
Note that the accounting entry for OU2 I/C COGS is recorded at the correct amount of PO price, which was set to be the same as the COGS in the Fulfillment Org in the 3rd Party System. OU2 I/C Receivables match the OU1 I/C Payables at the Transfer price, and OU2 I/C Revenue is recognized at the Transfer price as well. Depending on the legal arrangement between the Sales Org and Fulfillment Org, taxes may or may not need to be charged on the I/C invoices. Finally, accounting entries for transfer of goods from the Sales Org to the Customer are made. OU1 Inventory account is credited and COGS account debited at the Transfer price, while OU1 Revenue account is credited and Receivables debited at the Sales Order Price List price. Accounting entries in the Fulfillment Org (3rd Party System) may be recorded in the same Set of Books as accounting entries in the Sales Org (Oracle Central Instance) or in a separate Set Of Books in the same Oracle GL. Both of these cases are supported by setting up the Fulfillment Org in the Oracle Central Instance to record its accounting entries in the same Set of Books as the Fulfillment Org in the 3rd Party System (shared Chart of Accounts and Accounting Calendar). Accounting entries in the Fulfillment Org (3rd Party System) can also be recorded in a nonOracle GL, but in this case accounting entries made in the Fulfillment Org in the Oracle Central Instance need to be imported into the same non-Oracle GL and Set of Books.
Page 50
In this scenario, accounting entries are recorded in the Fulfillment Org (3rd Party System) and are imported into the same General Ledger and Set of Books as the accounting entries of the Sales Org (Oracle Central Instance). The accounting entries need to be imported into the same General Ledger because Fulfillment Org and Sales Org belong to the same Operating Unit. In the Intra Company accounting flow shown in the Figure 6, physical transfer of goods occurs between the 3rd Party System (modeled as a Logical Supplier) and the Customer. The associated financial flow includes one additional node: a Sales Org in the Oracle Central Instance that captures the Customers order.
COGS (3PS): $5 $20 Price list
Sales Org (SO) is also a selling org Oracle Central I. SOB1/LE1/OU1
Customer
$5 PO price
Logical receipt
Page 51
Now, lets examine accounting entries in the Intra Company DOM flow (Figure 7). Time T1 Transaction Sale and Shipment in the Fulfillment Org 3rd Party System Receipt in Sales Org Oracle Central Inst - Receiving Desktop Form Deliver in Sales Org Oracle Central Inst - Receiving Desktop Form Description Sales Org Accounting OU1 (Oracle Central Inst.) Fulfillment Org Accounting OU1 (3rd Party System)
Dr OU1 Internal Receivable 5 Cr OU1 Internal Revenue 5 Dr OU1 Internal COGS Cr OU1 Inventory 5 5
T2
T3
RT: Receipt in Sales Org Oracle Central Inst RT: Deliver in Sales Org Oracle Central Inst MMT: PO receipt in Sales Org (Accounting txn) (Logical PO receipt) MMT: Sales Org > Customer (Accounting txn) (Logical Sales Order Issue)
(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 Cr Internal Accrual Cr Internal Revenue Cr Revenue
5 5 5 20
Figure 7 Intra Company Accounting Entries Transaction T1 - Sale and Shipment in the Fulfillment Org (3rd Party System)
At the time of sale and shipment in the 3rd Party System Fulfillment Org, Inventory account is credited and an Internal COGS account debited with the amount of cost of goods sold. In addition, an Internal Receivable account is debited and an Internal Revenue account credited at the PO price. Note that accounts for COGS, Receivables, and Revenues need to be specially designated as Internal accounts because the sale is made within the same Operating Unit from Fulfillment Org in the 3rd Party System to Sales Org in the Oracle Central Instance. For the same
Page 52
reason, the PO price should always be the same as the COGS in the 3rd Party System. Internal COGS, Receivables, and Revenues should not be included in the companys overall COGS, Receivables, and Revenue accounts. They should be setup as separate natural accounts and should not be included in summary accounts or account hierarchies for companys COGS, Receivables, and Revenues.
Transaction T2 - Receipt in Sales Org (Oracle Central Instance)
Since Sales Org in the Oracle Central Instance and the Fulfillment Org in the 3rd Party System are in the same Operating Unit, they should use the same value for the company segment in their accounts. In addition, accounting entries in the Sales Org and Fulfillment Org should be imported into the same Set of Books (sharing the same Chart of Accounts and Accounting Calendar). Once an ASN is received from the 3rd Party System or a logical receipt is manually performed in the Sales Org (Oracle Central Instance), accounting entry is made by the Receiving Processor in the Oracle Central Instance to debit OU1 Clearing account and credit the Internal Accrual account at the PO price. Note that the Accrual account needs to be designated as an Internal account because no actual liability is incurred against another company or external entity. Internal Accrual account balance should not be counted towards companys overall liabilities. It should be setup as a separate natural account and should not be included in summary accounts or account hierarchies for companys liabilities. Purchasing Account Generator Workflow needs to be customized to default the A/P Accrual account to the Internal Accruals account for logical receipts in the Sales Org. There is one important difference between Drop Ship and DOM flows with regards to accounting. In the Drop Ship flow, the liability accrued in the Accruals account is transferred to the Payables account once an invoice is received from the Supplier and matched against the Purchase Order. In the DOM flow, there should be no invoicing between the Fulfillment Org in the 3rd Party System and the Sales Org in the Oracle Central Instance since they are in the same Operating Unit. This can be achieved by setting the item attribute Invoice Close Tolerance to 100% (Master Items form, Purchasing tab) for DOM items in the Sales Org. With Invoice Close Tolerance set to 100%, Purchase Orders will be automatically closed after receipt without waiting for an invoice to be matched in Payables. In the DOM, balance in the Internal Accruals account is never transferred to the Payable account since invoices are never received. Instead, it is eliminated against balances in the Internal Receivables account during the manual consolidation process at the GL period close. Internal Accruals and Internal Receivables can be mapped to the same natural account to facilitate the elimination process. Similarly, Internal COGS and Internal Revenues can be mapped to the same natural account.
Transaction T3 Deliver in Sales Org (Oracle Central Instance)
Page 53
At deliver transaction in Receiving, several accounting transactions occur. First, OU1 Clearing Account is credited and Inventory account debited at the PO price. At this point, the goods are logically transferred from the 3rd Party System to the Oracle Central Instance (remember that at transaction T1, the same Inventory account was credited when goods were physically shipped). Then, accounting entries for transfer of goods from the Sales Org to the Customer are made. OU1 Inventory account is credited and COGS debited at the Transfer price while OU1 Revenue account is credited and Receivables debited at the Sales Order Price List price. Note that Fulfillment Org in the 3rd Party System does not charge taxes to the Sales Org in Oracle Central Instance because they are in the same Operating Unit and no I/C invoices are generated.
Page 54
Accounting entries not maintained in the 3rd Party System It is possible for the 3rd Party System to maintain no accounting entries. This is typically a case with the 3rd Party Warehouse systems (3PWs). 3PWs provide the warehouse storage space and manage the transportation process but do not own the Inventory. Consequently, they do not keep the track of Receivable, Revenues of COGS. The Sales Org in the Oracle Central Instance is the one that owns the Inventory and maintains all associated accounting entries.
The communication between the Oracle Central Instance and 3PWs is different from the typical Drop Ship based DOM flow communication because it does not use Purchase Order and ASN documents. Instead, Oracle Central Instance and 3PWs communicate through XML Shipment Requests (equivalent of X12 940) and XML Shipment Responses (equivalent of X12 945). In this case, the DOM flow is not based on the Drop Ship flow but on the 3PW flow supported by the Oracle Shipping and Transportation applications. In the Intra Company accounting flow shown in the Figure 8, the physical transfer of goods occurs between the 3rd Party System (modeled as an Inventory Org) and the Customer. In this scenario, 3rd Party System does not log any accounting entries and the associated financial flow is between the Sales Org in the Oracle Central Instance and the Customer. Accounts for the inventory kept in the 3PW and associated COGS are maintained in the Sales Org (Oracle Central Instance).
COGS: $5
Customer
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 T1 Transaction Sale and Shipment in the Sales Org Oracle Central Instance Description Sales Org Accounting OU1 (Oracle Central Inst.)
Dr OU1 Receivable 20 Cr OU1 Revenue 20 Dr OU1 COGS 5 Cr OU1 Inventory 5
Page 55
Transaction T1 - Sale and Shipment in the Sales Org (Oracle Central Instance)
At the time of sale and shipment in the 3rd Party System, Oracle Central Instance credits OU1 Inventory account and debits the OU1 COGS account. In addition, OU1 Receivable account is debited and OU1 Revenue account credited at the Sales Order Price List price. 3PW does not charge taxes to Sales Org in the Oracle Central Instance since no I/C invoices are generated. While the 3PW-based DOM flow is simpler than the Drop Ship based DOM flow, its use is restricted by several limitations: 940/945 Documents not as universally supported as POs and ASNs o Many ERP vendors (including Oracle Applications) do not support Inbound Shipment Request (940) and Outbound Shipment Response (945) required to model a 3rd Party System as a 3rd Party Warehouse System Even if the 3rd Party System supports inbound Shipment Requests and outbound Shipment responses, using Purchase Orders and ASNs may be preferable to reuse the existing 3rd Party System implementation. Existing 3rd Party System implementation would more likely be setup to receive Purchase Orders and return ASNs than to receive Shipment Requests and return Shipment Responses.
3PW based DOM flow is not suitable for scenarios where 3rd Party System needs to perform functions in addition to shipping items from the warehouse o In many scenarios, 3rd Party Systems will perform activities in addition to shipping the goods from the warehouse. For example, 3rd Party System may be responsible for manufacturing the item or providing additional services based on the original Customer order. Typically, 3rd Party Systems would start order management workflows to perform these additional activities upon receiving a Purchase Order. In contrast, receiving Shipment Request (940) will typically trigger only shipping of the goods that already exist in the warehouse.
Limitation of Oracles Outbound 940/Inbound 945 implementation o o o Changes on 3PW orders not permitted (cancellations only) No automatic transactions to maintain 3PW on-hand inventory in the Oracle Central Instance Reservations on the 3PW inventory not supported
Page 56
Given these limitations, the 3PW based DOM flow is most suitable for situations where the 3rd Party System already supports Shipment Requests (940) and Shipment Response (945), performs only shipments from the warehouse based on the requests from the Oracle Central Instance, and maintains no accounting entries.
Page 57
Page 58
Transactable (INV) Stockable (INV) Customer Ordered (OM) Customer Orders Enabled (OM) OE Transactable (OM) Shippable (OM)
Optional Item Attributes: Reservable (INV) Inventory Item (INV) Internal Ordered (OM) Internal Orders Enabled (OM)
Page 59
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