Documente Academic
Documente Profesional
Documente Cultură
Revised 09/23/15
Application:
General Ledger
Setup:
Multi-Org Setup
Objectives:
1. To Setup Multi-Org
Prerequisites:
Overview.2
Multi-Org Planning...3
Multi-Org Setup6
Effects of Multi-Org....13
Multi-Org Lessons Learned....14
Summary.......14
Appendices A and B.15
Page 1 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
Overview
It is an important lesson before beginning any efforts on a Multi-Org solution to understand basic
terminology. As you learn it becomes quite helpful to familiarize ones self with the basic terms below
and accept them as defined. Accepting and learning this terminology will make the rest of this training
paper easier to understand. This in turn will make it easier to communicate with other experienced
Multi-Org implementers and more importantly with the client.
Let us first look at the key elements:
Set of Books: This is the highest level at which the financial entities are segregated. Any entity with a
particular Chart of Accounts structure, functional currency or calendar must be a separate Set of
Books.
Organization: Any entity you define using the Define Organizations form is called an Organization.
Organizations are then assigned Classifications. The Classification(s) an Organization is assigned
determines its type and use. Business Group, Legal Entity, Operating Unit, Inventory
Organization, and HR Organization are all Organization Classifications. An Organization may be
assigned more than one Classification e.g. the Organisation Vision Operations may be assigned the
Classifications of Legal Entity, Operating Unit, HR Organization and Inventory Organization
Business Group: Represents the highest level in the structure. This may be the consolidated enterprise
or a major division of a company. Currently, Business Group has no other purpose but to segregate
HR information. If you request a list of employees (in any module) you will only see those employees in
the Business Group of which your Operating Unit is a part. Multiple Legal Entities can relate to a
single Business Group.
Legal Entity: Represents a legal company for which you prepare fiscal or tax reports. A Legal Entity
relates to a single Set of Books. Currently Legal Entity has very limited use outside of Intrastate
movement reporting.
Operating Unit: Any autonomous organization, which uses the following applications:Oracle:
Cash Management
Payables
Purchasing
Receivables
Release Management
Sales and Marketing
European Localizations
An Operating Unit is associated with a single Legal Entity. the database tables in the above
products are secured by Operating Unit (e.g. customer and supplier names are shared across OUs, with
Copyright 2000 KPMG Consulting, LLC
All Rights Reserved
Page 2 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
Multi-Org Planning
In preparing a client site for a multi-org implementation, it is suggested that you combine the planning
of this part of the overall Oracle applications implementation with the Chart of Accounts Design
Workshop.
The most critical step in implementing an Oracle Multi-Org solution on any platform is careful and
adequate planning around Multi-Org details. To develop your Multi-Org model, it is often easiest to
start to think first of the Org in these three layers:
Set of Books,
Legal Entity,
Operating Unit
Page 3 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
Adopting a simplified structure of few dimensions makes it easier to work with other consultants and
clients unfamiliar with Oracle Applications and the Oracle Multi-Org functionality.
It is often easier to start in a matrix and identify these three elements first. Please note there are five
layers to a Multi-Org model and they are as follows:
Business Group,
Set of Books,
Legal Entity,
Operating Unit
Inventory Unit.
We will now look in detail at the approach to be used to develop the Multi-Org support materials; this
approach will enable you to combine the use of KPMGs R2i Rapid Return on Investment approach and
successfully implement Oracle Applications, using Multi-Org. A sample of the matrix used to
supplement the organizational model is included as Appendix A.
Step 1: Develop your Multi-Org Organizational model. Essentially this represents the clients MultiOrg organization chart. The more time that is spent developing this model before starting the actual setup, the more this will increase your chances for a successful Multi-Org validation report and accurate
view of the client organization.
Step 2: Identify in a listing format all of the Legal Entities and their names, as a pre-data listing.
Step 3: Identify all of the proposed Organizations or Operating Units. This is used as a check to ensure
that we include all Operating Units. Note: It is not uncommon to have requirements for more
operating units in applications such as Receivables than in Payables. Often, we find that because
AR represents the revenue business stream and drives the business, a need to track separate Receivables
is common. This is often supported by the best practice notion of shared service centres or centralized
Payables functions. Be aware, however, that applications that centralize functions by defining an OU
automatically determines the mode of operation of other applications using OU. For instance, you
cannot easily implement decentralized Purchasing with centralized Payables. Neither can you say that
your client will centralize Cash Disbursement but decentralize vouchering.
Step 4: Put all of the above gathered information together in one matrix. Essentially, the matrix is
formed of the following columns:
1.Organization Name, 2.Is it a Legal Entity? 3. Is it an Operating Unit? 4. Is it an Inventory
Unit? 5. Set of Books, 6.Legal Entity Name, 7.Applications.
The first column is the Organization Name. The second column identifies whether this organization is a
legal entity or not. The third column identifies whether or not this organization is an Operating Unit.
The fourth column is to identify whether or not the organization is an Inventory Unit. The fifth column
identifies which set of books the organization belongs. The sixth column identifies the legal entity name
Copyright 2000 KPMG Consulting, LLC
All Rights Reserved
Page 4 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
that the organization belongs. The last column identifies which applications need to support the
organization (this helps to identify which organizations do not require subledger functionality such as a
holding corporation).
Step 5: Using the details from your matrix put them in to a graphical organizational format. Draft the
organizational chart as follows:
First, list your Sets of Books across the top, treating them as an equal top tier of your organization.
Next using your matrix create a Legal entity layer on your organization chart for all legal entities,
properly aligning the legal entities with their respective Set of Books.
Next add the Operating Unit layer, for any organization you identified as an Operating Unit you need to
add a box to represent them graphically aligned under their respective legal entity. Note it is possible to
have more than one Operating Unit associated with one legal entity (it can be a many to one). Appendix
A contains an example of the graphical layout.
It is very critical at this point to review both your matrix and graphical representation ensuring that you
have all organizations from your matrix represented. Next, review with the client both for accuracy and
for completeness. Often-new operating units are identified after first discussion. Some tips to help you
ensure you have all the components are as follows:
1. Does every Set of Books (SOB) have at least one Legal entity? (If not you may want to find out
what the SOB represents)
2. Do you have at least one Operating Unit listed for any legal entity which resides in a different set of
books which you identified the need to use a subledger application such as AP, AR, OE, PO, or INV?
Note: you can have one Operating Unit support many legal entities within the same set of
books, granted you do not have a requirement for data separation (such as security at a
supplier site level by entity).
3. Ask yourself and then ask the client, do we need to issue statements, invoices, and track Receivables
for multiple companies tracking them at the individual company level and have separate reporting? If
so, verify that you have an operating unit for each of these.
Once you have verified all of the information gathered to date, add the remaining 2 layers to the
organizational chart the Business Group and Inventory Org layers. Unless you have a defined
requirement for more than one HR Business Group, then you can list the HR Business Group at the top
of the organizational model with all Sets of Books reporting to the HR Business Group. Lastly, add
your inventory Orgs to the model identifying them with the appropriate Operating Unit. Even if you
are not using inventory, you will still need to identify at least one inventory org for each
operating unit. If you are implementing Inventory, ensure that you validate and create all
necessary inventory Orgs that you need to meet your requirements.
Before, moving into set-up, another area that is worthwhile to pre-plan is identifying the responsibilities
you need to access each subledger-operating unit. As a minimum, you need to identify a super-user or
manager responsibility for each operating unit for each subledger to perform set-up activities required
Copyright 2000 KPMG Consulting, LLC
All Rights Reserved
Page 5 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
at the operating unit-subledger level. This will help ease the facilitation and management of ensuring all
of the necessary profile options are updated for each responsibility for each operating unit. The correct
setting of all necessary profile options could avoid significant administrative problems for the project
team.
A tip that could prove helpful to managing this effort is to create a Responsibility / Profile Matrix. The
matrix should list the necessary profile options settings necessary for each responsibility. This matrix
can then be used as a document for checking progress against each specific option for each
responsibility as it was completed. For example in a recent project in the U.S, there were five operating
units for Receivables and five custom responsibilities for Receivables. This resulted in 25
responsibilities just for Receivables, with at least nine profile options for each responsibility, which need
to be verified or updated. In this example, it would have been risky to manage this volume without a
structured approach. A sample of the matrix is included as Appendix B.
Multi-Org Set-up
As with any traditional implementation plan, after understanding the basics, careful planning and analysis you are ready
to begin set-up. The set-up tasks specific to Multi-Org need to occur before initiating the set-up for any of the subledger
modules (such as AR, AP, OE, PO, INV, etc.). This occurs first because there is a utility that your DBA initiates for MultiOrg, which essentially partitions the database for the operating units. Once this activity has taken place there are several
set-up steps within each module, which is affected by Multi-Org in one capacity or another. The effects of Multi-Org will
be discussed in the next section.
A list of the Multi-Org set-up steps and order are listed below. Refer to the R2i Multi-Org Configuration Guide. A brief
description of each step is located in the Oracle Multiple Organization Reference Manual - the part number is listed
following this section. There are 21 potential Multi-Org set-up steps identified as the following:
Page 6 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
Page 7 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
(MO 4) Create an Inventory Responsibility and assign the Set of Books and Business Group. This
is a System Administrator exercise.
(MO 5) Log on to the Responsibility defined in MO 4 with the assigned Business Group and Setup
of Books.
Do not define any new organizations or organization hierarchies until you have associated
each business group with a responsibility.
(MO 6) Define Locations for the Legal Entity, Operating Unit and Inventory Organization.
Page 8 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
Create the Legal Entities for the Business Group. The Legal Entity will be tied to a Set of Books
defined in General Ledger.
Page 9 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
Page 10 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
In sysadmin use the define responsibility window to define the responsibilities for each subledger
application associated with each operating unit. When a user signs onto Oracle Applications, the
responsibility the user chooses determines the data, windows, menus reports and concurrent
programs that user is authorised to access.
Page 11 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
Some profile options such as AR: Receipt Batch Source and AR: Transaction are secured by
operating unit, and when they are set, they have to be set for each operating unit at the responsibility
level.
Page 12 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
The reporting level a user can choose is restricted by the reporting option MO: Top Reporting
Level. The three choices available for this profile are: Set of Books Level, Legal Entity Level, and
Operating Unit Level.
Page 13 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
Effects of Multi-Org
As you continue through the implementation or upgrade to the multi-org process, it is important to keep
in mind and understand the effects of Multi-Org. This section will describe some of the aspects, which
are important to understand during this process. Some of these elements may affect how you define
your operating units or how many of them you define; others can be classified as informational to
understand what it means to your data and/or functional groups. This section is not going to represent
all of the potential effects, but will highlight some of the ones which we have learned through our US
implementation experience.
The introduction of Multi-Org into an implementation model introduces the concept of shared
elements and non-shared elements. Shared elements can be defined as items which are either shared
across operating units within a Set of Books or shared across operating units, and Sets of Books, within
a database instance. It is important to realize that later means that some set-up components are shared
across Sets of Books being available to all operating units defined in a particular database instance.
Non-Shared elements can be define as set-up components which are not shared across the operating
units, which means for each operating unit established you would need to perform this set-up step.
Some examples of each category are located below:
Examples of:
Set-up Components which are shared across Operating Units within a Set of Books:
AR Periods, Open/Close AR Periods.
Set-up Components, which are shared across Operating Units and Sets of Books, within a database,
instance:
Flexfield Definitions, Customer Headers, Supplier/Vendor Headers, Customer Profiles, Locations, Bank
Headers.
Non-Shared Components:
AR Transaction Types, AR/AP Bank Account Details, Customer Sites, Supplier/Vendor Sites.
Some of the traditional time estimates for entering set-up may need to be increased to accommodate for
the increased effort to set-up all the non-shared steps for each operating unit. Every implementation has
variables and conditions that make it unique in its own sense. However, what we found is that after
having done this a number of times, that we used an estimate of an additional day effort for each
operating unit. For example if we had 5 operating units for AR, if we were keying a full set-up, we
added an additional 2 days to our traditional time estimate for performing activities for the AR
module. Note that our estimate assumes the use of resources experienced in performing set-up.
Page 14 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
Page 15 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
APPENDIX A
Multi-Org Set-up Chart Details
Set of Books
Set of Books Name
Functional
Currency
Calendar
Page 16 of 18
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
Organizations
Organization Name
Page 17 of 18
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
Is it a Legal
Entity?
Is it an
Operatin
g Unit?
Is it an
Invento
ry Unit?
Set of Books
Legal Entity
Operating.
Unit
Application
s.
Page 18 of 18
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
APPENDIX B
Responsibility Profile Options
Module
Responsibi HR:
Business
lity
Group
EX:
AR
OE:Set of Sequentia
GL:Set of AR:Recei OE:
Books
pt Batch Transacti Books
l
Source
o Batch
Numberin
Source
g
INV:Inter
compan
y
Currenc
y
Conversi
on
AR Collector
Page 19 of 18
/var/www/apps/conversion/tmp/scratch_2/287507009.doc
Page 20 of 18
/var/www/apps/conversion/tmp/scratch_2/287507009.doc