Multi-Org Access Control

Introduction : Multi-Org Access Control (MOAC)

•         Multi-Org Access Control, or MOAC, enables We to access multiple operating units from a single Order Management responsibility.  

•         It allows companies that want to implement a shared services center to efficiently process business transactions because users are able to enter, process, view, and report on data for an unlimited number of operating units from a single responsibility.  Operating unit security is preserved such that companies can effectively implement security and shared services at the same time.

Prior to Release 12, each application responsibility could access only one operating unit.  Now a more flexible architecture has been put in place to support Multi-Org Access Control (MOAC). This architecture allows users to define security profiles so that users may access data for more than one operating unit within a single responsibility.

To accomplish this

•         Multi-org views have been removed, and replaced with synonyms. For example, MY_TABLE would no longer be a view defined on MY_TABLE_ALL, but rather a synonym which points to MY_TABLE_ALL

•         The data restriction is accomplished by assigning a virtual private database (VPD) policy to the synonym. This policy allows the system to dynamically generate restricting conditions when queries are run against the synonym.

Therefore order management users who had to work in multiple operating units had to log in and log out of multiple responsibilities to perform their tasks. 

If a company had three operating units Belgium, Holland, and Denmark, the company would have to create three responsibilities, one for each operating unit.  Order management users who had to enter orders into all 3 operating units, had to log into each one of the EMEA responsibilities separately. 

With Multi-Org Access Control, each application responsibility can access multiple operating units. The company can create a single EMEA responsibility for all three operating units and Order Management users can log in once to perform various tasks such as set up transaction types,  negotiate sales agreements, enter quotes/order/or returns,  schedule orders,  apply and release holds.

Multi-Org Access Control enables companies that have implemented 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.   This increases the productivity of Shared Service Centers as users no longer have to switch application responsibilities when processing transactions for multiple operating units at a time. 

2: Steps to Setup Multi Org Access Control 

1.      Define Operating Units (Optional)

2.      Operating unit hierarchy (Optional)

3.      Define security profiles

4.      Run security list maintenance Program

5.      Define Responsibilities (Optional)

6.      Assign Responsibilities to User (Optional)

7.      Set profile option values

8.      Set default Operating Unit (Optional)

9.      Setting System Parameters (Optional)

Multi-Org Access Control set-up includes general MOAC set-up and Order Management specific MOAC set-up. Please refer to the Multi-Org Access Control Functional Overview TOI for detailed information on general MOAC setup.  At a high level We need to set-up security profiles that allow access to multiple Operating Units.  We also need to set the following MO profile options, in order to enable Multi-Org Access Control:

            MO:   Security Profile

            MO:   Default Operating Unit.

Note that If We do not set these profiles the application will behave as it does now. This Document will cover the Order Management specific set-up in detail over the next couple of slides. 

As far as process,  any tasks that We can do currently in Order Management, We can do those across Operating Units with Multi-Org Access Control –  This includes viewing and managing set-up data,   viewing and managing transactions,  running concurrent programs and reports.  

3: Define security profiles

The setup for MOAC can be found in the HR Foundation Responsibility. Use the Navigation Path Security => Global Profile. This Profile should be set up to have access to all Operating Units defined in the E-business Suite. To do this a Security Type of Secure organization by organization hierarchy and/or organization list should be assigned to the Global Profile and each of the valid Operating Units within Wer business should be added to the list of Organization Names

Additional profiles can be added through the Security

=> Profile screen. Each profile can be set up to access one or a number of operating units. A profile must be set up for each combination of operating units We wish to access through the E-business suite.

Define 2 Different Security Profiles

4: Run security list maintenance Program

Once the security profile has been created, run the Security List Maintenance program. This ensures that all of the security profiles that We created are available for assignment to Wer responsibilities.

5: Define Responsibilities

Responsibility 1

Responsibility 2

Responsibility 3

6: Assign Responsibilities to User (Optional)

7: Set profile option

Security Profiles can then be assigned to the MO: Security Profile profile at Site, Application, Responsibility, Organization and User levels. For the purpose of this document I have set it up at user level for my own user.

8: MOAC– System Parameters Setup

Use the System Parameters form to review the profiles that are now system parameters.  

Note that this form now has a new field ‘Operating Unit’.  It allows We to view and manage system parameters across all operating units accessible to MO: Security Profile.

9: Validations of MOAC Structure.

Let us look at how We can query sales orders and lines across multiple Operating Units, once We have enabled Multi-Org Access Control.

As We can see,  the Operating Unit has been made visible (using folder tools) in both the Order Organizer Find Window and the Summary Window.

In the Find Window,   if We leave the Operating Unit field blank and do not specify criteria that are Operating Unit sensitive (such as Order Type or Ship To Location etc) We can search for transactions across all the Operating Units that We have access to via Wer MO: Security Profile.  

We can also restrict Wer search to a single Operating Unit by picking one from the LOV or by specifying a query criteria that is Operating Unit sensitive (such as the Order Type).

This is the Order Organizer window.   We can multi-select transactions from across multiple Operating Units in the Order Organizer Summary window, and  perform mass change or any of the following actions on them –

We can -

Ø  Apply Holds

Ø  Book Order

Ø  Cancel Order

Ø  Get Cost

Ø  Price Order/Line

Ø  Release Holds

For example in this slide, we can see how we can multi-select orders across Operating Units and book them.

Querying Orders

Running Reports

We can run reports for multiple Operating units – one Operating Unit at a time, without switching Application Responsibilities

We can choose the Operating Unit We want to run the report for, in the Request Window

When we enable Multi-Org Access Control We can run the reports listed (in the notes section of this slide) for any one of the multiple Operating Units that we have access to, without switching Application Responsibilities. 

As shown on this slide, while submitting the report request we can pick the Operating Unit we want to run the report for. The new field on report submission window defaults to our default Operating Unit, however we can pick a different value from the LOV.   This applies to all Order Management reports that list data from a single Operating Unit.  

MOAC–Run Concurrent Programs

•         The Operating Unit has been added as a new optional parameter to concurrent programs

•         Choose an Operating Unit to run the concurrent program for multiple Operating units – one Operating Unit at a time from without switching Application Responsibilities 

            OR

•         Leave the Operating Unit parameter blank, to run concurrent programs across multiple Operating Units

•         A new Operating Unit parameter has been added to the Order Management concurrent programs listed (in the notes section of this slide).  

•         With Multi-Org Access control, We can run these concurrent programs for any one of the multiple Operating Units We have access to without switching Application Responsibilities.   Or We can leave the new parameter blank and run these program for ALL of the Operating Units We have access to, in one submission. 

•         The programs that behave in this manner are -

•         Audit History Consolidator, Credit Check Processor

•         Credit Exposure Import, Schedule Order

•         Export Compliance Screening, High Volume Order Import

•         Included Items Freeze at Pick Release, Inventory Interface – non ship

•         Order Import, Process Pending Payments

•         Purge Imported Credit Exposure, Release Expired Hold

•         Reserve Orders, Show Sales Order

•         Progress from Firm Process, Purchase Release

•         Purge Open Interface Data,  Order Purge Selection

•         Purge Retro billing Requests, Quote Purge Selection

MOAC-Run Concurrent Programs

Let us look at an example.  As we can see in this screen, we can choose to run Order Import for one Operating Unit by selecting an Operating Unit from the LOV or run it for all Operating Units We have access to by leaving the Operating Unit field blank. If we want to run it for a single Operating Unit, it is recommended that we first select the Operating Unit, as this will automatically restrict all the OU sensitive parameter LOV’s to the selected Operating Unit.

If we leave the Operating Unit parameter blank but specify some other parameter which is Operating Unit sensitive (like Order Type or Ship-to location) we will be restricting the concurrent program to process data from a single Operating Unit.