Multi Org Reference / Training Guide

KEYWORDS \* Upper \* MERGEFORMAT

Multi Org Setup

Revised 09/12/00

Application:

General Ledger

Setup:

Multi-Org Setup

Objectives:

1. To Setup Multi-Org

Prerequisites:1. The General Ledger setup needs to be completed through the creation of the Set of Books

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

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

Order Management and Shipping Execution

Payables

Projects

Purchasing

Property Management

Receivables

Release Management

Release Management

Sales Compensation

Sales and Marketing

Service

European Localizations

Latin America 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 sites being specific to each Inventory Organization: An Organization for which you track inventory transactions and balances. Oracle Inventory, Bills of Material, Engineering, Work in Progress, Master Scheduling / MRP, Capacity and Purchasing (receiving) secure information by Inventory Organization. Inventory Organizations may be related to any Operating Unit(s) within the same Set of Books. The relationship between Inventory Organization and Set of Books is used for financial purposes only (creating requisitions and replenishing supplies).

HR Organization: HR Organizations are only utilized by Oracle HR and Oracle Projects products and have no impact on the Financial or Manufacturing applications. This facilitates a complex organization structure for HR tracking but a more simplified structure for the operational side of the Business

Responsibility: This is a Grouping of functionality and system data often related to a job role or responsibility. Responsibilities are associated with a Set of Books, Operating Unit and Inventory Organization where appropriate through profile settings (e.g. MO: Operating Unit defines the Operating Unit for that Responsibility).

Balancing Segment: This is a segment in the Accounting Flexfield structure (usually the Company segment) at which all accounting entries must balance. There may be multiple companies within the same structure; each of these must balance within it. All required inter-company entries will automatically be created within the Set of Books to ensure companies can never be out of balance.

Security Rules: Security rules limit (by responsibility) the values of a Flexfield which the user will see. E.g., a user will only see the Department values in the Accounting Flexfield which they have authority to see.

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

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 Multi-Org organization chart. The more time that is spent developing this model before starting the actual set-up, 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 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 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-upAs 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 Multi-Org, 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:

(MO 1) Develop the Organizational Structure (see section 2)

(MO 2) Define Set of Books

Set of books will be defined in the GL set-up. Depicted is the R2i Set of Books, Refer to the GL configuration guide for more detailed information on the steps to follow in setting up your set of books. Note if your company structure requires that you define a business group, define the set of books before the business groups.

Note if you have a set of books which does not have a requirement for subledgers, the setup for these SOBs can be done after the conversion to Multi-Org. The postponement of these SOBs allows you to get through the Multi-Org specific setup steps sooner, allowing the subledger modules to begins setup sooner.

(MO 3) Define Multiple Business Groups if not using default.

Oracle Applications provides default Business Group: Setup Business Group. Create additional Business Group(s) associated with the planned Organization Structure.

If the client requires multiple Business Groups, you must define all of the Business Groups at this point.

(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.

(MO 7) Define Organizations Structure and Relationship Legal Entity

In the define organization window define organizational relationships by assigning classifications to each organization. You can classify an organization as any combination of legal entity, operating unit and inventory organization. Specifications can only be done in the following order: 1.Legal Entity, 2.Operating Units, 3. Inventory Organizations. Refer to the Oracle Multiple organizations manual for more detailed information on set up

Create the Legal Entities for the Business Group. The Legal Entity will be tied to a Set of Books defined in General Ledger.

(MO 8) Define Organizations Structure and Relationship Operating Unit

Create the operating units for each legal entity, and link each operating unit to the legal entity.

(MO 9) Define Organizations Structure and Relationship Inventory Organization

Create an inventory organization for each operating unit. The inventory organization will be tied to the set of books, legal entity, and operating unit defined in the Multi-Org Setup.

(MO 10) Define Responsibilities

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.

(MO 11) Set Business Group Profile at each Responsibility

For the profile option HR: Business Group, set the profile option for each responsibility, either to Setup Business Group, or if appropriate, a newly created Business Group.

(MO 12) Set Operating Unit Profile Options at each Responsibility

In System Administration, define the appropriate MO: Operating Unit for each responsibility.

At the site level, a default operating unit must also be set in order to be able to convert to multi-org.

For a fresh installation, the default can be any operating unit desired.

(MO 13) Conversion to Multi-Org

Conversion to multi org requires the assistance of a DBA or System Administrator. Ask the Database Administrator to run the Autoinstall facility adadmin. This function should be used for a standard installation or a multi-org installation. An option within adaadmin is to convert to multi-org architecture. In choosing this option, this will enable the multiple organization support feature and add operating unit context to existing data. This process will also copy seed data to all operating units that have been defined. If adaadmin has previously been run, use the Replicate Seed Data job in system administration to update the organization and run the multi org reports to verify the process

(MO 14) Change Order Management Parameter

The Oracle document, Multiple Organization Setup and Implementation, indicates that the OM: Item Validation profile must be set at the responsibility level. In prior releases of the Oracle applications, there was an OE: Item Validation Org that need to be set at the responsibility level.

However in release 11i, there is an Item Validation Org parameter in Inventory that must be set to the proper operating unit during Order Management Configuration.

(MO 15) Set Profile Options Specific to Operating Units

A number of profile options need to be set for each responsibility for each operating unit where applicable. These include but are not limited to GL: Set of Books, and HR: User Type. Refer to the R2i configuration guide, and the Oracle Manual Multiple Organizations in Oracle Applications for a complete list of profile options that need to be set for each responsibility.

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. (MO 16) Define Inventory Organization Security (Optional)

Within Inventory Organization Security, access to inventory organizations can be restricted to specific responsibilities. For example, the client may wish to restrict the Manufacturing users to certain organizations according to the organization heirachy.

(MO 17) Setup Subledger Applications

This qualifies as the point at which modules other than General Ledger can begin their set-up activities. It is important to carefully co-ordinate the start of these activities and make sure your project team members use the newly defined Operating Unit responsibilities to complete set-up. Remember that OU-specific applications need to have setup done for each defined operating unit.

(MO 18) Secure Balancing Segment Values by Legal Entity (Optional)

Using the define security rule window create rules that secure data entry of balancing segment values for each legal entity. Each security rule is composed of one or more security rule elements that specify a range of values to include or exclude.

(MO 19) Verify Multi-Org Setup

Run standard Multi-Org Validation Setup Report to identify any problems with the set-up. Resolving any identified exceptions on the validation report eliminates the risk that a missed setup step is the cause of any unforseen future issues making the trouble-shooting process easier.

(MO 20) Implement Document Sequencing (Optional)

After Multiple Organizations have been implemented, document sequencing can be setup. This is a common requirement for European companies.

(MO 21) Define Intercompany Relations (Optional)

Define Intercompany Relations is only necessary when using the Multiple Organization Intercompany Invoicing functionality. Intercompany relations need to be defined for each Shipping/Selling relationship in the organization. Defining these relations will allow for the creation of automatic intercompany invoices.

(MO 22) Set Top Reporting Level Profile (Optional)

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.

(MO 23) Setup Conflict Domain (Optional)

A conflict domain is an abstract representation of the groupings used to partition data. When a program is listed as incompatible with another, the two programs cannot run simultaneously in the same conflict domain. Two incompatible concurrent programs may run at the same time if they are in different conflict domains. To maximize the concurrency in a multiple organization environment, conflict domains can be setup for operating units.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.

Multi-Org Lessons Learned

In addition to the items noted throughout this guide, this section will highlight some of the additional lessons we have learned from our US multi-org implementations.

When defining your General Ledger responsibilities, if you are planning to use the standard SmartClient drill down capabilities, you will need to define a separate GL responsibility for each operating unit you require drill down capabilities. Responsibilities are tied to an operating unit, and it is a one-to-one relationship. For example if you have 3 operating units and you allow GL Inquiry users to utilize drill down capabilities into AR, you will need 3 GL Inquiry responsibilities. If one person in your organization is responsible for all three operating units, they will have three responsibilities assigned to them in order to access the drill down functionality.

When designing and planning for data conversions into an Oracle multi-org environment you should keep in mind the impact that, the number of operating units can have. For example, if you have three operating units for AR and you need to convert your open balances. You will need to do this at an operating unit level and run the Auto-Invoice programs for each operating unit, thus effectively increasing the number of jobs to covert that you may need to run by three. An additional point to keep mind specifically for AR is that the Auto-Invoice process is typically spawned to optimize the execution process of this resource intense job. Typically for most organizations, this results in only one operating unit being converted at time. So, plan accordingly! Note these factors are dependent on individual platform, memory, processor and concurrent manager configurations.

Clients that are implementing decentralized ordering are always staggered when they realize that Sales Organizations that share customers have to re-enter the same record in different OUs.

Clients that have sought to implement Shared Services for Payables while retaining their separate Purchasing organizations have to deal with the Multi-Org limitations. Operationally, this means they have to set-up multiple Supplier Site records. Upon payment time the Payables Staff not only have to use different responsibilities, but they also cannot combine check payments for the same supplier servicing different OUs.

When you disable an organization, there is no relationship revalidation for the LE-OU-Inventory Organization hierarchies so you really have to be careful.

SummaryIn Conclusion, Multi-Org can be implemented successfully in a rapid or traditional implementation timeframe. As in any implementation on any platform, proper planning is critical. Take the time with the client to plan and review your multi-org requirements and understand them with your business processes, it will support your efforts to a successful implementation on any platform.

APPENDIX A

Multi-Org Set-up Chart Details

Set of Books

Set of Books NameFunctional CurrencyAccounting Flexfield StructureCalendar

Organizations

Organization Name

Organization Multi-Org Matrix

Organization NameIs it a Legal Entity?Is it an Operating Unit?Is it an Inventory Unit?Set of BooksLegal EntityOperating. UnitApplications.

APPENDIX B

Responsibility Profile Options

ModuleResponsibilityHR: Business GroupGL:Set of BooksAR:Receipt Batch SourceOE: Transactio Batch SourceOE:Set of BooksSequential NumberingINV:Intercompany Currency ConversionTax:Allow Override of Tax CodedTax:Invetory Item for FreightTax:Invoice Freight as Revenue

EX:

ARAR Collector

Copyright ( 2000 KPMG Consulting, LLC

All Rights ReservedPage 11 of 1C:\R2i_project\Rel 3.0 Upd config docs\GL Multi Org Setup.doc