EBS Multi Organisation Article and thoughts
Introduction
The scope of this document is to describe and explain the concepts and operational impacts of a multi organizations set up architecture (« Multi Org » feature) within Oracle Applications.
Multi Org can be set up in a single installation of Oracle Applications. It enables the system to handle as many organizations as needed, from the legal entity to the warehouse.
The Multi Org feature appeared in Release 10.6. In the former releases, Oracle already allowed to configure many sets of books in the same Oracle Applications database, but the subledger installation (AP or AR) could only be done for one set of books. The set-up of a second subledger meant physical duplication of the tables.
Multi-org now allows :
• To set up several sets of books linked to subledgers without duplicating data and access from one database environment.
• To separate and secure the data inside one « Business Group ».
There currently is a multi organization Oracle instance in production for Lucent. The aim here is to understand how this current architecture can be adapted to the SPN Lite project scope for 9/1 (introducing the Hilversum office sales order management for GCM products)
This document will be structured in three main sections:
1. Definition of Multi Org structure : this will describe the role of each organization type within Multi Org and how they are structured.
2. System and module impacts of Multi Org : this chapter will explain how the Multi Org structure influences system access and each module of Oracle Applications, in order to better understand the impacts of the current structure on the target solution.
3. Limitations of Multi Org : both from a general perspective and for a multiple operating units context.
1.1 Multi Org Definition structure
1.1.1 Organization types definition
In a Multi Org structure there can be 5 kinds of organization which interact :
• The Set of Books
• The Business Group
• The Legal entity
• The Operating Unit
• The Inventory Organization
Each organization has an impact at a different level.
1.1.1.1 Set of Books
A financial reporting entity that partitions General Ledger information and uses a particular chart of accounts, functional currency, and accounting calendar. When you use Oracle General Ledger, you choose a responsibility that specifies a Set of Books. You will only be able to see information regarding this chosen Set of Books.
The Set of Books is the most structuring organization within Multi Org.
It stands for the highest organization level in the system and is represented by a particular functional currency , calendar and chart of accounts (or flexfield structure for accounting and analytical purposes). The General Ledger (GL) module secures all information by set of books only.
It is possible to define as many sets of books as necessary. In the case of multiple sets of books with different currencies, it is possible to define a consolidation set of books in GL in order to aggregate the accounting information in one currency.
.
1.1.1.2 Business Group
An organisation that represents the consolidated enterprise, a major division, or an operation company. This entity partitions Human Resources Information.
Multiple Set of Books can share the same business group or they share the same business group attributes, including HR flexfield structures.
The Business Group represents a group of employees. All human resources information is secured by Business Group in Oracle. For example, when you request a list of employees, you see all employees assigned to the business group of which your organization is a part.
Two tables in the Oracle Projects module are partitioned by business group : burden schedules and resource lists.
Multiple sets of books can share the same business group.
.
1.1.1.3 Legal Entity
An organisation that represents a legal company for which you prepare fiscal or tax reports. You assign tax identifiers and other relevant information to this entity. A Legal Entity is associated with a Set of Books and Business Group.
Because Intrastat information is registered at Legal Entity Level, per country a Legal Entity must be created. This corresponds to the requirement of multiple Set of Books (at least one per country).
There are currently only a few features provided in Oracle Applications for legal entities, but future releases may include more reporting possibilities by legal entity.
1.1.1.4 Operating Unit
The Operating Unit is the level of the structure where data in Accounts Receivable, Order Entry, Accounts Payable, and Oracle Purchasing are partitioned and secured : each user sees information only for the operating unit to which his or her responsibility gives access.
It may represent a division or a department of the overall company.
Impact 1 : all sales orders, all customer and supplier invoices, and all purchase orders are together. Customer and vendor « site » information are also separate for each operating unit (see 1.3.1.1).
1.1.1.5 Inventory Organization
An Inventory Organization is an organization for which you track inventory transactions and balances, and/or an organization that manufactures or distributes products. Examples include (but are not limited to) manufacturing plants, warehouses, distribution centers, and sales offices.
A sales office is usually an operating unit, since order entry takes place at that level.
The following applications secure information by inventory organization: Oracle Inventory, Bills of Material, Engineering, Work in Process, Master Scheduling/MRP, Capacity, and Purchasing receiving functions.
For example the inventory organization you specify for each operating unit determines the items available in Purchasing. You can only choose an inventory organization that uses the same set of books as your operating unit.
1.1.2 Current Multi Org structure
The structure is a multilevel structure with logical and operational relationships between the organizations.
1.2 Module by module impacts and data visibility
1.2.1 Impacts on data separation in each module
The following charts will show which data is shared by all organizations and which data is partitioned by operating unit for each of the Oracle Applications module.
1.2.1.1 Visibility in General Ledger
The General Ledger module only works by set of books and not by operating unit.
The impacts of using one set of books are mainly the following :
• accounting periods opening and closing procedures are centralized for all locations.
• all transactions are converted and only available in the set of books functional currency.
• all entries are together (imported or entered) and can be seen without partition by operating unit.
Standard single–set–of–books product features do not support the view of secured data across operating units. You have to create custom reports or windows to view secured data across operating units.
1.2.1.2 Visibility in Accounts Payable
Common Data Data secured by Operating Unit
Configuration Payment terms
Payment methods
Paygroup
Payment formats
Expenses report templates
Holds General options
Expenses report templates (lign level)
Distribution sets
Tax codes
Suppliers Supplier header :
Supplier name,
Employee name,
supplier number,
taxpayer ID,
supplier type,
Suppliers sites :
site address
bank contacts
intra CEE ID
invoice limit amount
invoice hold
payment hold
default invoice data
Bank data Banks and agencies Bank accounts
Payment documents
Schedule
Reports Aging bucket definition AP reports
Expense allocation report
Aging bucket report
Invoices Numbering Invoice batches
Invoices
Expenses Expenses entry and inquiry
Payments Payment batches
Manual payments
Calendar Opening and closing periods
1.2.1.3 Visibility in Accounts Receivable
Common Data Data secured by Operating Unit
Configuration Receipt terms
Invoicing and accounting rules
Adjustment limits
Séquences d’auto-lettrage
Receipt methods
Bank agencies
Aging buckets
Dunning letters
Collectors
Transaction types
Transaction sources
Standard ligns
Auto-accounting
Types d’événement
Distributions
Receipt terms – associated accounts
Sites and tax rates
Bank accounts
Aging buckets dates
Vendors
Customers Customer header :
customer name,
customer number,
profile class
category Customer address :
customer address
bank accounts
default invoice data
Bank data Banks and agencies Bank accounts
Associated key flexfields
Reports Aging definition AR Reports
Aging reports
Invoices Invoice batches
Invoices
Adjustments
Receipts Receipt import formats Receipts formats
Manual receipts
Receipt interface
Receipt reconciliation
Calendar Opening and closing periods
1.2.1.4 Visibility in Purchasing
Common Data Data secured by Operating Unit Data secured by Inventory Org.
Configuration Employees
Buyers
Sites
Contrôles par poste Purchasing options Receptions options
Receptions
Suppliers Supplier header :
Supplier name,
Employee name,
supplier number,
taxpayer ID,
supplier type,
Suppliers sites :
site address
bank contacts
intra CEE ID
invoice limit amount
invoice hold
payment hold
default invoice data
Matching Match PO/Invoice
Requisitions/PO PO numbering Orders
Internal demands
Internal demand lignes
Quotations
Quote analysis
Approvals Approval groups
Documents controls
Calendar Opening and closing periods
1.2.1.5 Visibility in Inventory
Common Data Data secured by Inventory Org
Configuration Hazard classes
Units of measure
Units of measure conversions
Quality control codes
Items Item key flexfield (unique)
Items references
Item categories
Item localizations
Item references
Receipts Receipts options
Receipts
1.2.1.6 Visibility in Order Entry
Common Data Data secured by Operating Unit
Configuration All except Order Types and Salespersons Order Types
Salespersons
Customers Customer header :
customer name,
customer number,
profile class
category Customer address :
customer address
bank accounts
default invoice data
Sales Orders Ship-from organizations (inventory organizations) Enter sales order
View sales order
Shipping Ship Confirm (except Process Inventory) Pick release
Inventory interface
Update Shipping Information
1.2.1.7 Visibility in Projects (EF&I scope)
Non-setup entities are underlined.
Common Data Data secured by Operating Unit
Human Resources Locations
Organizations
Organization hierarchies
Jobs
Employees (by Business Group)
Projects Project statuses
Project classifications
Service types
Project role types
Project customer relationships
Contact types
Implementation options:
Project numbering
Project/task owning organization hierarchy + start organization
Project types
Project templates
Projects
Budgets Budget types
Budget entry methods
Budget change reasons Resource lists
Budgets
Expenditures Expenditure categories
Expenditure types
Non labor resources
Transaction sources
Implementation options:
Expenditure/event organization hierarchy + start organization
Cost rates
Expenditures:
Hours
Expenses
Usages
Purchase orders / supplier invoices
Billing Agreement types
Billing cycles
Payment terms
Customers
Invoice formats
Event types
Revenue categories Implementation options:
Customer invoice numbering
Invoice processing level
Agreements
Customer sites
Bill rate schedule
Customer invoices
Inquiries Implementation options:
Default reporting organization hierarchy + start organization
Resource lists
Accounting Implementation options:
Interface to General ledger
Set of Books
PA period types
PA periods
Auto accounting
Note: Expenditures can be charged to a project in a different operating unit from the expenditure operating unit, as long as the two operating units are associated with the same GL set of books, HR business group, and PA period type.
1.2.2 Impacts on data access
Under Multi Org configuration, data is separated at the access time. When a user connects to Oracle Applications, it uses one or several « responsibilities » (set of screens and menus). Each responsibility is always linked to one set of books, one business group, and one operating unit. Therefore users only have access to information which are relevant to one organization at a time. It is not possible to create a « cross-operating units » responsibility.
1.3 Limitations of Multi Org
1.3.1 General limitations
1.3.1.1 Suppliers and customers in the database
Supplier and customer tables are shared across operating units. However, you must define supplier sites and customer addresses for each operating unit. For example, if multiple operating units buy from the same supplier site, the supplier site must be defined once for each operating unit.
Taxpayer ID and Federal/State Reportable options still have to be entered at the supplier and customer header levels. If a global customer or supplier has subsidiaries in multiple countries, you have to define a separate customer or supplier for each country.
For customers, you should not specify any centralized statements site, centralized dunning site, customer–level order type, or customer–level salesperson because customer addresses, order types, and salespeople are not shared across operating units. Therefore, centralized statements and centralized dunning letters are not supported. You should also specify the tax code at the customer header level only if you have identical tax codes across operating units, otherwise you should specify the tax code for each newly created customer site. You should also specify the freight carrier at the customer site level, because carriers are secured by inventory organizations.
For both suppliers and customers, it is not possible to have a global view of all the existing sites across operating units through standard reports.
1.3.1.2 Shipping
You must run pick release once for each operating unit.
In the Confirm Shipments window, you can view orders across operating units. However, you cannot use the ”Process Online” option, which processes the shipping confirmation and updates inventory on–line. You must run the Update Shipping Information and Inventory Interface programs in batch mode for each operating unit.
1.3.1.3 Inventory transfers between organizations
In–transit shipments across organizations in different sets of books are not supported.
1.3.1.4 Kits on intercompany invoices
When the Automatic Intercompany Invoices program generates receivable invoices for kits, individual item descriptions (rather than kit descriptions) are displayed.
1.3.1.5 Window and report titles
Report and window titles will always show the set of books name, rather than the operating unit or legal entity name.
1.3.2 Limitations in multiple operating units per set of books context
1.3.2.1 Document sequencing
Document sequencing (invoices, payments, orders, journals, etc.) is only available at the set of books level. Legal entities for the same set of books must share document sequences. If an organization requires its own numbering sequence, you must set up a separate set of books for it.
1.3.2.2 Periods management
All of the operating units that share a set of books also share the same Payables, Receivables, and Purchasing period statuses. You must coordinate period status control between operating units that share the same set of books. When you update the period status to Open in one operating unit, that period is open for all operating units in the same set of books.
When you update the period status to Closed in one operating unit, you need to resolve any unposted transactions in that operating unit. Then, reopen the period, so that the next operating unit for the same set of books can try to close. Continue this cycle until the last operating unit for the set of books actually closes the period for all operating units.
1.3.2.3 Drilldown / Zoom functionalities
When you drill down from Oracle General Ledger to Oracle Payables and Oracle Receivables, you can view only the subledger details in the related operating unit.
This limitation affects the subledger reporting feature available with Oracle Financials for Europe (« localizations ») because some reports provide supplier and customer transaction information based on the operating unit, but display account balances for the whole set of books. If you intend to use subledger « localized » reporting, you should s
