Oracle BPEL

Internal Drop-Shipping: Multi-Org Inter-company invoicing in Rel. 11.5.10 David S. McCurry McCurry and Company, Inc. Introduction Many large and multi-national enterprises are composed of numerous organizations that belong to different operating units and legal entities that conduct business in multiple sets of books. It is common that the legal and reporting structures of these enterprises are complex and do not match the transactional structure of the business. Multiple Organization functionality is designed to accommodate multiple organizations and legal entities within a single installation of the Oracle Applications and serves to define these organizations and their logical relationships to each other so that business transactions can occur efficiently between them. Multi-Org functionality was first introduced with the release of version 10.6 of the Oracle Applications and the advent of Order Management, Advanced Pricing, and Workflow in Rel. 11i has broadened its extendibility. Now with the release of 11.5.10, yet further enhancements have been added that allow the functionality to be tailored to meet the most complex of business requirements.

Inter-company invoicing functionality is a component of Multi-Org that facilitates the sourcing of shipments from physical warehouses, reducing stocks, freight and inventory carrying costs at distribution and service locations without legal structure complications and redundant procurement, inventory order fulfillment processes. It can reduce order lead times by removing “corporate obstacles” to global inventory planning, making the legal structure of the enterprise transparent to the end-customer. It also automatically generates inter-company receivables and payable invoices based on the logical transaction flow of the business by using established transfer pricing policies, mitigating the risk of unbalanced inter-company transactions that delay closings and consolidations. Most importantly, it can accomplish this in a way that preserves a clear, documented audit trail for inter-company transactions that complies with GAAP and Sarbanes-Oxley. Scope of this paper The scope of this paper is to demonstrate how Multi-Org Inter-company Invoicing functionality can be utilized to automate the inter-company accounting and streamline the entire order process where orders are taken in one operating unit but physically shipped from another. The standard functionality will be discussed in detail as well as how and where it can be modified to customize the functionality to fit specific business requirements. The topics covered include an overview of the Inter-company Invoicing functionality, and an outline of the process, business events, and accounting impact in each entities set of books. Required configurations and setups are discussed in detail as well as how Transfer Pricing, the CoGS Workflows, and the generation of Accounts Receivable and Account Payables invoices can be customized to meet specific enterprise requirements. Global inventory planning is discussed and sample SQL for creating reconciling inter-company transactions is provided. Enhancements to the functionality included in Release 11.5.10 of the applications are also discussed. Finally, this paper attempts to address constraints and limitations of this functionality and suggests ways to mitigate possible risks and contingencies.

The target audience includes functional and technical resources that are involved in the implementation of the Oracle Applications. A basic understanding of Oracle Workflow and Advanced Pricing is recommended. This paper is primarily aimed toward the functional user but sample PL/SQL packages and discussion of certain APIs are presented for reference. This paper is not intended to cover in detail the functionality of these applications and the reader is encourage to reference the Workflow, Multi-Org, and the Application User’s guides.

OAUG Connection Point® 2006 Copyright 2006 by McCurry & Company, Inc. Page 1 of 21

Business Requirement Many large and multi-national enterprises are composed of numerous organizations that belong to different operating units and legal entities that conduct business in multiple sets of books. The merger-mania of the 80’s-90’s created many business enterprises that appear to be one to the outside but still retained the legal structure of many smaller companies on the inside. With the growth of the global economy in the last decade, many companies have grown beyond national borders and operate with multi-national business structures. Many un-related companies have attempted to leverage synergies by creating joint venture corporations. Quite often, these JVs are managed by one of the JV partners using its production facilities and personnel but require separate transactional reporting. Finally, many corporations are simply comprised of complex legal entity structures intentionally for tax benefits and liability limitation. Despite whatever complex and sometimes convoluted legal and reporting structure, the physical or literal structure of the business has become very different from the legal structure. Many public-traded companies are broken down into divisions based upon external reporting requirements that are based upon industry or market segment divisions, even though the products manufactured and sold into different business segments are produced in the same location. As a result, it is not uncommon for a single enterprise in a single installation of the Oracle ERP applications to operate several companies, legal entities, production, and distribution operations as independent organizations. Transactions are/must be handled as if they were 3rd party transactions even though the products that are “manufactured and sold” by the different “child corporations” are in fact produced and shipped from the same production facility using the same personnel and transaction channels. The difficulty comes in where these transactions must captured and processed based upon legal structure considerations. With the advent of Sarbanes-Oxley, there is a greater need to maintain accuracy and transparency for inter-company activities. Recent history has seen the abuse of these complex, convoluted, multi-national structures to create fragmented business transactions that hide the true condition of the enterprise. The resulting requirement of Sarbanes-Oxley is that a clear and auditable trail of these inter-company transactions must exist while at the same time support the “legal spaghetti” that make these business transactions appear legally to have occurred “arm’s length” between 3rd Party companies. The literal and obviously in-efficient process would be for these “companies” to generate transactions between them that suggest totally different organizations. Consider an example of an enterprise operates a manufacturing business and a distribution business under a legal structure of separate companies but are located that the same physical facility. Company X gets an order from a third party customer and in response, generates a purchase order to Company Y, who acknowledges by creating a sales order to Company X. When Company Y physically ships to the end customer, they must first “logically ship” the product to Company X, who “receives” it into inventory on the books and then executes a shipping transaction to represent the transfer of ownership to the true customer. This is done strictly to simulate an arm’s length transaction with conveyance of title from Y to X to the customer when it literally did not occur. But a paper trail of Purchase Order, Sales Order, Receiving Transaction, and Invoice are required. But this paper trail is fraught with pot holes and detours like duplicate or lost transactions, mis-matched accounting, unapproved and/or un-matched invoices, timing issues between AR and AP or between company X and company Y, and many other types of dis-connects. This configuration becomes increasingly problematic as a considerable number of inter-company transactions are carried out on a day-to-day basis between the two “companies”. The distribution and service organization (company X) sources a great many of their inventory items from the production organization (company Y). Because these organizations reside at the same physical location and use the same shared-personnel to receive, stock, and ship inventory, redundant transactions occur when the items are shipped from the production organization directly to the customer of the service organization.


The Objective The objective is to utilize functionality resident within the Oracle applications to eliminate these duplicate transactions and streamline the shipping process. Inter-company Invoicing is standard Oracle functionality that leverages the fact that these related parties exist in the same instance of the ERP applications. This functionality significantly streamlines the business process by eliminating the generation of redundant purchase orders, inventory transactions, and sales orders between the related parties by automating the inter-company transaction flow by creating an internal customer-supplier relationship between the two companies that allows Company Y to internally drop-ship product for Company X. “Internal” versus “External” Drop-Shipping: What’s the difference? External Drop-Shipping functionality in Oracle Order Management uses purchase orders to outside suppliers that are automatically generated from sales orders for goods supplied directly from the supplier. The “external” supplier ships the goods directly to the 3rd Party customer and confirms the shipment through the use of an Advanced Shipment Notice. Oracle uses this ASN to record a receiving transaction into inventory followed by an immediate logical shipping transaction. From these transactions, conveyance of title takes place and the customer can be invoiced and the supplier’s invoice can be processed. “Internal” Drop-Shipping functions in a similar fashion. The key difference is that no inventory transactions take place on the books of the selling operating unit; transfer of ownership of the goods from shipper to seller to customer with the only physical movement of the goods being out of the shipping organization. Overview of Inter-company Invoicing Inter-company invoicing has been available in the Oracle applications since Multi-Org was first introduced in Release 10.6. Multi-Organization functionality enables an enterprise to operate independent business units within a single installation of the software and still maintain segregation of the data by business units. These are called “Operating Units” in Multi-Org and are used to segregate Sales Orders, Purchase Orders, Receivables, Payables transactions by business units while leveraging the use of global item, customer, and supplier registries. As it is discussed here, the purpose of Inter-company Invoicing is to “fill-in” the accounting gap that occurs when goods are internally drop-shipped against a sales order from a warehouse that is part of a separate operating unit in a different set of books. When the shipping inventory organization is not part of the same operating unit as the selling entity, a gap is created as each operating unit is “missing” half of the transaction. Inter-company invoicing fills in that gap by generating accounting transactions in the form of inter-company receivable and payables invoices. Consider the example of Company X and Company Y presented above:

3rd Party Customer

Operating Unit X(Seller)

Operating Unit Y(Shipper)

Company X Set of Books

Sales Order

Company Y Set of Books

Product Shipment

Warehouse

AR Invoice

AP Invoice

Intercompany Relationship


Company X, operating as an Operating Unit, enters an order to a third party customer. The order is fulfilled by a warehouse (inventory organization) belonging to company Y, operating as an Operating Unit. Both company X and company Y are on separate sets of books. The Sales Order and the shipping of the product represent the physical flow of transaction while the generation of the inter-company transactions represents the logical transaction flow. The advantage of inter-company invoicing is quite clear when you consider the what steps would be involved in manually creating the logical transaction flow as opposed to using the inter-company invoicing functionality :

Without Inter-company Functionality Inter-company Functionality Process Customer Service enters the Order for the end customer in the Company X Operating Unit.

Customer Service enters the Order in the Company X Operating Unit and selects Company Y’s warehouse as the Ship From.

With no stock on hand, Order goes on back-order sends a notification to the Planner

Company Y Stockroom then picks the part and ships the product to the end customer.

Company X Planner creates a Purchase Order in the Company X Operating Unit and submits to Company Y Customer Service

Automated process generates and posts invoice between Company X and Y.

Customer Service enters a sales order in the Company Y Operating Unit with Company X as the customer

Company Y Stockroom receives demand notification and picks and ships the product to Company X.

Company X Stockroom receives the product into inventory against their purchase order

Company X Stockroom then picks and ships the part to the end customer.

Company Y generates invoice and sends to Company X Payables

Company Y enters the invoice and matches it to the PO and receipt.

The benefits of using Internal Drop-Shipping are very obvious when the two approaches are compared. Several redundant processes have been eliminated by not having to generate purchase orders, sales orders and “bogus” inventory transactions. This reduces the overall order fulfillment time and gets the product to the end customer faster. The planning and procurement activities have been centralized with company Y, as they function as a single source of supply for the enterprise and product demand is flattened into a global view for the whole enterprise. This also provides for the consolidating of inventory with one organization and reduces overall inventory carrying costs. Because the creation of the Inter-company AR and AP invoices is automatic, it eliminates the risk of timing differences between the two companies and makes the financial consolidation process easier. This also eliminates the risk of transfer pricing errors as well as transaction errors or lost transactions. How Internal Drop-Shipping Works The definition of the “internal” customer-supplier relationship in Oracle between the two operating units enables the selection of Company Y’s warehouse locations on the Sales Orders in Company X. This places demand on Company Y and allows them to execute shipping transactions directly against company X’s sales order. The “transaction gap” that is created between the two companies, specifically the COGS entry for company X and the revenue transaction for company Y is filled by running two inter-company invoicing processes: the “Create Inter-company AR Invoice (INCIAR)” process and the “Create Inter-company AP Invoice (INCIAP)” process. The INCIAR process creates an AR invoice on Company Y’s books for the customer Company X and the INCIAP creates a “mirror” AP invoice on Company X’s books


for the supplier Company Y. Consider the example above based upon the chronology of events and the accounting impact of process:

Event Set of Books Debit Credit

X None Company X books order to a 3rd party with a warehouse

designation of Company Y Y None

Trade Receivables

X Revenue, Freight, and Tax

(based on 3rd Party Pricing) Cost of Goods Sold (Based on Standard Cost)

Company Y picks and ships the goods against Company X’s

sales order Y

Inventory None X None Inter-company Receivables

The Create Inter-company AR Invoice Process Runs. Auto-

invoice is run for Inter-company Invoices Y Revenue, Freight, and Tax

(Based on Transfer Pricing) Cost of Goods Sold (Based on Transfer Pricing) X Inter-company Payable None

The Create Inter-company AP Invoice Process Runs. Expense Import is run for Inter-company

AP Invoices Y None The INCIAR and INCIAP processes use the Inter-company Relationship as well as other customer/supplier setups in Oracle to create AR and AP invoices on both sides that are consistent in date, amount, currency, taxes, etc. Again, this functionality has been available in Oracle since the release of multi-org in 10.6 and has been continually enhanced and expanded as newer versions of the applications have been released, but it’s basic conceptual functionality remains the same. With the release of 11i, the introduction of Advanced Pricing expanded the flexibility in deriving the transfer price. The replacement of Flex-builder with the Workflow-based COGS Account Generator expanded the flexibility in deriving the COGS Account for the shipping transaction. The release of 11.5.10 has brought yet more enhancements to the functionality. Enhancements to the functionality included in Release 11.5.10 With the release of 11.5.10 of the applications, procurement flows have been added to the established shipping flows. Procurement Flows provides for and inter-company invoicing for global procurement. This addition allows for the generation of Purchase Orders in one operating unit with the receipt of goods into the inventory organization belonging to another. Invoicing for inter-company procurement can be done at either the PO price or the transfer price, and accounting is done to represent a transfer of ownership between the operating units. The Inter-company Relations form (INVSDICR) has been changed to support the global procurement business flows. Several new fields have been added for global procurement to the form. In addition, this form is now only accessible through the new Inter-company Transactions Flow definition form. The Inter-company Transaction Flow (INVSICTF) form is a new form used for creating transactions flows to support advanced inter-company invoicing for both selling and procuring transaction flows. IC Transaction Flows defines the relationship relative to the movement of goods and the accounting impact between “chains” of operating units. Chains of inter-company relationships can now be created to support the flow of logical transactions through a chain of operating units through which ownership must pass when transacting between selling and shipping operating units, or between procuring and receiving operating units. Inter-


company invoices are generated between all operating units, and. the accounting is done to represent and ownership transfer between each operating unit in the chain.

3rd Party Customer

Operating Unit X(Seller)

Operating Unit Y(Shipper)

Sales Order

Product Shipment

Org 327

AR Invoice

AP Invoice

Logical Flow

Operating Unit Z(Intermediary)

AR Invoice

AP Invoice

This is example presented previously modified to show the functionality of “Advanced” inter-company invoicing. The new Inter-company Transaction Flow form supports the additions of operating units between the selling and shipping operating units. These are referred to as “intermediate” operating units and create a chain between the two ends. In this example, Company Z, has been inserted between companies X and Y. The physical flow remains the same as before; company X takes the order and company Y ships the product. But now, company Y is shipping the product on behalf of company Z, who is acting as the supplier for company X. Setting up for Internal Drop Shipping In order to use inter-company invoicing for selling and shipping across multiple operating units, several GL, AR, AP, PO, OM, and INV setups are required. Many of these setups most likely have been completed as part of your implementation but may have an impact of implementing inter-company invoicing. Setups such as General Ledger account code combinations, inventory items, launching Cost and Transaction managers are considered pre-requisite and will not be discussed here. To verify that everything has be setup correctly and completely, you should run the Setup Validation Report. In addition to these fundamental setups, there are approximately 17 separate set-up steps specifically for the Inter-company invoicing functionality. These are as follows:

Step 1: Profile Options related to Inter-company Invoicing There are several profile options that are used by Inter-company invoicing. Many are controlled strictly at the site level and must be set for the entire enterprise:


INV: Inter-company Currency Conversion This profile option determines conversion type for foreign currency invoices. INV: Inter-company Invoice for Internal Orders This YES/NO profile option can only be set at the Site level and controls whether or not the “Create Inter-company AR Invoice” process generates invoices for shipments between organizations through Internal Requisitions and Internal Orders. INV: Advanced Pricing for Inter-company Invoice This Yes/NO profile option can only be set at the Site level and controls whether or not the INCIAR process uses the Advanced Pricing Engine to determine the Transfer pricing for Inter-company Invoices.

QP: Pricing Transaction Entity This profile indicates the current Pricing Transaction Entity in use. Only contexts and attributes assigned to the current Pricing Transaction Entity will be available in the LOVs on the setup forms. The default is “Order Fulfillment”. QP: Source System Code This profile whether common or separate price lists are used for regular sales orders and inter-company invoices. The default is “Oracle Pricing”. Tax: Allow over-ride of Tax Code This YES/NO profile option determines whether tax code information should be passed to AR for freight. Tax: Invoice Freight as Revenue This profile option determines whether freight lines should be invoiced as revenue lines. Tax: Inventory Item for Freight This profile option determines the inventory item that is used when freight lines are invoiced as revenue lines. Step 2: Receivable Systems Options Receivable Systems Options have most likely been already setup but the “Require Salesperson Flag” is important to ICI functionality. This flag MUST BE set to NO in the Shipping Operating Unit. The INCIAR process generally does not pass Sales Credit information to Receivables and the process will fail if this flag is checked.


Step 3: Inter-company AR Transaction Source (Batch Source) Batch Sources control how receivables information is interfaced from Order Management to Oracle Receivables. The INCIAR process uses the transaction source “Inter-company” that comes seeded with the application to create the AR Invoice using Auto-accounting. The Inter-company Transaction source is seeded with the appropriate values and it is generally recommended that you do not modify it with two possible exceptions: the Allow Sales Credit Flag and the Transaction numbering.

It is important that the Inter-company AR Transaction Source be setup with a number sequence in the “Last Number” field which is unique from Batch Sources used by other AR documents. Difficulties in querying AR invoices can occur when the numbering sequence conflicts with the sequence of other AR transaction types. It is best to define your other batch sources using a different range of numbers. But if you have already begun to use this numbering sequence elsewhere, you may need to update the “Last number” value directly. This value is drawn from the sequence “AR.RA_TRX_NUMBER_X_YYY_S”, where the “X” refers to the Batch_Source_ID and “YYY” refers to the Organization_id for the Operating Unit. You should contact Oracle support for assistance for re-setting this numbering sequence.

If your Auto Accounting configuration uses the Accounting Flexfield segment values from the Sales Representative record to build the accounting flexfield combination for revenue, receivable, etc., it is important that the “Allow Sales Credit Box” on the “Autoinvoice Options” tab of the Transaction Sources form be checked.


Step 4: Auto-Accounting The INCIAR process uses the Auto-Accounting setup in the Shipping Operating Unit to build the accounts for the AR Invoice. Auto-Accounting allows to configure the build of the combinations for Receivables, Revenue, Freight, Tax, etc. based upon Values from Inventory Item Attributes, AR Transaction Types, the Internal Customer site, Salesreps, etc. The process uses these accounting flexfield combinations when it creates the records in the AR interface table to be picked by the Auto-Invoice process. Based on how the Auto-accounting has been defined, you must be mindful of the following considerations: If you are using account segments from the Sales Representative Record in your Auto-accounting configuration, note that Auto-Accounting will use the values from the “No Sales Credit” sales rep for these values. If you are using account segments from the Standard Lines, Auto-Accounting will use the values from the Sales Account Item Attribute in the OM Item Validation organization. Account segments using the transaction type will pull from the AR Transaction type specified on the Inter-company Relations form.

Customizing the account generation for Inter-company AR Invoices. The Auto-Accounting functionality has changed very little in the last several years and lacks the flexibility of those processes that have been re-designed to use Workflow. It may be the case that the existing Auto-Accounting configuration is too limited to derive the accounting required for the Inter-company AR invoices. In this case, it may be necessary to update interface records before the Auto-invoice process is run. One approach is to use a custom trigger to derive the necessary accounts for the generation of the various accounts on the Inter-company AR Invoice. An example might look like this :

CREATE OR REPLACE TRIGGER APPS.XYZ_RA_INTERFACE_LINES_ALL_T1 BEFORE INSERT ON AR.RA_INTERFACE_LINES_ALL REFERENCING NEW AS NEW OLD AS OLD FOR EACH ROW WHEN ( new.interface_line_context in ('ORDER ENTRY','INTERCOMPANY') and new.line_type = 'LINE' and new.org_id in (123,456,789) ) . . . If :new.interface_line_context = 'INTERCOMPANY' then . . .


Step 5: AR Transaction Types for the Inter-company Transactions Transaction Types are assigned to invoices and credit memos and default key data such as payment terms, accounts, tax, freight, posting and receivable information, etc. AR transaction types for Inter-company transactions must be setup for each operating unit which contains inventory organizations that act as shipping warehouses for selling operating units. Inter-company Invoicing between the operating units uses the Auto-Accounting Rules. Depending on how these rules are defined, some of the accounting flexfield segments may be derived from the accounts specified on the AR transaction type. It is advisable to create AR transaction types for Inter-company Invoices and Credit Memos not only for the sake of providing Account values for Auto-Accounting but also to provide visibility in AR to inter-company transactions.

Step 6: Transfer Pricing There are three methods available to derive the price to be used as the transfer price for inter-company invoices: Static, Advanced, and Custom. The most basic method is Static pricing, which pulls the transfer price from the Price List specified on the internal customer. Advanced Pricing provides more flexibility by using the Advanced Pricing Engine to derive the transfer price based upon its rules-based functionality. The third method is to modify the pricing API to call a custom code to return the transfer price.


The INCIAR process uses the API called MTL_INTERCOMPANY_INVOICES.get-transfer_price to derive the transfer price. The open architecture of this API allows the user to develop custom logic to derive the transfer price using whatever rules and logic they require. If this API is not used, the process progresses to determine whether static or advanced pricing will be used. The process uses the profile option, INV: Advanced Pricing for Inter-company Invoice to determine the desired path to take. If the profile option is set to “YES”, the Advanced Pricing Engine will be used. If the profile option is set to “NO”, the transfer price will be taken from the static price list referenced on the Internal Customer record.

Inter-company Invoicing with Advanced Pricing Oracle Advanced Pricing is a new application module introduced with Release 11i that is designed to be flexible to support the pricing requirements of all kinds of business scenarios. It is an application that uses rule-based components to determine the transfer price that goes well beyond the capabilities of static price lists. Oracle Advanced Pricing uses rule-based components to accommodate the many pricing concepts through standard configuration; and more specialized, complex pricing schemes through custom APIs and PL/SQL procedures. To accomplish this, Advanced Pricing employs the use of a “pricing engine” that calculates and returns a transfer price to the line based upon the parameters supplied to it. Depending on how the pricing rules have been setup in Advance Pricing, these parameters can include whatever data components drive the pricing of the item, such as Shipping or Selling Organization, Customer, Item, Item Category, etc. Oracle Advanced Pricing provides several seeded Qualifiers and Pricing Attributes that can be used to derive the transfer price. The pricing engine selects the eligible list lines (Qualifiers and Modifiers) that apply to the transfer price calculation. It should be noted that however the pricing engine is configured API customized, it should be designed to always return a non-zero value. While it is possible to create AR invoices with a price of zero, it is not possible to do so on the AP invoice and the INCIAP process will fail Step 8: Payment Terms for AR and AP The same payment terms must exist and must match in spelling and case in AR as in AP. Payment Terms are assigned to both the internal customer and supplier so that the terms of the invoices created by the INCIAR and INCIAP processes are the same.


Step 9: AR and AP Tax Codes Tax Codes are setup in each operating unit. Tax names or tax codes are use on invoices to record invoice taxes paid to suppliers and tax authorities. Each tax code has a tax type, a tax rate, and the account to which tax amounts are charged. AR and AP tax codes and tax rates must be the same in order for the Inter-company invoice generation processes to function properly. Separate tax codes should be created for inter-company invoicing based on the inter-company accounting requirements. Each Tax Code has a different GL account that is specific to the Selling Organization. It is important to assign the correct AP Tax code to the Inter-company vendor in order to have the correct GL account represented.

Step 10: Internal Customer Customer Address Information is maintained in each operating unit. Only the header information is maintained at the Application Level and is shared across operating units. The internal customer is defined in the shipping operating unit and is used by the INCIAR process based upon the inter-company relations form. Payment terms and the Tax Code must be same as those used on the internal supplier in the selling operating unit.


If advanced pricing or a custom logic is not being used to derive the transfer pricing. The static price list to be used by the INCIAR process for the AR inter-company invoice is specified on the internal customer record. The INCIAP process will also use this price for the creation of the AP inter-company invoice.

Step 11: Internal Supplier Supplier Address Information is maintained in each operating unit. Only the header information is maintained at the Application Level and is shared across operating units. The internal supplier is defined in the selling operating unit and is used by the INCIAP process based upon the inter-company relations form. Payment terms and the Tax Code must be same as those used on the internal customer in the shipping operating unit.

Step 12: Inter-company Transaction Flows Transaction Flows outline the linkages between operating units and inventory organizations that define the flows of financial transactions when inventory transactions take place the shipping organization and the selling organization. This transactional flow can be quite different from the physical flow of goods due to the presence of other operating units in between the shipping organization (source) and the selling organization (destination), known as “intermediate” operating units. The addition of Transaction Flows in Release 11.5.10 has greatly expanded the functionality of the Inter-company relations component of Inter-company invoicing. The addition of these intermediate operating units has created a “transactional chain” through which cost, revenue, and the transfer of liability can flow. The intermediate operating units serve as links in the chain that can be sequenced as required to reflect the desired transaction flow without having to perform manual transactions at each link. The Oracle Inventory Users guide calls these “Logical Transactions” and defines them as “an accounting event that represents the financial transaction between two operating units without the physical movement of goods”. The Inter-company Transaction Flow (INVSICTF) form is a new from in Release 11.5.10 that is used for creating transactions flows to support advanced inter-company invoicing for both selling and procuring transaction flows. You must now define the Transaction Flow before defining the Inter-company relations.


First define the “ends of the chain”, the starting and ending operating units. For a selling relationship, these are the Shipping and Selling Organizations. There are two transaction flow types, Selling and Procuring. As the procurement part of the inter-company invoicing is outside the scope of this paper, the value selected here is “Shipping”. Optionally enter the Ship-From Inventory Organization. Optionally enter a Category Qualifier to use items that belong the Inventory Category Set. Check the Advanced Accounting box if the transaction flow will include intermediate operating units. The intermediate operating units can then be added into the Nodes region of the form. Step 13: Inter-company Relations Inter-company Relations are defined at the business group level to define relations between two operating units and create the linkage between the internal customer (seller) and supplier (shipper). When a sales order is entered in an operating unit and shipped from a shipping organization in a separate operating unit, the inventory asset account for the shipping organization is credited and the cost of goods sold account is debited. The sales revenue is recognized in the selling organization. The system performs the accounting distributions to record the inter-company revenue, receivable, and payable entries.

Note: This is the 11.5.9 version of the form


This step is central to the Multi-org Inter-company invoicing functionality. Inter-company relations must be defined for each selling/shipping relationship in the instance. Note, only one relationship can be defined in one direction. It is possible to have multiple inter-company relation records where the shipping operating unit and the selling operating unit are the same.

In the 11.5.10 version of the inter-company relations form, the Currency Code Field can be used to define the currency code to be used in the Inter-company AR invoice. This field is only used when the profile option “INV: Advanced Pricing for Inter-company Invoice” is set to YES. When the profile option is set to “NO”, the INCIAR process uses the currency of the Price List used by the Inter-company customer. Options for the field when FI Type is “Shipping” are: Shipping Operating Unit, Selling Operating Unit, and Order Currency.

Step 14: Inventory COGS Account Generator The account generator uses Oracle Workflow to derive General Ledger Accounting Flexfield combinations for different applications. The INCIAP process uses the Inventory COGS Account Generator to derive the COGS account for the selling operating unit. Oracle Workflow is a very open architecture and allows you to customize the account generation process as needed. Workflow is an application that manages business processes according to pre-defined set of rules. The Oracle Applications Suite comes with many standard workflow processes embedded to provide better control and visibility of transactions. These processes include activities that are linked together in a logical order to control how transactions are processed. These activities are composed of functions, notifications, business events, and sub-flows and can be modified or re-arranged to meet the specific requirements of the business. Functions, notifications, item types, and messages are linked together to create processes using a tool called Workflow Builder. Workflow Builder uses “drag and drop” functionality in an Editor Window and a long list of seeded activities to enable the user to add, delete, or modify various processes. New activities can be easily created by copying and modifying any of the seeded components. Functions, Messages, and Lookup Types are powerful building blocks in defining workflow processes because they are very flexible and easily customized. Workflow functions call stored PL/SQL procedures or external functions to do the work of the process. This provides a very open environment to allow the user to address the specific requirements of the business process. Workflow processes are initiated when an Oracle application calls the Workflow engine. The application instructs the engine which workflow process to run. The engine is embedded in the database server and coordinates and monitors the activities in the process, determining which activities are eligible to run, executing the activities, and progressing to the next activity.

The Inventory COGS Account Generator is used by the INCIAP process to derive the COGS account for the selling operating unit. The Account Generator dynamically creates a COGS Account for order and return lines which go the INCIAR process. This is different workflow from the OM COGS Account Generator. The seeded Inventory COGS workflow can derive the COGS account from the COGS Item Attribute in the Shipping Organization or from the Order Type. If you need to build account code combination based on a more complex logic using other attributes, you can copy the Workflow and modify it as needed.


Step 15: Order Transaction Types While separate order transaction types are not required for Inter-company invoicing, it is recommended to create them in order to segregate orders shipped from another operating unit from “regular” orders. Also, if the selling organization processes orders that are shipped from different shipping organization, it may be helpful to segregate orders. Depending on how the Auto-Accounting rules and/or Inventory COGS account generator are defined, it may be required to create separate order transaction Types to drive the correct accounting for your inter-company invoicing transactions.

Step 16: Release Rules Separate Release Rules are recommended for internal drop-ship orders. Rules are defined at the application level and used as a LOV for selecting a Default at the Shipping Organization level. Default pick release rules are applied at pick release in the Release Sales Orders window. Each rule can be set up with its own set of unique pick release parameters depending on the pick release criteria required.

Step 17: Inter-Company AR and AP Processes – INCIAR & INCIAP The Create Inter-Company AR Process - INCIAR The INCIAR process generates the Inter-company receivable invoice for the Shipping operating unit from the internal customer. It creates the receivable transaction and loads it into the AR open interface table. Auto-invoice picks up this transaction and creates the actual AR invoice. The AR Transaction date is the same as the inventory shipping confirmation transaction date. The transfer price and currency for the invoice is either drawn from the inter-company price list or derived using Advanced Pricing. It should be noted as a reconciliation tool that the ID of the record in the Create INCIAR request log will equals the material transaction ID. The Create Inter-Company AP Process- INCIAP The INCIAP process generates an Inter-company payables invoice for the Selling operating unit from the internal supplier , the shipping operating unit. INCIAP uses the AR invoice created by the INCIAR process to create an AP invoice that “mirrors” the AR Invoice. The INCIAP process records the AP invoice in the same currency as the Inter-company AR invoice. If this currency is different from the functional currency in the set of books used by the Selling operating unit, Oracle will convert the invoice using the exchange rates based on the GL date of the invoice line. The INCIAP Process uses the Inventory COGS Account Generator workflow to derive the COGS Account. Please refer to step 14 above. The INCIAP Process uses the freight account from the Inter-company relations form. Pleases refer to step 13 above. The INCIAP Process uses the AP Liability Account from the inter-company supplier site (Shipping organization) specified on the Inter-company relations form. INCIAP creates the payable transaction and loads it into the Expense Report open interface table. The Expense Report import program picks up this transaction and creates the actual AP invoice.

Creating Report-Sets for the INCIAR & INCIAP processes Depending on the volume of inter-company transactions that take place on any given day, it is recommended to create report sets that routinely run and create the AR and AP invoices. In this way, running the INCIAR and INCIAP processes can be married with running the Auto-Invoice and Expense Report Import processes. It should be noted that each Report Set must be setup in the correct operating unit in order for the Auto-Invoice and Expense Report Import processes to run correctly. It is also recommended that the two report sets always be set to run such that they complete on the same day to insure that both invoices are created in the same accounting period.


Request Set for the Shipping Operating Unit

Request Set Set XYZ Inter-company Invoices - Shipping Set Code XYZ_INCIAR_SET Application Oracle Inventory Description Process Inter-company AR Invoice between Company Y

and X Owner MCCURRYD

Set XYZ Inter-company Invoices - Shipping

Set Application Oracle Inventory

Display Seq Stage Description

10 INCIAR- Company Y Generate AR Invoice for Shipping O.U.

20 Auto-Invoice Inter-co Invoices

Run Auto-invoice for Inter-company AR invoices

Request Set for the Selling Operating Unit

Request Set Set XYZ Inter-company Invoices - Selling Set Code XYZ_INCIAP_SET Application Oracle Inventory Description Process Inter-company AP Invoice between Company X

and Y Owner MCCURRYD

Set XYZ Inter-company Invoices - Selling

Set Application Oracle Inventory

Display Seq Stage Description

10 INCIAP- Company X Generate AP Invoice for Selling O.U.

20 Import Inter-co AP Invoices Run Expense Report Import Inter-company AP invoices

Reconciling Inter-company Transactions. Because internal drop-ship orders create transactions that cross operating units, it can be problematic to reconcile transactions in the event of an error somewhere in the process. Below is a SQL statement that can be used to create reporting to aid in the reconciliation process. SELECT


(SELECT name FROM HR_ALL_ORGANIZATION_UNITS WHERE organization_id = oeh.org_id) SELLER, (SELECT organization_code FROM MTL_PARAMETERS WHERE organization_id =oel.ship_from_org_id) WAREHOUSE,

oi.org_information3 SHIP_OU, oett.name ORDER_TYPE, oeh.order_number, oel.line_number, oel.ordered_item, oel.request_date, oel.actual_shipment_date, oel.shipped_quantity, oel.unit_selling_price, ps_sell.trx_number, ps_sell.trx_date, ps_sell.amount_due_original, ps_sell.invoice_currency_code, ps_ship.trx_number ICAR_TRX_NUM, ps_ship.trx_date ICAR_TRX_DATE, ps_ship.amount_due_original ICAR_AMOUNT_DUE, ps_ship.invoice_currency_code ICAR_CURRENCY, pia.invoice_num ICAP_INV_NUM, pia.invoice_date ICAP_INV_DATE, pia.invoice_amount ICAP_INV_AMT, pia.invoice_currency_code ICAP_CURRENCY FROM oe_order_headers_all oeh, oe_order_lines_all oel, hr_organization_information oi, oe_transaction_types_tl oett, ra_customer_trx_lines_all ctl_sell, ra_customer_trx_lines_all ctl_ship, ar_payment_schedules_all ps_sell, ar_payment_schedules_all ps_ship, mtl_intercompany_parameters mip, ap_invoices_all pia, ap_invoice_distributions_all pid WHERE oeh.header_id=oel.header_id AND oel.shipping_interfaced_flag='Y' AND oeh.order_type_id=oett.transaction_type_id AND oett.language='US' AND ctl_sell.org_id=oeh.org_id AND ctl_sell.interface_line_context='ORDER ENTRY' AND ctl_sell.interface_line_attribute1=to_char(oeh.order_number) AND ctl_sell.interface_line_attribute6=to_char(oel.line_id) AND ctl_sell.customer_trx_id=ps_sell.customer_trx_id AND ctl_ship.org_id=oi.org_information3 AND ctl_ship.interface_line_context='INTERCOMPANY' AND ctl_ship.interface_line_attribute1=to_char(oeh.order_number) AND ctl_ship.interface_line_attribute6=to_char(oel.line_id) AND ctl_ship.customer_trx_id=ps_ship.customer_trx_id AND mip.sell_organization_id=oeh.org_id AND mip.ship_organization_id=oi.org_information3 AND mip.customer_site_id=ps_ship.customer_site_use_id AND pia.vendor_id=mip.vendor_id AND pia.invoice_num=ps_ship.trx_number AND pia.org_id=oeh.org_id AND pid.invoice_id=pia.invoice_id AND to_char(pid.reference_1)=ctl_ship.customer_trx_line_id AND pid.reference_2=ctl_ship.interface_line_attribute7 AND oel.ship_from_org_id=oi.organization_id AND oi.org_information_context='Accounting Information' AND oel.org_id<>oi.org_information3


Limitations and Considerations

1. Business Practices It will be necessary for the companies to standardize their policies regarding parts returns and special charges. The inter-company invoicing functionality is not designed to accommodate situations where the selling and shipping organizations apply different product return policies and/or process, and charge each other expedite fees and special handling charges which are not passed on to the customer. 2. Impact on Reporting Standard and Custom Reporting may need to be modified or augmented to accommodate the transactions across operating units. The CoGS transaction for Company Y will come from AP rather than from Inventory. As a result, some standard COGS and Standard Margin reports may not be usable for these transactions, so the Revenue and COGS transaction for Y may require additional linking for reporting purposes. 3. Use of Inventory Transactions outside of Order Management Miscellaneous transactions in inventory cannot be used in any way for transactions relating to cross-operating unit sale order fulfillment. This functionality only works with transactions entered through Order Management. Manual adjustments entered directly in inventory will not transact across operating units.

4. Manual Adjustment to Inter-company Credit Memos When returned parts are non-conforming and the Shipping organization denies credit to the Selling organization, inter-company AR and AP invoices must both be manually updated in a coordinated effort by both operating units.

5. Copying Orders The use of this functionality is heavily dependant upon configurations and Workflows associated with Order Types, both header and lines. Significant errors can occur if cross-operating unit orders are created using “Normal” order types or standard orders are generated using the inter-company order types. It is a requirement that Customer service be very mindful of the type of order being generated and that the correct order and line type are being used. This is especially true with Orders are created by the copying of others orders.

Standard Orders should NOT be copied to generate Inter-company orders and vice-versa. Each set of Order types update different fields on the orders and defaulting rules may or may not be correctly applied.

6. Maintaining an Inter-company Price List The use of this functionality with advanced pricing requires that the inter-company price list be maintained and kept in synchronization with the price list used by the sales order. The create inter-company AR invoice process will fail for those orders where the item shipped is not on the inter-company price list. An alternative approach would be to use Advanced pricing and create a modifier that does not require the maintenance of the inter-company price list.

7. Non-Shippable Items Intercompany invoicing is only possible for items that go thru the inventory interface and as such only works for shippable items. At this point, there is no functionality available for inter-company invoicing of Service items. The following Item Attributes must be enabled for items to be transactable: Customer Ordered, Customer Order Enabled, Internal Ordered, Internal Order Enabled, Invoicable Item, Invoice Enabled, Cost Enabled, Stockable, Transactable, and Inventory Item.


8. Profile Option INV:Intercompany Invoice for Internal Orders The INCIAR process only uses the value set at the site level. This creates a problem when you want to create inter-company invoices for internal drop shipments but not for regular internal orders.

Conclusions Inter-company invoicing functionality is a component of Multi-Org that facilitates the sourcing of shipments from physical warehouses, reducing stocks, freight and inventory carrying costs at distribution and service locations without legal structure complications and redundant procurement, inventory order fulfillment processes. It can reduce order lead times by removing “corporate obstacles” to global inventory planning, making the legal structure of the enterprise transparent to the end-customer. With the advent of Sarbanes-Oxley, there is a greater need to maintain accuracy and transparency for inter-company activities. Inter-company Invoicing is standard Oracle functionality that significantly streamlines the business process by eliminating the generation of redundant purchase orders, inventory transactions, and sales orders between the related parties by automating the inter-company transaction flow by creating an internal customer-supplier relationship between related parties with customer orders are taken in one organization but shipped from another. Several redundant process can be eliminated, reducing the overall order fulfillment time and gets the product to the end customer faster. The planning and procurement activities can also be centralized as a single source of supply for the enterprise. This also provides for the consolidating of inventory with one organization and reduces overall inventory carrying costs. Inter-company invoicing has been available in the Oracle applications since Multi-Org was first introduced in Release 10.6. Multi-Organization functionality enables an enterprise to operate independent business units within a single installation of the software and still maintain segregation of the data by business units. With the release of 11i, the introduction of Advanced Pricing expanded the flexibility in deriving the transfer price. The replacement of Flex-builder with the Workflow-based COGS Account Generator expanded the flexibility in deriving the COGS Account for the shipping transaction. With the release of 11.5.10 of the applications, procurement flows have been added to the established shipping flows of the inter-company invoicing functionality. Procurement Flows provides for and inter-company invoicing for global procurement. This addition allows for the generation of Purchase Orders in one operating unit with the receipt of goods into the inventory organization belonging to another. While there are limitations and constraints to the functionality, Inter-company invoicing has evolved into a very powerful yet flexible tool in handling complex business structures and the business transactions associated with them. Because of its use of the Advanced Pricing and Workflow applications, open interfaces and public APIs, it is designed to be open enough to accommodate any business situation. Implementing inter-company invoicing can yield great rewards when applied to an environment where physical transaction flows do not match the logical transaction flows and the logical transaction flows are not at all logical. Sources and Additional Reading Oracle Inventory Users Guide – Release 11i, Part #A83507-09, Chapter 14 Inter-company Invoicing. Oracle Workflow Users Guide – Release 11i,Part # B15854-04. Oracle Advanced Pricing Implementation Manual- Release 11i, Part #B14385-03. Overview of Inter-Company Invoicing, Oracle White Paper, July 2005


About the Author. David McCurry is a senior consultant specializing the Oracle distribution and manufacturing applications. He has worked for over ten years as a senior and implementation consultant in mid-size to large manufacturing companies throughout the United States, Europe, Eastern Europe, and the Caribbean Basin. Mr. McCurry also has over 20 years experience in multiple environments spanning the Telecommunications, Textile, Aerospace, Electronics, Chemical, Transportation and Consumer/Industrial products industries. Mr. McCurry has also previously presented papers at OAUG conferences in Europe and the Asia/Pacific.


Oracle BPEL

Documents

removing corporate

inventory

intermediate

profile option

ar transaction

established

separate operating

3rd party