Oracle Applications R12 Legal Entities and Multi-Orgs (MOAC) Details

What Is Multi-Org?

Multi-Org is a server-side (applications and database) enhancement that enables multiple business units in an enterprise to use a single installation of Oracle Applications products while keeping transaction data separate and secure. The Multi-Org enhancement uses native database views to build a security layer on top of a single installation of Oracle Applications. In Oracle Applications Release R12, the following products support Multi-Org capabilities:

•      Cash Management

•      Order Management, Shipping Execution and Release Management

•      Payables

•      Property Manager

•      Projects

•      Purchasing

•      Receivables

•      Incentive Compensation

•      Sales and Marketing

•      Service

Basic Business Needs

The Multi-Org enhancement to Oracle Applications provides features necessary to satisfy the following basic business needs. You should be able to:

•      Use a single installation of any Oracle Applications product to support any number of business units, even if those business units use different ledgers

•      Support any number of business units within a single installation of Oracle Applications

•      Secure access to data whereby user access is limited to information relevant to the user’s organization

•      Procure products from an operating unit that uses one ledger, but receive them in another operating unit using a different ledger.

•      Sell products from an operating unit using one ledger, but ship them from another operating unit using a different ledger, automatically recording the appropriate intercompany sales by posting intercompany accounts payable and accounts receivable invoices.

•      Report at any level of the organization structure

Types of Organizations Supported in the Multi-Org Model

The Multi-Org model provides a hierarchy that dictates how transactions flow through different business units and how those business units interact. You define the organizations and the relationships between them. In the diagram in the slide, note the different shapes used for each organization type. The shapes are helpful when drawing multiple organization diagrams.

Business Group

The Business Group partitions Human Resources information and the Purchasing Approval Hierarchy. A Business Group could be set up to model a consolidated enterprise, a major division, or an operating company—without any accounting impact. Multiple Legal Entities can relate to a single Business Group.

You must have at least one Business Group. For a new installation, Oracle Applications provides a default business group, Setup Business Group. You can define additional business groups as required for your enterprise.

Ledger

A Ledger is a financial reporting entity, which implements the four “C”s and is a single repository of financial truth.

*      Chart of Accounts (COA: Accounting Flexfield Structure)

*      Functional Currency

*      Financial Accounting Calendar

*      Accounting Conventions

Here is an example of a Ledger implementing four “C”s: The balance on creditors (COA) is 4.2 million euros (Currency) on March 31, 2007 (Calendar), according to IAS/IFRS definition (Accounting Convention).

The Ledger concept is similar in a Multi-Org environment. General Ledger secures transaction information (journal entries, balances) by Ledger. When you use General Ledger, you select a responsibility that specifies a particular Ledger with information relevant to only that Ledger.

Legal Entity

A Legal entity represents a legal company for which you prepare fiscal or tax reports. You assign tax identifiers and other Legal entity information to these types of organizations. A Legal entity is identified through the registration with Legal Authority.

Types of Legal Entities

GRE/Legal entity: Use this classification to represent the following organizations.

*      Ultimate Legal entity (New in R12): Represents the enterprise and typically the highest (global) level of a business organization

*      Legal entity: Represents the designated legal employer, recognized by the legal authorities in a country as a separate employer. In an organization hierarchy, a Legal entity may report to an operating company or to the ultimate Legal entity.

*      Consolidated Legal entity (New in R12): Acts on behalf of multiple operating companies, which are either not legally registered or simply on the behalf of the enterprise in a country

Operating Unit

An organization qualified as an operating unit can be used to model an autonomous business unit in an organization that has a business need to secure transaction data, set up and seed data. An Operating Unit can be set up to support different business policies and workflow processes. Generally, an Operating Unit could be a major division or separate company within the enterprise. Each user sees the information associated with the operating units to which they have access. An Operating Unit is linked to a Responsibility using the MO: Operating Unit profile option.

Balancing Entity

This is an entity for which you prepare a balance sheet, represented as a balancing segment value in the Accounting Flexfield structure. There can be multiple balancing entities within the same operating unit structure and each of these must balance within itself. All required intercompany entries will be automatically created within the Ledger to ensure that companies are never out of balance. A balancing segment could be a company or a division, for example.

It is important to keep in mind that a Government Reporting Entity (GRE) or Legal entity may comprise of one or more than one balancing segments. For example, you may have multiple companies defined in your chart of accounts that roll up to a single Legal entity for reporting purposes. Alternatively, each company you define in your chart of accounts may have multiple divisions for which you produce balance sheets. In that case, each company in the chart of accounts will most likely be set up as a Legal entity and each division will most likely be set up as an operating unit. Oracle does not automatically secure balancing segment values within your chart of accounts with specific legal entities or operating units. You can create security rules to do this. For example, you may want the Payables team to only be able to enter invoices for a specific division associated with a particular operating unit. If security rules are not defined, they will be able to access all divisions regardless of the operating unit associated with their responsibility. The solution is to create a security rule that allows access to only the divisions that roll up into their operating unit.

While a balancing segment most often is associated with a single operating unit, it is not always the case. For each of the three examples, assume there is one General Ledger, the balancing segment value is the company segment, and there are three companies defined (10, 20, and 30). Also, keep in mind that operating units are associated with responsibilities. That is, each responsibility is associated with one operating unit.

Example 1: Company is a Legal entity. Balancing segment value (company 10) is a Legal entity in and of itself. Two divisions have been defined as operating units and roll up to it. A flexfield security rule that allows access to company 10 has been created and associated with the responsibility that points to the Div1 and Div2 operating units. When users log in with either responsibility, they will only be able to enter transactions associated with company 10 (and not 20 and 30).

Example 2: Company is an operating unit. Balancing segments 10 and 20 are operating units in and of themselves. Both roll up to the same Legal entity. Two different security rules will be defined. All responsibilities associated with the C1 operating unit will have a security rule that allows them to enter transactions associated with company 10. All responsibilities associated with the C2 operating unit will have a different security rule that allows them to enter transactions associated with company 20.

Example 3: Company is part of a line of business. Balancing segment 10 is associated with one line of business and balancing segments 20 and 30 are associated with a separate line of business. As in the earlier examples, security rules will be created to allow appropriate access to data.

Inventory Organization

An inventory organization represents an organization for which you track inventory transactions and balances. Examples include manufacturing plants, warehouses, distribution centers, and sales offices. The following products and functions secure information by inventory organization: Inventory, Bills of Material, Engineering, Work in Process, Master Scheduling/MRP, Capacity, and purchasing/receiving functions. To run any of these products or functions, you must select an organization classified as an inventory organization.

With the Multi-Org enhancement, multiple Ledgers can use the same “global” item master organization, since the item master organization is used for item definition and not item accounting information. All accounting related attributes in the Item Master are controlled at the item or organization level.

Sample Organization Structure

With Oracle Applications accounting, distribution, and materials management functions, you define the relationships between inventory organizations, operating units, legal entities, and Ledger to create a multilevel company structure.

Legal Entities (LE) Post to a Ledger

Each organization classified as a Legal entity must specify a Ledger to post accounting transactions. A Legal entity can point to only one Ledger.

Operating Units (OU) Are Part of a Legal Entity

Each organization that you classify as an Operating Unit must reference a Legal entity. An Operating Unit can point to only one Legal entity.

Inventory Organizations (IO) Are Part of an Operating Unit

Each organization classified as an Inventory Organization must reference an operating unit. An Inventory Organization points to only one Operating Unit, but through standard functionality can be referenced by any Operating Unit having the same Ledger as the attached Operating Unit. Items are defined in the master inventory organization (master parts list) and added to the appropriate child inventory organizations. Any inventory transactions are secured by the Inventory Organization.

Define the Organization Structure

Plan and define the entities in your organization structure.

A successful implementation of Multiple Organization Support in Oracle Applications primarily depends on correctly defining your organization structure in the hierarchy used by Oracle Applications. A careful analysis and design of a company’s organization structure is critical for future success. The following points describe how the Multi-Org model relates organizations:

*             A Business Group is the highest level of the structure and does not have an accounting impact. The Business Group determines which employees will be available to Ledgers and Operating Units related to that Business Group.

*      A Ledger is the highest level that impacts accounting.

*      Ledger is associated with a single Business Group. Multiple Ledgers may be associated with a single Business Group.

*      Each Ledger may have a different chart of accounts structure, calendar, or functional currency.

*      Each GRE/Legal entity is associated with a single Ledger, multiple Legal Entities may be associated with a single Ledger.

*      Each Operating Unit is associated with a single GRE/Legal entity, multiple Operating Units may be associated with a single Legal entity.

*      An Inventory Organization may be associated with any Operating Unit within the same Ledger.

Adding to the Organization Structure

The Multi-Org enhancement allows you to add organizations at any time. Enterprises with substantial acquisition and divestiture activities, as well as businesses prone to reorganizations, are able to define new business units and disable old business units as required.

One approach for organizations that restructure frequently is to define new business organizations as required, while leaving the old organizations untouched. With this approach, it is easy to keep day-to-day business transactions recorded.

To add additional operating units:

*      Create the operating unit

*      Run the Replicate Seed Data concurrent request

*      Create new responsibilities as necessary and set the MO: Operating Unit profile option

How Multi-Org Secures Data

Security Model

As shown in the slide, users have responsibilities linked to operating units via a profile option.

The responsibility is key to multi-org security and reporting. It determines:

•      Operating unit

•      Reporting ability

Data Security by Application

Data is partitioned (secured) in Oracle Applications in many different ways:

*      General Ledger and Fixed Assets are partitioned by GL Ledger. In addition, hierarchies of asset books may also be set up within assets that can effectively secure assets by asset book.

*      Human Resources is partitioned by Business Group.

*      Order Management, Accounts Receivable, Accounts Payable, Purchasing, Cash Management, Projects, Service, Incentive Compensation, Sales and Marketing are partitioned by Operating Unit.

*      Manufacturing applications are partitioned by Inventory Organization.

Global Registries

For the global registries of both customers and suppliers, header level information is stored in an unpartitioned table for all entities within an instance. This allows for custom reports to consolidate information at either the Ledger or GRE/Legal entity levels.

Taxpayer ID, Federal and State reportable options are still at the customer or supplier level. In the above example, the supplier, ABC Corporation, is shared across the two Operating Units. Each Operating Unit has its own groupings of address information. If two Operating Units share the same address for a supplier, they must currently enter the information separately.

Organization Reporting Options: Ledger

If the MO: Top Reporting Level profile option is set to Ledger, you can run your reports at Ledger level, Legal entity level, or operating unit level. Because the MO: Top Reporting Level is set to Ledger for the OU1 responsibility, users will be only able to select a reporting level of Ledger, GRE/Legal entity, or Operating Unit. In this example, the user will be able to see a consolidated subledger report of all operating unit activities that roll up to Ledger 1.

•                            MO: Top Reporting Level is set to GRE/Ledger.

•                            Reporting Level parameter is set to Ledger.

•                            Reporting Context parameter is set to Ledger 1.

Organization Reporting Options: Legal Entity

If the MO: Top Reporting Level profile option is set to GRE/Legal entity, you can run your reports at the GRE/Legal entity level or operating unit level. Because the MO: Top Reporting Level is set to GRE/Legal entity for the OU2 responsibility, users will be only able to select a reporting level of GRE/Legal entity or Operating Unit. In this example, the user will be able to see a consolidated subledger report of all operating unit activities that roll up to LE2.

•                            MO: Top Reporting Level is set to GRE/Legal entity.

•                            Reporting Level parameter is set to GRE/Legal entity.

•                            Reporting Context parameter is set to LE2.

Organization Reporting Options: Operating Unit

If the MO: Top Reporting Level profile option is set to Operating Unit, you can run your reports at the operating unit level only. You are only allowed to view data in the operating unit assigned to your responsibility. In this example, the user will be able to see a consolidated subledger report of all operating unit activities for OU3.

•      MO: Top Reporting Level is set to Operating Unit.

•      Reporting Level parameter is set to Operating Unit.

•      Reporting Context parameter is set to OU3.

Organization Naming Considerations

Multi-Org naming conventions should be used to identify the Oracle organizations classification (for example, Ledger, Operating Unit, Inventory Organization) and its unique characteristics like country or currency, location name, and usage.

The following are general guidelines for creating organization names:

Ledgers, where:

*      Ledger_: An operational book that obtains journal entries directly from a subledger system (for example, accounts payable, inventory)

*      COB_: A consolidation Ledger

*      ROB_: A reporting Ledger when using the Multiple Reporting Currencies (MRC) feature

*      BG_ : A Business Group

*      HR_ : A Human Resources Organization

*      LE_ : A GRE/Legal entity

*      OU_ : An Operating Unit

Inventory Organizations, where:

*      IO_: An Inventory Organization intended to be a subledger in Oracle Applications or a planning entity. This organization will contain either inventory transactions or Master Demand Schedule entries, or both.

*      GM_ : The Global Item Master. If more are than one Item Master is used (which is not advised) then follow with a currency designation (for example, USD).

*      VO_: An Inventory Organization used only for validation purposes (for example, for maintaining value-added tax rates by item) and is not an Inventory subledger. It will never contain inventory transactions.

*      PO_: Used for planning purposes only with no transactions. For example, a Distribution Requirement Planning (DRP) schedule, with planning processes, and related setups for particular product lines crossing many plants and distribution centers, could be established and controlled from this Organization.

Country Codes, Locations, Business Names, Functions and (corporate) Proper Names are used in the Organization naming conventions to distinguish the actual site location and country ownership. For example:

*      Country Codes: Are abbreviations used to identify the Organization’s country of registration and residence. They usually have three characters followed by a sequentially numbered digit for the country. For example: USA1, USA2.

*      Locations: Are the City and State or Province address of the Organization. They are delineated by an “_” between the City and State and sometimes abbreviated to fit into the 30-character suggested Name length, for example, DALLAS_TX.

*      Example: Ledger_USA1_ABC; OU_USA1_MILWAUKEE_ABCCORP

Define Multi-Org Access Control (MOAC)

User access to multiple operating units is called Multi-Org Access Control. The primary topics of discussion for MOAC are:

•      New and changed features that support various functionalities

•      Benefits

•      Setup and process

•      Dependencies and interactions

User access to multiple operating units is called Multi-Org Access Control (MOAC). Multi-Org Access Control allows companies that operate shared service centers or those that have centralized their accounting and administration functions to process business transactions more efficiently. For example, say you operate in multiple countries and your headquarters provides some or all accounting services to the other subsidiaries. You may not have implemented a formal shared service center, but you can still reap the benefits from Multi-Org Access Control. MOAC allows companies to gain processing efficiencies because users can more easily access, process, and report on data across multiple operating units from a single responsibility without compromising data security or system performance.

New and Changed Features of MOAC

MOAC is basically the ability to access multiple operating units from a single application responsibility. Multi-Org preferences allows the user to control and limit the number of operating units they have access to based on their work environment. Cross organization reporting has been enhanced to be more in-line with the new MOAC. Users can run reports enabled for cross organization reporting, via their security profile, to summarize data for all operating units rolling up to a specific GRE/Legal entity or ledger.

Access One or More Operating Units Using Single Responsibility

You can assign operating units to a security profile and then assign the security profile to responsibilities or users. If multiple operating units are assigned to the security profile, then a user can access data for multiple operating units from a single responsibility.

Enhanced Reporting Capability Using:

*      Reporting level parameter: Allows users to choose the level at which they want to report the valid options, which are Ledger, GRE/Legal entity and Operating Unit. If the user selects Ledger as the reporting level, then the report displays data for the operating units assigned to the ledger accessible by the user. If the user chooses Operating Unit, selectable operating units depend on the operating units assigned to the MO: Operating Unit or the MO: Security Profile profile option. If the MO: Security Profile profile option is set, the MO: Operating Unit profile option is ignored.

*      Reporting context: Allows users to select an entity within the selected reporting level. Valid options are ledger names, or operating unit names, depending on the reporting level value.

Benefits of MOAC

In Oracle Applications 11i, if you had three operating units in the shared services center you were managing, such as a Mexico Operating Unit, a Canada Operating Unit, and a United States operating unit, you needed to define three different responsibilities. If a user processes Payables Invoices across all three operating units, he/she would have three separate responsibilities, one for each operating unit. In order to process invoices for the various operating units, your user would have to switch responsibilities any time he/she wished to process an invoice for another operating unit, thus decreasing their efficiency.

Using MOAC, a user can perform tasks for multiple operating units (OU) without changing their responsibilities.

Tasks users can perform using MOAC in multiple OUs:

•      Enter Payables Invoices

•      View Consolidated Requisitions

•      Perform Collections

•      Process Receiving and Drop Shipments

•      Customer Data Management Accounting Setup

In Oracle Applications Release 12, you can create a security profile and assign multiple operating units to the profile. In the example mentioned here, assign all three operating units to a security profile and associate the security profile to a responsibility using the MO: Security Profile option. For example, you could assign the security profile to the USA Payables responsibility to allow that responsibility to process invoices across all three operating units.

Processing Payables Invoices is just one example. With Multi-Org Access Control, you can efficiently perform other processes, such as processing receivables invoices, viewing Consolidated Requisitions, performing Collections using Advanced Collections, and process Receiving and Drop Shipments.

A single application responsibility can now access multiple operating units. Companies that have implemented a Shared Services operating model can:

*      Increase operational efficiency and effectiveness

*      Process data across multiple OUs from a single responsibility

*      Process transactions more efficiently for companies that have centralized business functions or operate Shared Service Centers

*      Obtain better information for decision-making

*      Obtain a global consolidated view of information

*      View information, such as supplier sites and customer sites across multiple OUs

*      Reduce costs

*      Speed up data entry

*      Reduce setup and maintenance of many responsibilities

In Oracle Applications11i, an operating unit is associated with a responsibility, therefore when a user had to enter and/or process data for multiple operating units, he/she had to switch responsibilities to access the appropriate operating unit. For example, if you had a centralized payment processing center where a single user processed payment for multiple operating units, he/she would have to switch responsibilities every time he/she wanted to process payments for a different operating unit.

Now in Oracle Applications Release 12, MOAC enables companies that have implemented a Shared Services operating model to efficiently process business transactions by allowing users to access, process, and report on data for an unlimited number of operating units within a single applications responsibility. This increases the productivity of Shared Service Centers, as users no longer have to switch application responsibilities when processing transactions for multiple operating units. Data security and access privileges are still maintained using security profiles, which now support multiple operating units.

Multi-Org Access Control: Setup and Process

In Release 12, when you define your security profile in HR using the Security profile form or the Global Security profile form, assign all operating units needed for a responsibility’s access. Then, run the Run Security List Maintenance concurrent request from HR, which will make the security profile available for assignment to a responsibility via the MO: Security Profile profile option.

In terms of processing, things operate basically the same way as in 11i. Each product team has implemented MOAC to best suit their business process flows. For example, in AP, there’s a new operating unit field on their Invoice Workbench. The OU list of values will read from the Security Profile assigned to the responsibility to determine which OUs should be displayed in the LOV. In general, when a user logs in to a responsibility and opens an application, the application will determine which operating units can be accessed and used for processing. The user can then view or process transactions for multiple operating units.

Accounting Setup Manager (ASM): Centralized Setup

You create a Ledger using the Accounting Setup Manager in General Ledger. You define all other types of organizations using the Organizations window.

Define Legal Entities

This allows you to define Legal Entities and associate country-specific rules.

Assign/View Legal Entities

This allows you to assign Legal Entities defined in other applications such as HRMS, Inventory, Purchasing.

Define Ledger (Set of Books): Associate Four Cs

This allows you to define multiple Ledgers for accounting rules for E-Business Suite (EBS) applications like Accounts Payables (AP), Accounts Receivables (AR), include currencies like US dollar, pound sterling, Canadian dollar, and associate country-specific rules for USA, UK, Canada, and so on.

Define Operating Unit [(OU)

This allows you to define or assign any number of Operating Units for a specific GRE/Legal entity.

MOAC Setup: Create an Operating Unit

Navigation

*       Responsibility =  General Ledger, Vision Operations (USA)
(N) Setup > Financials > Accounting Setup Manager 

*       Responsibility =  Human Resources , Vision Enterprises
(N) Work Structures > Organization > Description 

*       

You can define your operating units in two places. You can continue to define them in the Oracle HRMS Organization Form or in the New Account Setup Manager in General Ledger. The Accounting Setup Manager streamlines the setup and implementation of Oracle Financial Applications by centralizing the setup and maintenance of common financial components, such as legal entities, operating units, and ledgers. So, here when you create an accounting setup, assign a Legal entity,

and create the ledgers that will perform the accounting for that Legal entity, you can also define and assign the relevant operating units. By leveraging Accounting Setup Manager to define your OUs, you can streamline your setup. The small change in R12 is that instead of attaching an OU to a LE, you assign it to a default legal context. If operating units are assigned to a Ledger, they will be associated to a primary ledger in an accounting setup. You will be able to view all operating units assigned to an upgraded primary ledger using Accounting Setup Manager.

Dependencies and Interactions of MOAC

As already mentioned, operating units can be defined using either the HRMS organization form or the Accounting Setup Manager.

•      Oracle HRMS:

–     Define operating units.

–     Set up Multi-Org Security Profiles.

•      Accounting Setup Manager:

–     Define operating units.

–     View all operating units assigned to the primary ledger.

•      Oracle E-Business Suite products that use Operating Units:

–     Process data across multiple operating units using Multi-Org Access Control.

Following are a few examples of how products leverage MOAC:

*      In Payables, you can enter invoices for different operating units from their Invoice Workbench. There is a new operating unit field, which is the first field to be specified when entering an invoice. It does not imply that you can enter an invoice with invoice lines that cross operating units. An invoice is still applicable for one operating unit, but you can select different operating units without having to change responsibilities.

*      In Receivables, there are some new cross organization reports. So when you run a report, it will run the report for all the operating units you have access to, based on your security profile.

*      In Purchasing, you will be able to view consolidated requisition demands that cross operating units.

*      In Collections, you can manage customers and accounts across OUs.

*      Accounting Setup Manager provides the ability to define operating units, assign them to a primary ledger, as well as create the GRE/Legal entities and operating units at the same time.