Multi Org Access Control
An improvement in R12 to facilitate cost savings and to cater to Shared Service Centers
Background of MOAC
In Release 11i Responsibilities have been tied to Operating units and each time a person needed to process transactions for a particular Operating Unit he/she had to switch to the responsibility created for the OU and thereby increasing transaction processing time(and cost), reducing efficienciences allround.
What is MOAC, What is the Change?
In R12 a Security Profile is created and all the Operating Units that need to be accessed are added.
This is done from HR (either the Global security form- across Business units or security form- specific Business Unit)
Then Security List maintenance Program is run to make this Security Profile available for assignment to users and Responsibilities.
When it is assigned at User Level (MO: Security Profile) then the user is able to access all the OU's included in the profile.
When it is assigned at Responsibility Level (MO:Security Profile) from that responsibility it is possible to access all the OU's in the profile.
So in a shared service environment there is no need to log in and logout or change responsibilities.
Additional Features: Now say 10 OU's are included in a Security profile and assigned to a user, who needs to access only 5 daily, he can use the MO: Default Operating Unit and the User Preferences to restrict his access to the ones he really needs to use from amongst the 10.
When Migrating from R11i to R12 the existing Profile MO:Operating Unit is retained for backward compatibility whenever there is no intention to use the MOAC Feature.
So MOAC is as powerful if not more powerful than the proverbial Mother-in-Law!!!!!!!!!!!! (Think of her and her ability to gossip with multiple Neighbours (OU's) LOL. This is an attempt to help newbies to understand the concept in simple layman's language.
An improvement in R12 to facilitate cost savings and to cater to Shared Service Centers
Background of MOAC
In Release 11i Responsibilities have been tied to Operating units and each time a person needed to process transactions for a particular Operating Unit he/she had to switch to the responsibility created for the OU and thereby increasing transaction processing time(and cost), reducing efficienciences allround.
What is MOAC, What is the Change?
In R12 a Security Profile is created and all the Operating Units that need to be accessed are added.
This is done from HR (either the Global security form- across Business units or security form- specific Business Unit)
Then Security List maintenance Program is run to make this Security Profile available for assignment to users and Responsibilities.
When it is assigned at User Level (MO: Security Profile) then the user is able to access all the OU's included in the profile.
When it is assigned at Responsibility Level (MO:Security Profile) from that responsibility it is possible to access all the OU's in the profile.
So in a shared service environment there is no need to log in and logout or change responsibilities.
Additional Features: Now say 10 OU's are included in a Security profile and assigned to a user, who needs to access only 5 daily, he can use the MO: Default Operating Unit and the User Preferences to restrict his access to the ones he really needs to use from amongst the 10.
When Migrating from R11i to R12 the existing Profile MO:Operating Unit is retained for backward compatibility whenever there is no intention to use the MOAC Feature.
So MOAC is as powerful if not more powerful than the proverbial Mother-in-Law!!!!!!!!!!!! (Think of her and her ability to gossip with multiple Neighbours (OU's) LOL. This is an attempt to help newbies to understand the concept in simple layman's language.
0 comments