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
(N) Setup > Financials > Accounting Setup Manager
* Responsibility
= Human Resources , Vision Enterprises
(N) Work Structures > Organization > Description
(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.
2 comments:
Awesome content.
Great information, all in 1 place.
Post a Comment