Now in Release 12, Multi-Org Access Control (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 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.
The question is how it is possible in R12 and not in 11i...
ANSWER is the Virtual Private Database (VPD) enables data access control by user or by customer with the assurance of physical data separation. This feature came in Oracle 10g databse.
Base data tables exist in the product schema with a naming convention of %_ALL. The data in this table is striped by ORG_ID (Operating Unit).
To view this info in APPS schema user use to use some VIEWs based on evirnmental variable.
In R12 these kind of VIEWs are phased out and SYNONYMs came in...
e.g.
In 11i therer was a view OE_ORDER_HEADERS in APPS schema which use to retrive / show information base on below SQL statement.
SUBSTRB(USERENV ('CLIENT_INFO'), 1, 10)
....................................................................................................................................................
Now in R12 synonym in the APPS schema provides the Multi-Org filtering based the Virtual Private Database feature of the Oracle 10G DB Server.
For more technical knowledge please refer www.norcaloaug.com/seminar_archive/2009.../4_01_peters.ppt
ANSWER is the Virtual Private Database (VPD) enables data access control by user or by customer with the assurance of physical data separation. This feature came in Oracle 10g databse.
Base data tables exist in the product schema with a naming convention of %_ALL. The data in this table is striped by ORG_ID (Operating Unit).
To view this info in APPS schema user use to use some VIEWs based on evirnmental variable.
In R12 these kind of VIEWs are phased out and SYNONYMs came in...
e.g.
In 11i therer was a view OE_ORDER_HEADERS in APPS schema which use to retrive / show information base on below SQL statement.
SUBSTRB(USERENV ('CLIENT_INFO'), 1, 10)
....................................................................................................................................................
Now in R12 synonym in the APPS schema provides the Multi-Org filtering based the Virtual Private Database feature of the Oracle 10G DB Server.
For more technical knowledge please refer www.norcaloaug.com/seminar_archive/2009.../4_01_peters.ppt
In Release 12, you can create a Security Profile and assign as many operating units as you want to that security profile.
Multi-Org Access Control Setup:
Using Oracle HRMS, you can define your security profile using two forms:
- The Security Profile form, which allows you to select operating units from only one Business Group
- The Global Security Profile form, which allows you to select operating units from multiple Business Groups
Also it can be done by creating organization hierarchies to show reporting lines and other hierarchical relationships. If you want to include organizations from a single Business Group, use the Organization Hierarchy window, alternatively, use the Global Organization Hierarchy window to include organizations from any Business Group. Always define hierarchies from the top organization down.
After doing these setups or modification in security profile, run a concurrent request called “Security List Maintenance” from HR which makes those security profiles available and allows you to assign them to a responsibility via a profile option called “MO: Security Profile”
1. The MO Security Profile controls the list of operating units that a responsibility or user can access. If you set the security profile at the responsibility level, then all users using that responsibility will have access to only the operating units available in the security profile.
If you set the security profile at the user level, then the user will have access to only those operating units, irrespective of application responsibility that they log into. User level security profile over rides, security profile assigned at other levels.
2. The MO: Default Operating Unit is optional and allows you to specify a default operating unit that defaults when you open different subledger application pages. Because you can access multiple operating units, you may want to set up a default one instead of forcing users to constantly have to choose one. User Preferences allows you to specify a default operating unit at the user level. Use the MO: Default Operating Unit profile option to set the operating unit context or default operating unit when accessing an applications.
3. The last profile option is for backwards compatibility and to support products that do not use Multiple Organizations. The release 11i setting was for this is preserved during upgrade. The Release 11i MO: Operating Unit profile option is supported in Release 12 as not all customers of Oracle products require multiple organizations.
Multi-Org Access Control Process:
CASE:
Within a Business Group “Vision Corporation” we need to give access to Multiple Operating Unit through one responsibility, base on conditions. MOAC going to help in this.
For one particular responsibility called “DG- Purchasing SuperUser” there is a requirement of having access to multiple Operating Units listed below:
- Vision Construction
- Vision Corporation
- Vision Operations
- Vision Services
Due to many other requirements one hierarchy “DEVendra- Org Hierarchy” exists with the structure as show below.
- Vision Corporation
- Vision Operations
- Vision Services
- Vision Utilities
In this case we can define one security profile “DEVendra- Security Profile”, use existing hierarchy and include one more OU “Vision Construction” also exclude “Vision Utilities”.
As this is the requirement with in Business Group, Organization Hierarchy and Security profile will serve the purpose. Had it been a requirement across Business group, we would have gone for Global Organization Hierarchy and Global Security profile.
NOTE: The case we are going to consider is hypothetical and the numbers of Operating Units are only 3-4, in practical it could be much more. So just imagine if a hierarchy has 50 OUs list and only 2 OUs needs to excluded / included for one of requirement… this consideration will give better understanding of this demo…
Check / Create a Hierarchy:
HRMS Manger (R) > Work Structures > Organizations > Hierarchy
Create a Profile:
HRMS Manger (R) > Security > Profile
Enter a name, and select the Security Type called “Secure organizations by organization hierarchy and/or organization list”. This allows you to assign multiple OUs.
NOTE: Optionally use the next two steps to enter a list of Operating Units instead of a Hierarchy or to add additional Operating Units to the list included in the Hierarchy.
Enter Classification: Operating Unit and Organization Name.
This will give access to “Vision Construction” as well as all OUs in the attached hierarchy excluding “Vision Utilities”. Hence the purpose mentioned in this case will get solved.
Run the Security Maintenance List program
Name : Security Maintenance List
Parameters: Generate list for... All Security Profiles
Create a customized responsibility
System Administrator (R) > Security > Responsibility > Define
.
.
Assign the security profile
System Administrator (R) > Profile > System
Assign the responsibility to your user
System Administrator (R) > Security > User > Define
Test the MOAC Setup whatever we did here...
Login > DG- Purchasing SuperUser (R) > Purchase Order > Purchase Order
Check LOV in the Operating Unit field to see the list of Operating Units that can be accessed.
Note: If the pictures have bad visibility please CLICK HERE
