MULTI - ORG

Introduction

With Release 10.9 of Oracle Applications support for complex organizations has been enhanced. There is a great deal of confusion about what Multi-Org does, and doesn’t do and how it can be demonstrated to prospects and customers. The purpose of this document is to provide a simple overview of what Oracle Multi-Org does, explain Oracle Multi-Org terms and give some examples of how Oracle Multi-Org can be used by complex business organizations. For more information I strongly recommend;

Visit the Multi-Org web site at http://www-apps.us.oracle.com/multiorg/ Multi-Org Statement of Direction, available from the Multi-Org web site Modeling a Multi-Business Unit Enterprise (Word), available from the Multi-Org web site Multi-Organization Features (PowerPoint), available from the Multi-Org web site Multiple Organizations in Oracle Applications, Part# A50771-1

What does Oracle Multi-Org give me?

Support for multiple organizations without multiple installations: You can define multiple organizations and the relationships among them in a single installation of Oracle Applications. In the past if you had multiple business entities you would have to install Oracle Applications modules multiple times within the same database. This is no longer required, as a single installation will now support any number of different logical business entities.

Secure access: You can assign users to an ‘Operating Unit’. Users can then only see and work with data which is relevant to them. The most visible example is Customers (Receivables) and Suppliers (Payables). Users will see all customer and supplier headers but will only be able to see the sites which are relevant to that ‘Organization’.

Sell and ship products from different ‘Legal Entities’ (in different ‘Sets of Books’): You can sell goods from one ‘Legal Entity’ in a ‘Set of Books’ and ship the goods from another ‘Legal Entity’ using another ‘Set of Books’. Oracle will automatically create the inter-company sales entries to accounts payable and accounts receivable.

Automatic Accounting for Internal Orders: You can create internal requisitions (via Sales Orders) in one ‘Inventory Organization’ and ship the items from another ‘Inventory Organization’ with the correct inter-company invoicing being automatically created. The two ‘Inventory Organizations’ must be in the same ‘Set of Books’

Purchase and receive products between ‘Inventory Organizations’: You can enter purchase orders in one ‘Inventory Organization’ and receive the inventory into different ‘Inventory Organization’ (within the same ‘Set of Books’).

Plan any ‘Inventory Organization’ in any ‘Set of Books’: Using the ‘Planners Workbench’ you can see and plan any ‘Inventory Organization’ defined in the system regardless of which ‘Operating Unit’ or ‘Set of Books’ it is related to. You cannot create replenishment requests for ‘Inventory Organizations’ outside of the ‘Operating Unit’ you are in when you created the plan.As well as this new Multi-Org specific functionality doesn’t forget the existing functionality of Oracle Applications which is related to solving the same business problems...

Automatic inter-company accounting within a single ‘Set of Books’: If you create accounting entries which span more than one ‘Balancing Segment’ in either Oracle General Ledger, Oracle Payables or Oracle Receivables the correct inter-company entries will be created automatically. This is limited to transactions within one ‘Set of Books’.

Consolidations: You can consolidate any chart of accounts structure in any ‘Set of Books’ together using the General Ledger Consolidation features.

Summary of Terms

Set of Books: This is the highest level at which the financial entities are segregated. Any entity that has a particular chart of accounts structure, functional currency or calendar must be a separate ‘Set of Books’.

Organization: Any entity you define using the ‘Define Organizations’ form is called an ‘Organization’. ‘Organizations’ are then assigned ‘Classifications’. The ‘Classification(s)’ an ‘Organization’ is assigned determines its type and use. ‘Business Group’, ‘Legal Entity’, ‘Operating Unit’, ’Inventory Organization’, and ‘HR Organization’ are all ‘Organization Classifications’. An ‘Organization’ may be assigned more than one ‘Classification’ e.g. the ‘Organization’ Vision Operations may be assigned the ‘Classifications’ of ‘Legal Entity’, ‘Operating Unit’, ‘HR Organization’ and ‘Inventory Organization’

Business Group: Represents the highest level in the structure. The consolidated enterprise or a major division of a company. Currently ‘Business Group’ has no other purpose but to segregate HR information. If you request a list of employees (in any module) you will only see those employees in the ‘Business Group’ of which your ‘Operating Unit’ is a part. Multiple ‘Legal Entities’ can relate to a single ‘Business Group’.

Legal Entity: Represents a legal company for which you prepare fiscal or tax reports. A ‘Legal Entity’ relates to a single ‘Set of Books’. Currently ‘Legal Entity’ has very limited use outside of Intrastate movement reporting.

Operating Unit: Any autonomous organization which uses Oracle Receivables, Oracle Payables, Oracle Order Entry, Oracle Purchasing and Oracle Projects. An ‘Operating Unit’ is associated with a single ‘Legal Entity’. Information is secured by ‘Operating Unit’ in the above products with some shared information (e.g. customer and supplier names with sites being specific to each ‘Operating Unit’)

Inventory Organization: An ‘Organization’ for which you track inventory transactions and balances. Oracle Inventory, Bills of Material, Engineering, Work in Progress, Master Scheduling / MRP, Capacity and Purchasing (receiving) secure information by ‘Inventory Organization’. ‘Inventory Organizations’ may be related to any ‘Operating Unit(s)’ within the same ‘Set of Books’. The relationship between ‘Inventory Organization’ and ‘Set of Books’ is used for financial purposes only (creating requisitions and replenishing supplies).

Page 2

HR Organization: ‘HR Organizations’ are only utilized by Oracle HR and Oracle Projects products and have no impact on the Financial or Manufacturing applications. This facilitates a complex organization structure for HR tracking but a more simplified structure for the operational side of the business

Note: There is nothing to stop one entity being a ‘Business Group’, ‘Legal Entity’, ‘Operating Unit’ and ‘Inventory Organization’ all at the same time (or any combination). This would assume a very simple organization structure.

Responsibility: This is a grouping of functionality and system data often related to a job role or responsibility. ‘Responsibilities’ are associated with a ‘Set of Books’, ‘Operating Unit’ and ‘Inventory Organization’ where appropriate through profile settings (e.g. MO: Operating Unit defines the ‘Operating Unit’ for that ‘Responsibility’).

Balancing Segment: This is a segment in the ‘Accounting Flexfield’ structure (usually the Company segment) at which all accounting entries must balance. There may be multiple companies within the same structure; each of these must balance within itself. All required inter-company entries will automatically be created within the ‘Set of Books’ to ensure companies can never be out of balance.

Security Rules: Security rules limit (by responsibility) the values of a ‘Flexfield’ which the user will see. e.g. a user will only see the ‘Department’ values in the ‘Accounting Flexfield’ which they have authority to see.

Page 3

Multi-Org Example 1:

Here is a generic example of how Oracle Multi-Org ‘sees’ a multi-level company setup. From the following diagram please note:

A ‘Business Group’ is the highest level of the structure and has no accounting impact. The ‘Business Group’ determines which employees will be available to ‘Sets of Books’ and ‘Operating Units’ related to that ‘Business Group’

‘Set of Books’ is the highest level which impacts the accounting side of the business ‘Set of Books’ is associated with a single ‘Business Group’, multiple ‘Sets of Books’ may be associated with

a single ‘Business Group’ Each ‘Set of Books’ may have a different chart of accounts structure, calendar or functional currency Each ‘Legal Entity’ is associated to a single ‘Set of Books’, multiple ‘Legal Entities’ may be associated with

the a single ‘Set of Books’ Each ‘Operating Unit’ is associated with a single ‘Legal Entity’, multiple ‘Operating Units’ may be associated

with a single ‘Legal Entity’ An ‘Inventory Organization’ may be associated with multiple ‘Operating Units’ within the same ‘Set of

Books’

Inven to ryO rgan iza tion

Inven to ryO rgan iza tion

O pera tingU n it

Inven to ryO rgan iza tion

O pera tingU n it

Lega l E n tity

O pera tingU n it

Inven to ryO rgan iza tion

O pera tingU n it

Lega l E n tity

S e t O f B ooks S et o f B ooks S et O f B ooks

B us iness G roup

Note: Currently it is recommended by Oracle Applications Development to keep a one-one-one relationship between ‘Set of Books’, ‘Legal Entity’ and ‘Operating Unit’. This restriction is recommended for the following reasons:

Document Sequencing (important in European countries) is within the ‘Set of Books’ level Standard reports are at the ‘Operating Unit’ level Period status control is at the ‘Set of Books’ level e.g. If you close the period in Oracle Payables, all equivalent

Oracle Payables periods will close in all ‘Operating Units’ within the same ‘Set of Books/Legal Entity’.

Page 4

Multi-Org Example 2:

Given the generic example above, lets describe the setup of a fictitious company ‘Vision Enterprises’. Vision Enterprises is the basis for the new Vision Demonstration environment, and is defined as a multinational enterprise consisting of four autonomous businesses;

Vision Operations, a manufacturing operation Vision Distribution, a distribution company Vision Services, a project based services company Vision ADB, an average daily balance based enterprise

These entire businesses roll up to a consolidated, UK based holding company called Vision Corporation. Vision Operations has four inventory sites and Vision Distribution has one inventory site. All of the Vision businesses have autonomous accounting, accounts payable and accounts receivable organizations. All sales orders are received in Vision Operations with some shipments being made from Vision Distribution. The following is how this would be setup in Oracle Applications:

- B us in ess G ro up- H R O rgan iza tion

- In ve n to ry O rg- H R O rg a n iza t io n

- L e g a l E n t i ty- S e t o f B o o ks- O p e ra t in g U n it- H R O rg a n iza t io n

P lan tM 1

P lan tM 2

P lan tS 1

P lan tD 1

V is ionO pera tions

P lan tD 2

V is ionD is tribu tion

V is ionS ervices

V is ionA D B

V is ionC orpora tion (U K )

This setup allows the following:

There is a single ‘Business Group’ which means that all employees are available for all parts of the organization

Each of the four ‘Legal Entities’ have their own ‘Set of Books’, allowing autonomous control over the accounting structure while still allowing segment values to be shared across ‘Set of Books’ where appropriate. e.g. the account segment values in the chart of accounts is shared by Vision Operations, Vision Distribution, and Vision Enterprises even though Vision Enterprises has a three segment (co-dep-account) chart of accounts

Vision Corporation has a functional currency of ‘GBP’ (Pounds Sterling), Vision Distribution has a functional currency of ‘SND’ (Singapore Dollars), all others have a functional currency of ‘USD’ (US Dollars)

Consolidations bring financial information together from all subsidiaries into Vision Corporation Sales orders can be taken into Vision Operations and shipped from Vision Distribution with all correct

accounting (and inter-company invoicing) being created automatically Customer and supplier names are shared across all ‘Operating Units’ however customer and supplier sites are

specific to each operating unit Each ‘Operating Unit’ can setup it’s Oracle Payables and Oracle Receivables options to best suit the way that

‘Operating Unit’ does business ‘Security rules’ can limit the data, including accounts a user has access to Material planners can plan all ‘Inventory Organizations’ using the ‘Planners Workbench’. They must however create the replenishment requests from within the correct ‘Operating Unit’.

Page 5