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.
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.
