Search from 700 + Posts

Oct 23, 2011

MOAC in R12 Order Management

In this post I will explain the MOAC feature offered in Oracle Apps R12

MOAC – Multi Operating Unit Access control is a major Feature that Oracle has introduced in R12.
In this post I will explain in brief, impact of MOAC in Order Management.

With the MOAC in place, now user can access to multiple operating units without changing the responsibility. This will be of great help to organizations where user need to change responsibilities to access different operating units
Like Shared Services.

To Implement MOAC, Oracle has introduced new field “Operating unit” in almost all UO like Sales Order, Quick Sales Order, Find Windows (Please refer the user guides for complete list).

Now whenever user Navigate to Transaction related forms like Sales Orders, it is mandatory to enter an OU first to create an order. The moment user select the Operating unit, all the fields that are depend on Operating Units like Ship To, Order Type etc will display data that is relevant for the OU.

Apart from the UI’s like Orders Summary, Book Order, Hold will display Orders across all accessible Operating Units. As explained above whenever user change the Operating Unit, system will clear all the operating units sensitive fields.

In Order management LOV’s for all OU dependent fields have been enhanced to display the Operating unit name along with values.


Let’s take the example of item LOV. As we know in OM item LOV will display all the items based on the Item Validation Organization. Item validation org is depending on the Operating Unit. When Operating Unit field has a value (derived or default) the item LOV will display data based on the Item Validation Org for that Operating Unit. If the Operating Unit is cleared or changed the Item field will be cleared. When the Operating Unit field is null, the item LOV will display data for the Item Validation Org setup for the default OU.

Reports
In almost all the reports a new parameter Operating Unit has been added. If user provides the value for this parameter then Report will be executed for that parameter only, but in case user left that blank report will execute for all the operating units (Accessible to user). Not only that once we select the Operating Units all the OU depend parameter reset, so that they will reflect the value for the selected Operating Unit.
Few of OM reports have made Global, i.e. they will execute and display the data for all the operating units (Accessible to user).

Before we start wring sql/plsql etc we have to keep in mind that in R12 all the operating Unit sensitive view has been replaced with the secured synonyms.
So to set the context they need to execute
MO_GLOBAL.Set_Policy_Context

This API has 2 parameters
Context
Org_id

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.


NOTE – if user don’t set this context all the secured synonym will not return any data.


SETUP – For complete info, please refer my earlier post.
Set the Global Profile
Set MO: Security Profile
Set MO: Default Operating Unit

2 comments:

  1. I got the requirement,earlier we used to run a report in two different operating units and in that report in after parameter form and before report they initialized mo_global.set_policy_context('S',:p_org_id),Here :p_org_id is the parameter which is passing from the profile option,So it worked fine as they ran from different ou's,But now they would like to run from one responsibility to which they have created a security profile and added two ou's to that security profile Please help me how we can make it work ,as earlier user is not passing any org_id bu it is impacting by default and now also they wont like to pass any org_id but it needs to work..

    Thanks in advance

    ReplyDelete
  2. Hi

    If you have a security profile and that has more than one Operating units associated to it then user need to pass Operating Unit as parameter to reports , other wise it will be executed for all the operating unit for that security Profile.

    Please note that When a session is initialized in the applications, values will be populated into mo_glob_org_access_tmp for each of the operating units the user has access to based on their "MO: Security Profile" setting , thus that is reason if we want to run the report/API for one particular operating unit we use MO_GLOBAL.SET_POLICY_CONTEXT('S',org_id) to restrict the access to a Specific Operating Unit

    Any Reason why user don't want to select value for just one additional parameter , With new MOAC feature they need not to switch responsibilities to access different OUs, thus save lot of time, with the cost of one additional parameters.

    Hope that would be of some help.

    ReplyDelete