Professional Documents
Culture Documents
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.
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 Users guides.
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 80s-90s 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 intercompany 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 arms 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 arms 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 dayto-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.
Page 2
of 21
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.
Sales Order
Intercompany Relationship
Product Shipment
AR Invoice
Warehouse
Page 3
of 21
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 Customer Service enters the Order for the end customer in the Company X Operating Unit. With no stock on hand, Order goes on backorder sends a notification to the Planner Company X Planner creates a Purchase Order in the Company X Operating Unit and submits to Company Y Customer Service 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.
Inter-company Functionality Process Customer Service enters the Order in the Company X Operating Unit and selects Company Ys warehouse as the Ship From. Company Y Stockroom then picks the part and ships the product to the end customer. Automated process generates and posts invoice between Company X and Y.
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.
Page 4
of 21
for the supplier Company Y. Consider the example above based upon the chronology of events and the accounting impact of process:
Event
Company X books order to a 3rd party with a warehouse designation of Company Y
Set of Books
X Y
Debit
None
Credit
None
Trade Receivables Company Y picks and ships the goods against Company Xs sales order X Cost of Goods Sold (Based on Standard Cost) Inventory The Create Inter-company AR Invoice Process Runs. Autoinvoice is run for Intercompany Invoices The Create Inter-company AP Invoice Process Runs. Expense Import is run for Inter-company AP Invoices X Y Cost of Goods Sold (Based on Transfer Pricing) Inter-company Payable None None None Inter-company Receivables Revenue, Freight, and Tax (Based on Transfer Pricing) Revenue, Freight, and Tax (based on 3rd Party Pricing)
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 its 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.
Page 5
of 21
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.
Sales Order
Product Shipment
Logical Flow
AP Invoice
AP Invoice
Org 327
AR Invoice
AR 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.
Page 6
of 21
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 Intercompany 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.
Page 7
of 21
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.
Page 8
of 21
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.
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 . . .
Page 9
of 21
Page 10
of 21
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.
Page 11
of 21
Page 12
of 21
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.
Page 13
of 21
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.
Page 14
of 21
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.
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.
Page 15
of 21
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.
Page 16
of 21
XYZ Inter-company Invoices - Shipping XYZ_INCIAR_SET Oracle Inventory Process Inter-company AR Invoice between Company Y and X MCCURRYD
XYZ Inter-company Invoices - Shipping Stage INCIAR- Company Y Auto-Invoice Inter-co Invoices
Oracle Inventory
Generate AR Invoice for Shipping O.U. Run Auto-invoice for Inter-company AR invoices
Request Set for the Selling Operating Unit Request Set Set Set Code Application Description Owner
XYZ Inter-company Invoices - Selling XYZ_INCIAP_SET Oracle Inventory Process Inter-company AP Invoice between Company X and Y MCCURRYD
XYZ Inter-company Invoices - Selling Stage INCIAP- Company X Import Inter-co AP Invoices
Oracle Inventory
Generate AP Invoice for Selling O.U. Run Expense Report Import Intercompany AP invoices
SELECT
Page 17
of 21
(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
Page 18
of 21
Page 19
of 21
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.
Page 20
of 21
Page 21
of 21