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 users 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 MultiOrg 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 MultiOrg, 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. 2. 3. Legal entities. Attach the Legal Entity to a Set of Books. Operating units. Attach the Operating Unit to the correct Legal Entity and Set of Books. 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:

E-Business Enterprises (UK)

! Business Group ! Legal Entity ! HR Organization

GBP Set of Books

E-Business Operations (US)

! ! ! !

Business Group Legal Entity HR Organization Operating Unit USD Set of Books

MFG Plant 1

! Inventory Organization

MFG Plant 2

! Inventory Organization

E-Business Distribution (SG)

! ! ! !

Business Group Legal Entity HR Organization Operating Unit

SGD Set of Books

Distribution Facility

! Inventory Organization

E-Business Services (US)

! Business Group ! 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. CrossBusiness 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 EBusiness 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 EBusiness Operations to implement business rules unique to that Operating Unit, such as the discount basis on Receivables invoices. Similarly, EBusiness 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 EBusiness 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, EBusiness 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 EBusiness 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.