Oracle Apps R12 Multi Org Structure

What is a Multi Org Structure?

If an enterprise or a business wants to implement multiple organizations such as multiple Ledgers (Sets of Books), or Legal Entities, or Business Groups within a single installation of Oracle Applications, then we can summarize that the enterprise is planning to implement a multi org setup.

Example:

Before we dive into this topic, let us draw a multi org structure on a whiteboard. It would help to analyze a real picture, as we pick at the concepts that go into designing a multi org structure.

The above is the organization structure for Office Smart Solutions, which is a major office supplies retailer, headquartered in Naperville, Illinois, USA. The organization operates in three countries – the US, Canada and India.

Office Smart has an organization structure with the following:

·               2 Business Groups – one in the US, which controls the organization structure in North America, and one in India

·               3 Legal Entities – one in the US, one in Canada, and one in India

·               3 Primary Ledgers – one in the US, one in Canada, and one in India

·               3 Operating Units – one in the US, one in Canada, and one in India

·               5 Inventory organizations – two in the US, one in Canada, and two in India

·               Subinventories and locators exist beneath the inventory organizations, but they are not relevant for the session on multi org structures.

With this, let us step back and reflect…

 

The way it was in 11i

 

In 11i, a user working with a specific responsibility, under a given operating unit, would need to switch responsibilities, if she were to access a sales order that was created from a different operating unit. For this to happen, the user had to be assigned a second responsibility that was linked to the second operating unit.

From an implementation perspective, this implied that each responsibility could be linked to one and only one operating unit. Thus, if a user in Office Smart Canada, needed access to data in Office Smart US, then she would need to be assigned a responsibility that was tied to the US Operating Unit – Office Smart Operations.

Responsibilities were tied to operating units through the profile option MO: Operating Unit.

 

What R12 brings to the table

 

Release 12 brought with it, the philosophy of Multi Org Access Control (MOAC).

“Globalization is unstoppable. Regardless of geography, industry or income, companies are globalizing to gain new customers and access new markets. Is this a good thing? Nearly two-thirds of the CEOs we surveyed are positive about the impact that globalization will have on their organizations over the next three years.”

Source: 9th Annual Global CEO Survey – Globalization and Complexity; PwC 2006

With Release 12, Oracle Applications had to ensure that certain aspects of the applications were redesigned to meet the inevitable advance of Globalization.

 

Organizational changes in R12

 

The Set of Books evolved into Ledgers and Ledger Sets. The philosophy of Multiple Organization Access Control (MOAC) introduced in R12, ensured that the same user could perform multiple tasks across operating units without changing responsibilities. The use of Security Profiles was extended beyond HR to make MOAC possible.

 

Organization Access Control in R12

 

In a multi org environment, securing the data in each organization becomes a key task and concern for management and the implementation team. By creating custom responsibilities, management ensures that employees are given access to only those menus and functions that they need to perform their routine activities. However, an addition layer of security needs to be designed to ensure that using those menus and forms given to them, employees cannot trespass into an organization that they should not have access to.

As mentioned above, in 11i access to organizations was compartmentalized based on operating units. This ensured data security, but at the expense of making it a little cumbersome for the user to switch between organizations that belong to different operating units.

The Multi Org Access Control (MOAC) feature in R12 retains the data security aspect between organizations and users. However, it also brings with it a certain degree of user friendliness in navigating between different operating units.

 

How does R12 implement this change?

 

This series is designed to highlight all that it takes to implement a Multi Org Structure in Release 12.

Convert Single to Multi Org in oralce apps

Step- 1

Before running the Convert to Multi-Org process, make sure you do the following:

• Apply the AD Patch 2412184: ADADMIN Convert to Multi-Org Performance Improvement: Increase parallelization

• Define at least one Operating Unit, and set the profile option, "MO: Operating Unit" at Site level, to that Operating Unit's value

Step- 2

Run Convert to Multi-Org process available from the Database Objects menu of the ADADMIN utility. The Convert to Multi-Org process upgrades a standard product group into a Multi-Org product group. You can choose this option only if you do not already have Multi-Org set up.

The Convert to Multi-Org program does the following:

• Populates the ORG_ID column in the Multi-Org tables with the new operating unit value you defined at the site level profile option: MO: Operating Unit

• Sets the MULTI_ORG_FLAG in the FND_PRODUCT_GROUPS table to “Y”

• Runs the “Replicate Seed Data” program

If you define more than one Operating Unit, the replicate seed data process is run for all Operating Units.

Step- 3

After running the Convert to Multi-Org process, make sure you apply the following TCA patch as post conversion process:

• Patch 2451368: Migrate data from Customers to Site Uses

R12 Multi-Org Access Control - features and benefits in oracle apps

Multi-Org Access Control - Description:

In 11i, when users had to enter or process data for multiple operating units, they had to login to different responsibilities because each responsibility could only access one operating unit. So if there were a centralized payment processing center where users processed payments for multiple organizations, they would have to keep logging in and out of different responsibilities to process payments for a different organization or operating unit.

Now in Release 12, Multi-Org Access Control 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 application’s 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 that will now support multiple operating units.

Multi-Org Access Control - Example:

For example, if you have three operating units in the center you were managing, such as a Belgium Operating Unit, a Holland Operating Unit, and a Denmark operating unit, in 11i you needed to define three different responsibilities. If you had one user who processed payables invoices across all three operating units, then you would need to assign the three responsibilities to that user and then the user would need to log in and out of each responsibility to process invoices.

In Release 12, you can create a Security Profile and assign as many operating units as you want to that security profile. So in this example, you could assign all three operating units to the same security profile. Then, you can tie that security profile to a single responsibility using a profile option called MO: Security Profile. For example, you could assign the security profile to the EMEA 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.

MOAC - Benefits:

•Improve Efficiency
–Process data across multiple OUs from one 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 data entry
–Reduce setup and maintenance of many responsibilities


Multi-Org Access Control Process Summary:

Each Financials 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 reads 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.

Oracle Multy - Org process

Multi-Org or multiple organization access (MOAC) is basically the ability to access multiple operating units from a single application responsibility. In Release 11i, when one had to enter or process data for multiple operating units, one had to login to different responsibilities because each responsibility could only access one operating unit. If one was managing Payables for Sweden, Norway and Finland one needed to define three different responsibilities. In Release 12, one would create a Security Profile and assign as many operating units as you required. One can tie that security profile to a single responsibility using a profile option called MO: Security Profile. For example, you could assign the security profile to the EMEA Payables responsibility to allow that responsibility to process invoices across all three operating units.

In Release 12, define a security profile in HR using the Security profile form or the Global Security profile form, and assign all of the operating units that one would want a responsibility to access. The one needs to run a concurrent request called “Run Security List Maintenance” from HR which will make those security profile available and allow one to assign them to a responsibility via a profile option called MO: Security Profile.

One can define an operating unit using the Accounting Setup Manager in Oracle General Ledger or Organization Definition form in Oracle HRMS or Inventory. We shall discuss about Accounting Setup Manager in a future blog post. An operating unit is then attached to a default legal context (as compared to Legal Entity in Release 11i)
Define a security profile using either of the two forms: Security Profile form or the Global Security Profile Form that is shown below. Both forms look almost identical where Security Profile Form allows one to select operating units from only one Business Group where as Global Security profile Form allows one to select operating units from multiple Business Groups. One can define another profile option called MO: Default Operating Unit which is optional and allows one to specify a default operating unit that will be the default when you open different subledger application forms.

Oracle apps MOAC setup in R12

The Security Profiles form allows you to group together Operating Units

Define the security profile for the order management responsibility:

Navigate: HRMS Management responsibility:

1. HRMS Manager > Security > Profile
2. Verify that the security profile is defined for the OM responsibility.
3. If the security profile is not yet setup, enter it and attach the operating units
4. SAVE

The Security List Maintenance concurrent program must be run each time you add or change Security Profiles.

There are three Profile Options you need to be aware of related to Multi-Org that should be set at the Responsibility Level.

•         The R12 profile option ‘MO: Security Profile’ is always evaluated first.

•         The pre-R12 profile option ‘MO: Operating Unit’ still works in R12.  It is just a secondary priority being evaluated after ‘MO: Security Profile’.

•         The R12 profile option ‘MO: Default Operating Unit’ sets the default Operating Unit for transactions when running under a Security Profile.

Many R12 applications modules do not work with ‘MO: Security Profile’ set for a given responsibility. 

•         They must only use ‘MO: Operating Unit’.

•         Some even require all three Profile Options set.

Examples:

–         CRM Modules

–         Certain GL Drill Down Functions

(Trial and error determination of setups, no clear direction)

Now check the operating unit field in the order’s screen

Vision Operations defaults as the operating unit in the form per profile option setting for ‘OM: Default Operating Unit’ at responsibility level

Multi Organizations Access Control (MOAC)

The new feature in R12 enables companies wanting to implement a shared services operating model to efficiently process business transactions by allowing them to access, process and report on data for an unlimited number of operating units within a single applications’ responsibility.


With MOAC, users can:

• Perform multiple tasks across Operating Units without changing responsibilities such as invoice entry, order processing, bank payments etc. thus improving the efficiency of transactions for companies that have centralized business functions or operate Shared Service Centers
• Obtain better information for decision making such as, accessing supplier and customer site levels details across multiple OUs
• Speed up data entry
• Reduce setup and maintenance of many responsibilities

How MOAC works technically:
MOAC is initialized when you open a Form, Oracle EBS page or a Report or submit the concurrent program. The first MOAC call checks if the profile “MO: Security Profile” has a value. If Yes, then the list of operating units to which access is allowed is fetched and the list of values (LOV) is populated .This list of values is nothing but list of OUs associated with the Security Profile attached to MO: Security Profile. Security profiles are defined with the help of the HR responsibility. Then, default value of the LOV is set to the operating unit specified in “MO: Default Operating Unit”.
When the profile “MO: Security Profile” does not have a value, MOAC switches to the 11i single organization mode. As in 11i, the profile “MO: Operating Unit” is checked and the operating unit is initialized to the one defined in it.
The important point to note here is that the profile “MO: Operating Unit” is ignored when the profile “MO: Security Profile” is set.
MOAC setups:
Following are the basic steps to be performed in order to enable MOAC feature:

1. Define Security Profiles (using form function ‘Define Global Security Profile’)
   • Enter a unique name for the security profile.
   • To restrict access by discrete list of organizations, select ‘Secure organizations by organization hierarchy and/or organization list for the Security Type’.
   • Check the Exclude Business Group check box to remove the business group in the list of organizations.
   • Use the Classification field to limit the list of values (LOV) in the Organization Name field. For example, if you select the classification to Operating Unit, only operating units will display in the LOV.
   • In the organization name field, select the Operating Unit for which you want access.
   
   
   • Repeat until you have included all organizations to which you need access.
2. Run the concurrent program “Security List Maintenance Program” from the standard request submission form. The “Security List Maintenance Program” can be run for a single named security profile to prevent impact to other security profiles.
3. Assign appropriate security to the profile option “MO: Security Profile” for your users and responsibilities
   • Navigate to the “System Administrator” responsibility > System Profile Options
   • Assign the security profiles to MO: Security Profile for your responsibilities and/or users.
     
4. Assign a value for profile option “MO: Default Operating Unit” (Optional)
   • Navigate to System Administrator Responsibility > System Profile Options
   • Assign a default operating unit to “MO: Default Operating Unit” profile option for your responsibilities and/or user.
5. Assign MO: Operating Unit (Mandatory for only Single Org or if MO: Security Profile is not defined)
   • Navigate to System Administrator Responsibility > System Profile Options
   • Assign the Operating unit to MO: Operating Unit profile option for your responsibility or user.

Note – From the above screen shots we can conclude that user with purchasing responsibility will be able to access data from two Operating Units Vision Operations and Vision Services.
Developer’s Insight:
To increase the flexibility and performance in a multiple organizations environment and provide the same level of data security, the DBMS Virtual Private Database (VPD) feature replaces the CLIENT_INFO function.
The Virtual Private Database (VPD) feature allows developers to enforce security by attaching a security policy to database objects such as tables, views and synonyms. It attaches a predicate function to every SQL statement to the objects by applying security policies. When a user directly or indirectly accesses the secure objects, the database rewrites the user’s SQL statement to include conditions set by security policy that are visible to the user.
MOAC –Changes to Custom Code while upgrading to R12 from 11i-–During R12 upgrade the major task is to enable the MOAC feature to custom code. Following is the recommended approach to achieve MOAC implemented in real aspect to custom code:

1. Multiple Organizations Views/Tables Changes Single Organization View –
   • Drop the single organization view
   • Create a synonym with the same name as the obsolete single organization view
   • Attach a policy function to the synonym
   Reference Views –
   
   • Add the ORG_ID column if it does not exist
   • Replace single organization views with _ALL tables for all except one, which must be a secured synonym
   • Include the ORG_ID filter in the where clause of the view to avoid the cartesian product, if the ORG_ID is the driving key or part of the composite key
   • Include the ORG_ID parameter in the columns based on functions, if necessary
2. Enhancements to Forms The multiple organizations setup and transaction forms must display the Operating Unit field. This allows users to select the operating unit and enter the setup or transaction for the operating unit. Oracle recommends deriving the operating units from the transaction attributes.

1.  Enhancements to Reports and Concurrent Programs
   • You must remove references of CLIENT_INFO and NVL function to the ‘ORG_ID’ column in the reports.
   • Single Organization Reports—The operating unit mode for single organization reports are flagged as     ’SINGLE’ in the Define Concurrent Programs page.
   • Cross Organization Reports–The Operating Unit mode for cross organization reports are flagged as ‘MULTIPLE’ in the Define Concurrent Programs page.
2. Enhancements to Public APIs
   • Do not use the multiple organizations temporary table directly in the SQL query.
   • Rewrite the SQL joins with two or more views to use just one secured synonym depending on the driving table for the query and replace the remaining views by _ALL tables.
   • Add the ORG_ID to the WHERE clause of the SQL to avoid cartesian joins for tables that include ORG_ID the composite or driving key.
   • Use MO_GLOBAL.Set_Policy_Context.
     This API has 2 parameters –1. Operating unit 2. Context
     Context has 2 values 1. M  2. S
     When policy context is set to ‘M’, data from all accessible Operating Units will be returned.
     When policy context is set to ‘S’, then only data from the specified Org_Id will be returned.
   • Products must call the MO_GLOBAL.init() API to execute the multiple organizations initialization.
3. Enhancements to Workflows
   With multiple organizations access control, you must set the current organization ID and not the CLIENT_INFO org context. You must derive the current organization ID from item keys. Do not rely on MO: Security Profile, MO: Default Operating Unit, and MO: Operating Unit profile options when setting the organization context because the operating unit must be validated before initiating the workflow.

MULTI – ORG Concept in Oracle Applications R12

What is Multi-Org?
It’s a feature used to store the data of multiple organization in a single instance by partitioning the data of human resource, financials, sales, purchases, assets and materials
Examples of Multi Org are Tata Group, Reliance Group, Mahindra Group etc.
Let us consider Tata Group to illustrate more on Multi Org

In the above illustration Tata Finance, TCS, Tata Motors are individual organizations.
NOTE: The complete organization data are maintained at one place.
Financial statements are to be created for individual organization separately this is achieved using E BUZ Suite.
Multi-Org has been categorized into:

1. Business Group
2. Ledger
3. Legal Entities
4. Operating Unit
5. Inventory Org

 1. Business Group:

Business Group is a top level in the org structure. At this level we secure work structures (Job Structure, Position structure, Grades structure) and remuneration policy (Pay roll Policy).
Structure for Jobs, Position, Grades may differ from organization to organization, say position structure in a organization may have clerk, senior clerk, manager, senior manager. Where as in another organization it may only have clerks and managers.
Based on the Work Structure and remuneration the business group are created. If all the 3 organization (Tata Finance, TCS, and Tata Motors) have different Work Structure and remuneration then we need to define 3 business groups else if they have the same Work Structure and remuneration then only one business group is defined.
Module involved is HR

 2. Ledgers:

Ledgers are used to secure journals and ledger balances of the company. A ledger is a collection of currency, calendar, chart of accounts and sub ledger accounting (SLA) methods.

Currency, here we setup the local currency for the organization where its business is defined say INR (INDIAN Rupee) this is used only to report the balances but the transaction can be done in other foreign currency also including INR.
 Calendar, the financial year is been defined to control the transactions and secure them. We divide the financial year into PERIODS, periods may be defined daily, Monthly, Quarterly this is only to restrict the transaction as transaction can happen only for the period that’s open, say in July we can have transactions for the month of July and August as its open but we can restrict for September by keeping it closed.
 Chart of Accounts, here we define the accounts setup for an organization. For better understanding let us take an example where in we need to create an account when a rent has been paid. The account entry would be
 Rent A/c
To Cash
 Now to differentiate this based on the organization say if the rent is for Tata Finance or TCS or Tata Motors. The entries can be

So for this when the transaction is recorded the entry in the system would be 01.1001
If there are any further division (category) then a new segment is created but if an organization is not having any division then a default segment is also defined.

Now the account for tata motors having division for cars in a particular location say hyd and for payables as an account would be 01.001.0001.1002, if tata finance has no division and location but with rent account then the entry would be 02.000.0000.1001

Note: An account that is defined for an organization is a combination of Company code and Account code, that are defined if there are no segments (Division, Location etc) been defined. We should have minimum two segments and a maximum of 30 segments when defining an account.

Sub Ledger Accounting: (SLA), how to maintain the account is been defined in SLA, the accounts may be accrual based or cash based.
Module involved is GL

3. Legal Entities: 

This is a legal business or a registered firm; at this level we prepare income tax reports.
In our example we would be having 3 legal entities (Tata Motors, TCS, and Tata Finance)
Legal Entries are used to report the Tax Reporting

4.    Operating Unit: (OU)

 An operating unit is division of legal entity, at this level we secure the sales and purchase transactions.
Now we also need to keep in mind that an OU can be set at the division level or location level or branches based on the sectors.

Here in the above illustration Cars and Trucks are division, Hyd, Pune and Bangalore are location.  OU can be set at Division level or Location level or Branch Level.
If the OU is set at branch 1 then branch 2 cannot see the details (Sales and purchases) of branch 1 and vice versa as they are secured. Similarly if set at the location then it is secured with that location and restricted from other locations.
Module involved is AR, AP, PO, OM, CM etc

5. Inventory Org:

This is used to secure the materials of an organization.
Note: Legal Entity can also be an Operating Unit as there are no further division in a organization.

Multi - Org Concept in Oracle Apps R12

  Multi-Org in simple term means the implementation of multiple business units (or Organization) under a single installation of Oracle Applications. The concept of Multi-Org will manage the operations of an enterprise which has got subsidiaries across globe under a single oracle apps window, taking appropriate care of data security and data maintenance. Below are some of the features of multiple organization functionality.

• Any number of Business Units in an Enterprise can be supported within a single installation of Oracle Application

• User can access the data corresponding to and limited to the operating unit

• Reporting can be managed at different organization levels like, Business Group, Ledger, Operating unit etc

• Transactions like Procurement, Receiving, Selling, Shipping Etc. with the same Party Can be Performed through Different Organization and can be managed internally through inter company postings

A real time organization construct in R12

Here in this example construct, CCS Company has organization structure as follows

1. 1 Business Group - Which controls the organization in America and Australia
2. 2 Legal Entities - one in US and one in AU
3. 2 Primary Ledgers - one in US and one in AU
4. 2 Operating Units - one in US and one in AU
5. 3 Inventory Organizations – two in US and one in AU

How Organization Hierarchy flow in Oracle R12

Multi-Org and Multi-Org Access Control in R12 (MOAC)

Prior to R12, user has to switch between responsibilities to enter transaction and for doing other activities for a particular organization. This is very time consuming to do activities in an environment like this if you have 100 operating units. To overcome this factor, oracle has introduced a new feature in R12 which allow the user to switch the organization from the same responsibility which enables the user to access different organization and its data from a single responsibility. 

To achieve the new objective, Oracle has introduced new functionality called Multi-Org Access Control (MOAC) in release 12. Following are the set up steps needs to follow for implementing the MOAC architecture for a particular application

Multi – Org Setup Steps in R12

1. Define Location

Open HRMS Manager Responsibility and navigate to Work Structure à Location

Define your location Specific Details (BG Address and time zone) for your Business Group in ‘Address Details’ tab and Shipping details in ‘Shipping Details’ tab as below.

Save the Changes

Following table will hold location details

 HR_LOCATIONS_ALL  

2. Define Business Group

Open HRMS Manger responsibility and navigate to

Work StructureàOrganizationàDescription

Enter the business group name and assign the location created in the previous step and save the changes

Select the LOV as business group under the ‘Organization Classification’ block

Select ‘Business Group from the LOV and check ‘Enabled’ check box for the business group name and save changes

Now click on ‘Others’ button and select the Business Group info from the additional window and click OK, then another window will get opened with name ‘Additional Organizations Information’ like below

Press TAB and enter the mandatory details like below

Click OK Button, then you will be prompted to save the changes. Press on YES button. The details will get saved.

Following Table will hold business group information

HR_ALL_ORGANIZATION_UNIT

3. Create Legal Entity

As per the structure defined, we have to create the one legal entity for AU operation.

 Switch the responsibility to General Ledger and navigate to the following

 SetupàFinancialsàAccounting Setup ManageràAccounting Setups

 In Release R12, the legal entity setup is a part of accounting setup.

Press button ‘Create Legal Entity’ and enter the Details

Click on ‘Create New Address’ to create the new address

Click ‘APPLY’ to save the changes.

Legal Entity details will be available in the following table

 XLE_LE_OU_LEDGER_V

4. Define Ledger

Navigate to Accounting Setup Manager and define the New Ledger for the Legal Entity created

Ledger Details Will be available in the Following table

 GL_LEDGERS

5. Create and assign Operating units to Legal Entities to Ledger

In this step we will assign operating unit to Legal Entity. This will be defining from General Ledger responsibility

Navigate to Setup –> Financials –> Accounting Setup Manager –> Accounting Setups

In the Ledger Definition window, enter the Ledger name and press GO button. Once the search finishes and resulted with the Ledger name, Click on ‘Update Accounting Options’ button

Then Assign the Legal Entity to the ledger by clicking ‘Add Legal Entity’ button

Search for the legal entity created in our previous step and click on apply button to save the changes. Now the legal Entity is assigned to Ledger

Now click on Update button next to the operating unit setup option

Click on Add operating unit

Enter the details. Assign the business group and legal entity created from the above steps to the operating unit and click on apply button

After completing all ledger option press ‘Complete’ button to complete the accounting setup

6. Create Inventory Information

Switch to Human Resource responsibility and Navigate to the following

 Work Structure àOrganizationàDescription

 Click on New Button to create the new Inventory Organization

From the Organization Classifications Frame, select the option Inventory Organization from the LOV.

Press OK to save the Details

No click on ‘Others’ button and select ‘Accounting Information’ option. A small window will open, Press TAB to enter the details in this window

Assign the following to the inventory organization we have created in our previous steps

Primary Ledger

Legal Entity

Operating Unit

Click OK and Click Yes to save the changes

Again Click ‘Others’ button and select the ‘Inventory Information’ from the list

Then add all inventory details and save the changes.

Once the setup is done, run the following reports/programs to use the operating unit we created

In order to use the operating unit, run the following program and it should be run for all the new operating unit structure

Switch the responsibility to ‘System Administrator’

Program :- Replicate Seed Data

Parameter: - <Operating Unit>

Run the following program

Multi-Org Setup Validation Report

Now the operating units and other related setups are ready to use. Now we have to think how we can enable the multiple organization can be enabled from a single responsibility.

Enabling Multi – Org Access Control (MOAC)

MOAC is implemented in R12 to allow the users to submit requests and access data of different operating units in a single responsibility. This functionality can be done by setting the SECURITY PROFILES under HRMS module

There are 2 security profiles:

• SECURITY PROFILE:  is used for the selection of operating units from the same business group       
• GLOBAL SECURITY PROFILE: is used for the selection of operating units from the different business group

Set up of Multi-Org Access Control:

• Setup Security Profile in HRMS

Switch the responsibility to Human resource

Navigate to the following

Security àProfile

Select the name for the profile and attach the business group created

In order to have access to the security profile we created, we need to create a responsibility and assign this profile option to the responsibility

Switch to System Administrator responsibility and navigate to the following

SecurityàResponsibilityàDefine

Once the responsibility is defined, assign the new security profile option to the responsibility by navigating the following

Profile à System

This is it!!! 

We have done with the setup of Multi-Org.  This is a key functionality in Oracle R12 which is serving as the stepping stone to Oracle Multi-Org implementation.

Following SQL query can give the relation between Ledger, Legal entity and Operating Units in Oracle Apps R12

SELECT hrl.country, hroutl_bg.NAME bg, hroutl_bg.organization_id,

       lep.legal_entity_id, lep.NAME legal_entity,

       hroutl_ou.NAME ou_name, hroutl_ou.organization_id org_id,

       hrl.location_id,

       hrl.location_code,

       glev.FLEX_SEGMENT_VALUE

  FROM xle_entity_profiles lep,

       xle_registrations reg,

       hr_locations_all hrl,

       hz_parties hzp,

       fnd_territories_vl ter,

       hr_operating_units hro,

       hr_all_organization_units_tl hroutl_bg,

       hr_all_organization_units_tl hroutl_ou,

       hr_organization_units gloperatingunitseo,

       gl_legal_entities_bsvs glev

 WHERE lep.transacting_entity_flag = 'Y'

   AND lep.party_id = hzp.party_id

   AND lep.legal_entity_id = reg.source_id

   AND reg.source_table = 'XLE_ENTITY_PROFILES'

   AND hrl.location_id = reg.location_id

   AND reg.identifying_flag = 'Y'

   AND ter.territory_code = hrl.country

   AND lep.legal_entity_id = hro.default_legal_context_id

   AND gloperatingunitseo.organization_id = hro.organization_id

   AND hroutl_bg.organization_id = hro.business_group_id

   AND hroutl_ou.organization_id = hro.organization_id

   AND glev.legal_entity_id = lep.legal_entity_id