Release 11i Multi-Org Today

An Oracle White Paper

December 2001
 Release 11i Multi-Org Today

EXECUTIVE OVERVIEW
The purpose of this document is to provide an overview of Multi-Org functionality
and recent features in Release 11i of the Oracle E-Business Suite.

INTRODUCTION
This document is organized into five sections:
• What is Multi-Org?: This section discusses what Multi-Org is and the
benefits it provides.
• Multi-Org Setup: This section streamlines the steps that are involved in
setting up a Multi-Org environment.
• New Multi-Org Features in Release 11i: This section presents the new
features available in Multi-Org for Release 11i of the Oracle E-Business Suite.
• A Multi-Org Example: This section illustrates the relationships and
interaction between the organizational units of a fictitious, global enterprise
modeled in the Oracle E-Business Suite.
• Frequently Asked Questions: This section addresses some frequently
asked questions about Multi-Org.

WHAT IS MULTI-ORG?
Introduced as standard functionality in Release 10.7, Multi-Org is a key component
of the Oracle E-Business Suite that:
• Provides secure access to the different organizations of the enterprise
• Supports multiple organizations of the enterprise structure in a single
database

Secure Access by Operating Unit

In Release 11i, an individual Operating Unit is assigned to an individual application
Responsibility. To see and work with data that is relevant to a specific Operating
Unit, users choose the appropriate Responsibility after logging on to Oracle
Applications.

Release 11i Multi-Org Today Page 2

Operating Unit

In the applications of the E-Business Suite that use Multi-Org functionality, an

Operating Unit is the primary organization unit through which you secure
transaction data, but also create, process, and report on financial applications data.
An Operating Unit can be used to model an autonomous business unit that
performs one or more business activities and creates transactions with financial
impact.
Transaction data with financial impact and some setup data are partitioned by
Operating Unit in the following applications:
• Oracle Cash Management
• Oracle Order Management and Shipping Execution
• Oracle Payables
• Oracle Projects
• Oracle Purchasing
• Oracle Property Manager
• Oracle Receivables
• Oracle Release Accounting
• Oracle Sales Compensation
• Oracle Sales and Marketing
• Oracle Service
• European Localizations
• Latin America Localizations
• Regional Localizations

Organizations

In general, an organization can be a company, department, division, cost center, or

virtually any other organizational unit within a business.
The organizational units relevant to Multi-Org in the E-Business Suite are defined
and stored using the Oracle Human Resources (HR) application. Organizations are
assigned classifications that determine their type and use. These classifications
include “Business Group”, “GRE/Legal Entity”, “Operating Unit”, “Inventory
Organization”, and “HR Organization”.
The organizations described below are the cornerstones for securing transactions
and modeling an enterprise in the Oracle E-Business Suite. How the user
assembles these building blocks to logically model the enterprise dictates the
permitted interaction of the organizational units and the flow of transactions
between them.

Release 11i Multi-Org Today Page 3

Business Group

The purpose of the Business Group is to partition human resource information.

The Business Group is the highest level in an organization structure hierarchy in
the E-Business Suite. You can use the Business Group to model the consolidated
enterprise or a major division of a company that is an employer.

HR Organization, and GRE/Legal Entity in Oracle Human Resources

The HR Organization classification is applied to the organizations to which the

user assigns employees. This includes Business Groups, and in the United States it
is also applied to organizations of type “GRE” (Government Reporting Entities).
The GRE in the Oracle Human Resources products is the same organization as the
Legal Entity that appears in the Oracle Financials products. The GRE represents
the real-world legal entity that pays employees, withholds their taxes, and provides
reports on various matters concerning them to government agencies. In the
Financial Applications of the E-Business Suite the Legal Entity appears as
GRE/Legal Entity when the Oracle Human Resources application is installed.

Legal Entity in Oracle Financials Products

The Legal Entity represents a legal company for which the user prepares fiscal or
tax reports. Tax identifiers and other relevant information are assigned to this
entity.
The GRE/Legal Entity organization classification in the financial applications is
used primarily for Cross-Organization Reporting for selected reports in Release 11i
of the E-Business Suite. The role of the Legal Entity will be enhanced in future
releases of the Oracle E-Business Suite.

Operating Unit

The Operating Unit is the organization unit through which you create, process,
report on, and secure financial applications data.

Inventory Organization

The Inventory Organization is an organization for which you track inventory

transactions and balances.
Inventory Organizations secure information in the following applications:
• Oracle Advanced Supply Chain Planning
• Oracle Bills of Material
• Oracle Capacity
• Oracle Costing
• Oracle Engineering
• Oracle Inventory

Release 11i Multi-Org Today Page 4

 • Oracle Master Scheduling/MRP
• Oracle Order Management (shipping functionality)
• Oracle Purchasing (receiving functionality)
• Oracle Service, Quality
• Oracle Work in Progress

Set of Books

In the E-Business Suite, a Set of Books is the financial reporting entity that secures
journal entries and account balances within the Oracle General Ledger application.
It is neither an organization nor an organization classification in the context of
Multi-Org.
Generally, a Set of Books is used to represent a legal entity or a group of legal
entities. Each Set of Books may have a different chart of accounts structure,
calendar and functional currency.

Organization Structure in the Oracle E-Business Suite

It is the relationship of a Set of Books, Legal Entity, Operating Unit and Inventory
Organization that defines what is referred to as a Financial Organization Hierarchy
in the Oracle E-Business Suite.

Business Group

Set of Books

GRE/Legal Entity

Operating Unit

Inventory
Organization

• A Business Group is the highest level of the structure and has no

accounting impact. Legal Entities, Operating Units and Inventory
Organizations all belong to a single Business Group. The Business Group

Release 11i Multi-Org Today Page 5

 also determines which employees will be available to the Sets of Books and
Operating Units related to that Business Group.
• A Set of Books is the highest level that impacts accounting. A Set of Books
is associated with a single Business Group, but multiple Sets of Books may
be associated with a single Business Group.
• Legal Entities are associated with a Set of Books. One or more Legal
Entities may be associated with a single Set of Books, and multiple Legal
Entities may be associated with a single Business Group.
• Operating Units belong to a Legal Entity. One or more Operating Units
may be associated with a single Legal Entity.
• Inventory Organizations belong to an Operating Unit. An Inventory
Organization can serve multiple Operating Units within the same Set of
Books. Inventory Organizations can be associated with any Operating
Unit(s) within the same Set of Books. The relationship between Inventory
Organizations and a Set of Books is financial (creation of requisitions and
replenishment of supplies). For example, requisition transactions are
created against an Inventory Organization, which then have a financial
impact in the Set of Books.

Responsibilities

In the E-Business Suite, the Responsibility is a grouping of functions often related

to a job role or level of responsibility in a business. Application Responsibilities
may be explicitly associated with a Business Group, Operating Unit, Inventory
Organization, and Set of Books through System Profile Option settings.

Transactions and Setup Data Security in Subledgers

The “MO: Operating Unit” profile option links a Responsibility to a given

Operating Unit and thus dictates the data that a user may see. This profile option
must be set for each Responsibility in a Multi-Org environment.

Set of Books in Subledgers

The Set of Books partitions the accounting representation of the financial data.
The Operating Unit is associated with a Legal Entity and Set of Books through
setup attributes. When working within the subledger applications, the Operating
Unit associated with the application Responsibility dictates the Set of Books that
will receive transactions interfaced from those subledger applications.

Set of Books Security in General Ledger

In Oracle General Ledger, the application Responsibility is explicitly tied to a single

Set of Books through the “GL: Set of Books Name” profile option. That link
dictates which Set of Books data that a user can work with.

Release 11i Multi-Org Today Page 6

Once transactions are posted in the General Ledger, a user can drill down to the
source transaction in the subledger applications from General Ledger for any
Operating Unit. The “MO: Operating Unit” profile has no effect on the General
Ledger Responsibilities when drilling down to any subledger transactions that make
up a given General Ledger account balance.
When creating batches in Oracle General Ledger, the “MO: Operating Unit”
profile of the user’s Responsibility determines what input and output tax codes can
be used.

Security Rules for Accounting Flexfields in Sub Ledgers and General Ledger

Security rules provide accounting data security within the General Ledger and in
the subledger applications.
Security rules are created in the General Ledger application and are attached to any
application Responsibility. They determine the range of values of the Accounting
Flexfield that a user can see when working with transactions in the subledgers or
the General Ledger application. For example, a security rule can be constructed to
allow a user to enter or see only specific values of a certain segment in the
Accounting Flexfield when entering transactions in a subledger application such as
Oracle Payables. Similarly, a security rule can be attached to a General Ledger
Responsibility to limit access to journal entries based on certain values of a segment
in the Accounting Flexfield.

Support for Multiple Organizations Without Multiple Installations

Multiple installations of a database and applications to support many organizational
units of a global enterprise can result in fragmented and untimely data.
The Multi-Org architecture utilizes native database features to build a security layer
that allows you to logically partition all your application data in one database,
instead of physically partitioning data with multiple instances and even multiple
application installations.
Supported by the Multi-Org architecture, a single global instance promotes efficient
and effective decision making with timely, reliable, fact based information.
Consolidation of data into a single instance works to reduce expenditures on
hardware and IT personnel, and makes it possible to simultaneously propagate
software updates to all your Multi-Org Operating Units.
The Multi-Org architecture also provides you the flexibility to promptly make
globally available any change in your organizational structure.
Oracle itself relies on the E-Business Suite and the Multi-Org architecture native
therein to run its global operations.

Release 11i Multi-Org Today Page 7

MULTI-ORG SETUP
The following are the summarized steps for implementing Multi-Org in Oracle
Applications or when converting from a Non Multi-Org environment to a Multi-
Org environment.

Step 1 – Develop an Organization Structure

A successful implementation of Multi-Org begins with defining your organizational
structure in the multi-level hierarchy used in Oracle Applications. The levels
include:
• Business Group
• Set of Books
• Legal Entity
• Operating Unit
• Inventory Organizations

Step 2 – Define Set of Books

After determining your accounting calendar, currency and chart of accounts
structure, define all necessary Sets of Books.
If your enterprise structure will require multiple Business Groups, you should
define each Set of Books before Business Groups.

Step 3 – Define Locations

Define the names and addressees for the locations that you will use within your
enterprise.
You should define locations for your Legal Entities and your Inventory
Organizations. Oracle Applications uses location information for activities such as
requisitions, receiving, shipping, billing, and employee assignments.

Step 4 – Define Business Groups (Optional)

You should define all your Business Groups before defining any other type of
organization. You must have at least one Business Group. For fresh installations,
Oracle Applications provide one pre-seeded Business Group, “Setup Business
Group.”
You can define additional Business Groups as needed for your enterprise. We
recommend that you modify the pre-defined Business Group instead of creating a
new one. If you decide to define a new Business Group, instead of modifying the
pre-defined Business Group, then you need to set the “HR: Business Group”
profile option at the Responsibility level for the new Business Group. Oracle
Human Resources automatically creates a security profile with the Business Group
name when you define a new Business Group.

Release 11i Multi-Org Today Page 8

Step 5 – Associate Responsibilities with Business Groups (Optional)
If you have multiple Business Groups, or if you do not choose to use the default
Business Group provided by Oracle Applications, you must associate each
Responsibility to one and only one Business Group. If you are upgrading to Multi-
Org, you must also associate previously created Responsibilities to the appropriate
Business Group.
You associate a Business Group with a Responsibility via the “HR: Business
Group” system profile option.

Step 6 – Define Organizations

Define all your other organizations, i.e. Legal Entities, Operating Units, and
Inventory Organizations.
You can perform this step and the next step (Define Organization Relationships) at
the same time. The steps are presented separately to emphasize the difference
between the organizational entity and the role it plays in your organizational
structure.

Step 7 – Define Organization Relationships

Define your organization relationships by assigning classifications to each
organization.
Attributes of certain classifications relate organizations and the roles they play.
You can classify an organization as any combination of Legal Entity, Operating
Unit, and Inventory Organization.
Specify your organization classifications in the following order:
1. Legal entities. Attach the Legal Entity to a Set of Books.
2. Operating units. Attach the Operating Unit to the correct Legal Entity and
Set of Books.
3. Inventory organizations. Attach the Inventory Organization to the correct
Operating Unit, Legal Entity and Set of Books.
If you have more than one Business Group, change to the Responsibility associated
with the desired Business Group and continues defining your organization
classification.

Step 8 – Define Responsibilities

Define your Responsibilities for each Operating Unit by application.
Carefully consider your naming conventions for the Responsibility names in a
Multi-Org environment. It is a good idea to use abbreviations of the business
function and the organization name to uniquely identify the purpose of the
Responsibility. Examples of naming conventions are Payables Manager Northwest
or Western Receivables Super User.

Release 11i Multi-Org Today Page 9

Step 9 – Set MO: Operating Unit Profile Option
Set the Oracle Applications system profile option “MO: Operating Unit” to link
each Operating Unit to a Responsibility.
You must also define the default Operating Unit by setting the “MO: Operating
Unit” profile option at the site level in the system profile option hierarchy. If this is
a fresh installation, the default Operating Unit can be any Operating Unit you have
defined. If this is an existing installation, you should assign as the default
Operating Unit the Operating Unit to which all existing data should belong.

Step 10 – Convert to Multi-Org Architecture

Run the AutoUpgrade utility adadmin.
One of the options in adadmin is to convert to Multi-Org architecture. Choosing
this option will enable the Multi-Org Support feature as well as add Operating Unit
context to all existing data. This process will also replicate seed data to all
Operating Units that have been defined.
Before your database administrator runs this step, you must have defined an
Operating Unit and set the site-level profile option “MO: Operating Unit” to use
your new Operating Unit. This profile option tells adadmin what Operating Unit it
should use when converting your existing data. If you define additional Operating
Units, the seed data will be replicated for all Operating Units.
Once you have converted to Multi-Org Architecture, the Convert to Multiple
Organization Architecture option does not display on the menu as you have already
Multi-Org installed in your database.

Step 11 – Verify Order Management System Parameters

If you have different item validation organizations for your Operating Units, use
Order Management “System Options” window to set the necessary characteristics
for each Operating Unit. This allows Order Management and Shipping Execution
to default the tax code and revenue account information correctly. The “Item
Validation Organization” setting indicates the Oracle Manufacturing organizations
that items are validated against. All transactable items must be defined in this
organization. This setting was previously controlled through the profile option
“OM: Item Validation Organization”.

Step 12 – Set Profile Options Specific to Operating Unit

Some profile options, including “AR: Receipt Batch Source” and “AR: Transaction
Batch Source”, reference data that is secured by Operating Unit. You must set
these profile options at the Responsibility level. You should choose a value
corresponding to the Operating Unit of the Responsibility.

Release 11i Multi-Org Today Page 10

Step 13 – Define Inventory Organization Security (Optional)
With Inventory Organization security you can restrict Inventory Organization
access to specific Responsibilities. You may want to restrict your manufacturing
users to certain organizations according to your organizational hierarchy.

Step 14 – Implement the Applications Products

After the steps above are complete, go into each Operating Unit and set up the
Oracle Applications products. The following products must be set up for each
Operating Unit in which you intend to perform the functions:
• Oracle Cash Management
• Oracle Order Management and Shipping Execution
• Oracle Payables
• Oracle Projects
• Oracle Purchasing
• Oracle Property Manager
• Oracle Receivables
• Oracle Release Accounting
• Oracle Sales Compensation
• Oracle Sales and Marketing
• Oracle Service
• European Localizations
• Latin America Localizations
• Regional Localizations
Oracle Fixed Assets, Oracle General Ledger, Oracle Inventory, and the rest of the
Oracle Manufacturing products need to be set up only once for the installation, not
once for each Operating Unit.

Step 15 – Secure Balancing Segment Values by Legal Entity (Optional)

Create your security rules to secure data entry and inquiry for balancing segment
values in each Legal Entity.
Assign your security rule(s) to all Responsibilities associated with the Legal Entity's
Operating Units. If you need to further secure balancing segment values for each
Operating Unit of a Legal Entity, you can define additional rules and assign them to
all Responsibilities associated with the relevant Operating Units.

Release 11i Multi-Org Today Page 11

Step 16 – Run the Multi-Org Setup Validation Report (Recommended)
After you have implemented Multi-Org, run the Setup Validation Report to identify
any setup problems. Some of the error conditions that the report finds may be
optionally deleted by running this report, while others require that you change your
setup. All suggested changes can be optionally confirmed so that you may retain
your implementation even if it fails validation.

Optional Steps

After you have implemented Multi-Org and run the Setup Validation Report, you
have the option to set up the following data that may be necessary depending on
your business and regulatory requirements:
• Document sequencing rules
• Intercompany Selling/Shipping relationships
• Cross-Organization Reporting infrastructure.
You also may need to set up Domain Conflicts to maximize the concurrency of
programs.

Step 17 – Implement Document Sequencing (Optional)

Depending on the regulatory and accounting requirements of the countries in
which you operate, it may be necessary to set up document sequencing for each of
the applications that supports it.
Document sequences are generated for transactions at the Set of Books level, i.e. all
Operating Units and all Legal Entities associated with a given Set of Books will
share available numbering sequences. Some countries impose strict legal
requirements for maintaining by legal entity a distinct and auditable number range
for financial transactions. For this reason it is often necessary to maintain a one to
one relationship between a Set of Books and Legal Entity.

Step 18 – Define Intercompany Relations (Optional)

Intercompany relations may be defined for each Selling/Shipping relationship in
your organization. Defining these relationships will allow for the production of
automatic intercompany invoices.

Step 19 – Set Top Reporting Level Profile Option (Optional)

You need to define your reporting levels by setting the “MO: Top Reporting Level”
profile option. This is used for the new Release 11i Cross-Organization Reporting
feature.

Step 20 – Set Conflict Domains (Optional)

When one concurrent program is listed as incompatible with another, the two
programs cannot run simultaneously in the same conflict domain. Two
incompatible concurrent programs may run simultaneously if they are submitted in

Release 11i Multi-Org Today Page 12

different conflict domains. To maximize the concurrency in a Multi-Org
environment, you can set up conflict domains for your Operating Units.

NEW MULTI-ORG FEATURES IN RELEASE 11i

Cross-Organization Reporting
The Cross-Organization Reporting feature introduced in Release 11i, supports the
need to report on critical financial information at different levels of an enterprise.
Cross-Organization Reporting functionality in Release 11i of the E-Business Suite
offers:
• Multiple reporting levels
• Report security
• A broad array of enhanced financial reports
Transactions are processed and secured within the confines of an Operating Unit.
Cross-Organization Reporting capability expands the view of data available through
selected standard reports.
Standard reports from Oracle Payables, Oracle Receivables, Enterprise Tax,
Singapore Localizations, Taiwan Localizations and Thailand Localizations have
been enhanced to support Cross-Organization Reporting.
During report submission two new parameters must be entered: Reporting Level
and Reporting Context.

Reporting Level

The reporting levels that you may choose are controlled via the “MO: Top
Reporting Level” profile option. This profile may be set at the Site level or
Responsibility level in order to restrict access to a single Operating Unit, a Legal
Entity or a Set of Books.
Upon installation of the applications, the “MO: Top Reporting Level” profile
option is defaulted to Operating Unit at the Site level in the profile options
window.
Your system administrator specifies a value for the Top Reporting Level for which
you can run various reports for your Responsibilities. You may report at:
• Set of Books level
You may run reports for the whole Set of Books, a specific Legal Entity
level or a specific Operating Unit.
• Legal Entity level
You may run reports at for a specific Legal Entity level or a specific
Operating Unit.
• Operating Unit level

Release 11i Multi-Org Today Page 13

 You may only run reports for a specific Operating Unit.

Reporting Context

Reporting context is the specific instance of a Set of Books, Legal Entity or

Operating Unit that the Responsibility has access to.

Use the Cross-Organization Reporting feature to produce financial reports at

different levels of your enterprise

Available Cross-Organization Reports

The following is the list of currently available reports that have been enhanced with
Cross-Organization Reporting functionality:

Receivables

• Aging - 4 Buckets Report

• Aging - 7 Buckets Report
• Aging - 7 Buckets - By Amount Report
• Aging - 7 Buckets - By Account Report
• Aging - 7 Buckets - By Collector Report
• Aging - 7 Buckets - By Salesperson Report
• Credit Hold Report
• Customer Credit Snapshot

Payables

• Accounts Payable Trial Balance

• Posted Invoice Register

Release 11i Multi-Org Today Page 14

 • Posted Payment Register
• Payables Accounting Entries Report

Enterprise Tax

• Sales Tax Report

• Tax Reconciliation Report
• Canadian GST/PST Tax Report
• Tax Register
• Use Tax Liability Report
• Tax Audit Trail
• Intra-EU VAT Audit Trail
• Financial Tax Register

Singapore Localizations

• Singaporean GST F5 Report

Thailand Localizations

• Thai Payables Incomplete Tax Invoice Report

• Thai Payment Delivery Report
• Thai Input Tax Summary Report
• Thai Output Tax Summary Report

Taiwan Localizations

• Taiwanese Output VAT Report

• Taiwanese Receivables Government Uniform Invoice Report
• Taiwanese Receivables Zero-Rate Tax Report
• Taiwanese Payables Sales/Purchase Return and Discount Certificate
• Taiwanese Pro Forma 401 Report
• Taiwanese Purchase Return and Discount Report
• Taiwanese Sales Return and Discount Report

A Multi-Org Example
This section presents an example of the possible relationships and interaction
between the organizational units of a fictitious, global enterprise modeled in the
Oracle E-Business Suite. The example highlights how Multi-Org supports a

Release 11i Multi-Org Today Page 15

flexible business model to meet the needs of global enterprises while delivering the
necessary data security across organizational units.
E-Business Enterprises is presumed to be a multinational holding company with
three autonomous businesses:
• E-Business Operations, a manufacturing operation
• E-Business Distribution, a distribution company
• E-Business Services, a project-based services company
Each of these autonomous businesses rolls up to the consolidated UK-based
holding company, E-Business Enterprises.
The parent company, E-Business Enterprises operates in the United Kingdom and
thus maintains its Set of Books in “GBP” (Pounds Sterling). Similarly, E-Business
Distribution operates in “SGD” (Singapore Dollars), and E-Business Services and
E-Business Operations each operate in “USD”.
The manufacturing company, E-Business Operations, has two inventory
organizations for which it produces goods for global consumption.
E-Business Distribution has one inventory organization from which it distributes
goods to its worldwide clientele.
E-Business Operations and E-Business Distribution have their own autonomous
accounting, accounts payable and accounts receivable organizations.
E-Business Services independently manages all aspects of delivering its consulting
services to a worldwide clientele. Data between Eastern and Western E-Business
Services operations are secured by means of two subordinate Operating Units (East
Operations and West Operations) that, in turn, independently manage their
respective accounting, accounts payable and accounts receivable activities.

Release 11i Multi-Org Today Page 16

The diagram further illustrates the relationship between the organizational units of
E-Business Enterprises:

! Business Group
GBP Set of
E-Business Enterprises (UK) ! Legal Entity
Books
! HR Organization

! Business Group
! Legal Entity
E-Business Operations (US)
! HR Organization
! Operating Unit

USD Set of
Books
MFG Plant 1 ! Inventory Organization

MFG Plant 2 ! Inventory Organization

! Business Group
! Legal Entity
E-Business Distribution (SG)
! HR Organization
! Operating Unit SGD Set of
Books

Distribution Facility ! Inventory Organization

! Business Group
E-Business Services (US)
! Legal Entity
! HR Organization

USD Set of
Books
West Operations ! Operating Unit

East Operations ! Operating Unit

Release 11i Multi-Org Today Page 17

Given this organizational model, E-Business Enterprises can benefit in numerous
ways from Multi-Org architecture and a global, consolidated database.
• Employee data. For each autonomous business entity of E-Business
Enterprises, there exists a Business Group to represent its pool of employee
data. Employee compensation, withholding and government reporting for
each country are managed within the confines of the Legal Entity/HR
Organization combination under the Business Group of each country and
subsidiary. Separate Business Groups allow each autonomous business to
comply with local regulatory requirements for management of human
resources and compensation. Therefore, the UK parent, E-Business
Enterprises, and its Singapore subsidiary each have a Business Group to
represent their own pools of employee data and model these business
entities as employers in their respective countries. Similarly, a Business
Group exists for each of the U.S. subsidiaries, E-Business Operations and
E-Business Services to represent their own pools of employee data. Cross-
Business Group Responsibility security can also be set up so that users can
access employee data in different Business Groups across the global
enterprise.
• Local accounting practices. Each of the three Legal Entities under E-
Business Enterprises has its own Set of Books with a unique functional
currency, accounting calendar and chart of accounts structure. This permits
autonomous control over the accounting structure while still allowing
common segment values for the global enterprise to be shared across Sets
of Books. For example, E-Business Operations, E-Business Distribution,
and E-Business Services can all share the account segment values in the
chart of accounts structure even though the total number of segments in
each chart of accounts may differ.
• Local business rules. Each organization classified as an Operating Unit
can set up Oracle Payables, Oracle Receivables, or any other Oracle product
that supports Multi-Org, to best suit the way that Operating Unit does
business. System options for each application allow you to define
application behavior specific to an Operating Unit. This flexibility allows E-
Business Operations to implement business rules unique to that Operating
Unit, such as the discount basis on Receivables invoices. Similarly, E-
Business Services has the flexibility to decide whether to accrue interest on
invoices presented to its customers.
• Consolidated reporting of accounting data. Standard General Ledger
functionality supports consolidation of financial information from all
subsidiary Sets of Books into a consolidated Set of Books for E-Business
Enterprises. For example, E-Business Operations can seamlessly translate
and consolidate its USD Set of Books into a consolidated Set of Books
denominated in GBP for the UK parent, E-Business Enterprises.

Release 11i Multi-Org Today Page 18

 • Security by operating unit. Financial transaction data specific to any of
the four named Operating Units is completely secure within the confines of
the Operating Unit. Accounts Payable transactions originating in E-
Business Operations, E-Business Distribution and E-Business Services are
visible only to application users that have been granted access to the
respective Operating Units.
• Global vs. Operating Unit specific trading partner data. Various
attributes of trading partners are shared across Operating Units while other
data is specific to an individual Operating Unit. For example, the highest
level attribute of a trading partner, such as the customer or supplier name is
shared across E-Business Operations, E-Business Distribution, and the two
Operating Units under E-Business Services. However, other attributes of
the trading partner relationship such as supplier payment terms or customer
bill-to site information is specific to each Operating Unit.
• Intercompany sales across Sets of Books. Standard functionality allows
sales orders to be entered in one Operating Unit pointing to a given Set of
Books and to be fulfilled from another Operating Unit/Inventory
Organization combination in a different Set of Books. In this instance, E-
Business Distribution can accept sales orders, and if necessary, fulfill them
from one of the inventory organizations attached to E-Business Operations.
The Payables and Receivables applications can then assist in the creation of
the appropriate intercompany transactions in each Set of Books to reflect
this activity.
• Cross-Organization Reporting. Various cross-organization reports can
provide managers a view of business activity at the Set of Books, Legal
Entity or individual Operating Unit level. For example, the Receivables
“Customer Credit Snapshot” can support management of the customer
credit relationship at the Legal Entity or Operating Unit level for E-
Business Services. Also, enterprise tax reports such as the “Sales Tax”
report can be run at the Set of Books, Legal Entity or Operating Unit level
for E-Business Services to meet internal and external tax reporting needs.

FREQUENTLY ASKED QUESTIONS

What are the differences between multiple databases, multiple

instances and multiple installs?
Multiple databases and multiple instances refer to an applications enterprise
scenario in which there are multiple installations and implementations of the Oracle
Applications running in production. There are multiple applications databases,
each with its applications implementation.
Multiple databases and multiple instances are synonymous in an applications
context. The database meaning of instance differs from the applications definition

Release 11i Multi-Org Today Page 19

in which it refers to a separate SGA (System Global Area) accessing a common
database within an Oracle Parallel Server environment.
Multiple installs refer to the Multiple Sets of Books Architecture. Prior to release
10.7 of Oracle Applications, data partitioning was achieved by physically installing
applications multiple times, once for each Set of Books, each organized into
product groups in a given database. With the MSOBA architecture, users accessed
each product group and the data partitioned therein with a unique application
Responsibility.

Is there a utility to consolidate applications from multiple instances

into one instance?
Yes. Oracle Consulting has a consulting offering available to consolidate multiple
instances into a single instance. The offering is known as Oracle iMerge.

Is the Multiple Sets of Books Architecture (MSOBA) supported in 11i?

No. Customers should migrate to Multi-Org before upgrading to Release 11i.
AutoUpgrade will detect a Multiple Sets of Books Architecture implementation and
not attempt to upgrade it.

Do I have to move to Multi-Org if consolidating multiple instances?

Yes. In order to consolidate instances you will need to utilize the Multi-Org
functionality.
For more information on this topic, see the following white papers in the “Release
11i Upgrade“ section under the “Technology” tab on Oracle AppsNet @
www.oracle.com/appsnet.
• “Strategic Approaches for Consolidating Multiple Oracle Applications
Instances”
• “Strategic Planning for an Oracle Applications Instance Consolidation
Project”
• “The Advantages of Moving to Multi-Org”

Must I implement Multi-Org before, during or after the R11i upgrade?

No. You do not have to implement Multi-Org in Release 11i unless you have
implemented Oracle Applications using the Multiple Set of Books Architecture
solution (MSOBA). However, you should consider enabling Multi-Org as it
supports functionality that is useful to the global enterprise. There are numerous
features in Release 11i that support international operations and also depend on the
Multi Org architecture.

Release 11i Multi-Org Today Page 20

How does Multi-Org affect setup data?
You can share much setup data across Operating Units for applications such as
Payables, Purchasing and Receivables. However, this setup data will exist within
the confines of a single Set of Books.

How is customer and vendor information shared across Operating

Units?
Customer and vendor header information such as name and number attributes is
shared across all Operating Units. Operating Unit partitions vendor site-specific
information including vendor addresses. Recent enhancements to the customer
model in the Oracle E-Business Suite permit sharing of customer site level
information, such as addresses across Operating Units. However, other customer
site-specific information remains secured by Operating Unit.

How is the period close procedure affected by Multi-Org?

You control the accounting period status at the Set of Books level. When you close
the accounting period for a Set of Books, the accounting period is also closed for
all the Operating Units using subledger applications associated with that Set of
Books.

How does data security in CRM relate to 11i Multi-Org in the financial
applications?
In the CRM family of products there exist “OU aware” (Operating Unit Aware)
and “OU partitioned” (Operating Unit Partitioned) applications.
OU aware applications use an Operating Unit when interfacing with OU
partitioned financial applications. This includes sending transactions to a financial
application or referencing data in any OU partitioned financial application. After
the Operating Unit has been derived in the OU aware application, it follows the
transaction through its life cycle.
In the several OU partitioned CRM applications of the Oracle E-Business Suite,
users define most setup data, create and process transactions only for the Operating
Unit associated with their application Responsibility.

Release 11i Multi-Org Today Page 21

Release 11i Multi-Org Today
December 2001
Author: Shared Services and Multi-Org Architecture, Oracle Applications Development
Contributing Authors: Sally Screven, Russell Pike, Kevin Glynn

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.

Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com

Oracle is a registered trademark of Oracle Corporation. Various

product and service names referenced herein may be trademarks
of Oracle Corporation. All other product and service names
mentioned may be trademarks of their respective owners.

Copyright © 2001 Oracle Corporation

All rights reserved.