7/31/2014 Document 397362.

1
https://support.oracle.com/epmos/faces/DocContentDisplay?_adf.ctrl-state=1408lwc1mt_206&id=397362.1 1/7
Multi Org Access Control (MOAC) in Oracle Purchasing (Doc ID 397362.1)
Modified: 12-Dec-2013 Type: BULLETIN
In this Document
Purpose
Scope
Details
Agenda
1. Overview
2. How it works
3. Setups Required

4. Impact of MOAC to Oracle Purchasing
5. Implementation Considerations
6. Customizations
7. Troubleshooting
References
APPLIES TO:
Oracle Purchasing - Version 12.0 to 12.2 [Release 12 to 12.2]
Oracle Inventory Management - Version 12.0.0 to 12.2 [Release 12.0 to 12.2]
Information in this document applies to any platform.
***Checked for relevance on 07-Jan-2013***
PURPOSE
This article will discuss the features specific to uptake of Multi Org Access Control (MOAC) in Oracle Purchasing.
SCOPE
The intended audience is Consultants and support involved in implementing, upgrading or supporting Oracle Purchasing
in Release 12 or above which incorporate this specific feature.
DETAILS
Agenda

1. Overview
2. How it works
3. Setups Required
4. Impact of MOAC to Oracle Purchasing
5. Implementation Considerations
7/31/2014 Document 397362.1
https://support.oracle.com/epmos/faces/DocContentDisplay?_adf.ctrl-state=1408lwc1mt_206&id=397362.1 2/7
6. Customizations
7. Troubleshooting

1. Overview
From Release 12 the Multi-Org Access Control feature, will enable users to access data in one or more Operating Units
from a single responsibility. This feature allows users in a shared services environment to access/transact data within
several operating units from a single responsibility at the same time restricting access to other users through a security
policy. This allows flexibility and convenience for shared service users. At same time you can prevent access to data
from users who are not authorized to access this information. Before Release 12, users were limited to access
information only from within the context of their own operating unit from a single responsibility.
2. How it works
The feature uses Security Profile concept introduced in Release 11i Oracle Human Resources Management System
(Please refer Page 1-22 Oracle Human Resources Management Systems Configuring, Reporting, and System
Administration Guide Release 11i Part No. A95418-02), which allows system administrator to predefine the scope of
access privilege as a profile option. A security profile may be defined, which may consist one or more Operating Units.
The profile option, MO: Security Profile, is used to associate predefined security profile to a user responsibility. This
ensures secured access to the user through profile MO: Security Profile to Operating units defined in the Security
Profile.
2.1 How it works in 10.7-11.5.x
Multiple Organization Architecture had data security by Operating Unit. A Column ORG_ID was added in Release 10.7 to
each base table that was available for access by all Operating Units. All these tables were renamed with suffix, '_ALL',
and their corresponding secured views are created in APPS schema.
Multi-Org views restrict data access by filtering records for a single Operating Unit set by application responsibility level
profile, MO: Operating Unit. The value for the profile option is cached in Application Context, and is initialized whenever
FND initialization routine is called. CLIENT_INFO function retrieves ORG_ID value stored in the application context. The
value is valid during a session.
2.2 What is different in 12.x
In release 12 Multi-Org Access Control Virtual Private Database (VPD) feature introduced will replace usage of
CLIENT_INFO(Org Context) function in Multi-Org Architecture.

3. Setups Required
- Add the following form functions to Purchasing Menu (for eg. PURCHASING_SUPER_USER)
i. Define Organizations
ii. Define Global Security Profile
- Add the Security List Maintenance Program to the Request Group attached to Purchasing Responsibility
- Define Operating Units (Optional)
- Define Security Profile by Navigating HR Responsibility->Security->Profile and following: (Please view the attachment
for details)
i. Enter a unique name for the security profile.
7/31/2014 Document 397362.1
https://support.oracle.com/epmos/faces/DocContentDisplay?_adf.ctrl-state=1408lwc1mt_206&id=397362.1 3/7
ii. To restrict access by discrete list of organizations, select Secure organizations by organization hierarchy and/or
organization list for the Security Type.
iii. Check the Exclude Business Group check box to remove the business group in the list of organizations.
iv. Use the Classification field to limit the LOV in the Organization Name field. For example, if you select the
Classification to Operating Unit, only Operating Units would display for the list of values (LOV) in the 'Organization
Name' field.
v. In the organization name field, select the Operating Unit for which you want access. Repeat this step until you have
included all organizations that you need access.
- Run the "Security List Maintenance Program" from the standard request submission form. The "Security List
Maintenance Program" could be preferably run for one named security profile to prevent disturbing other security
profile setup.
- Assign MO: Security Profile
i. Choose System Administrator Responsibility
ii. Open System Profile Options
iii. Assign the security profile to MO: Security Profile profile option for your responsibility or user.
- Assign MO: Default Operating Unit (Optional)
i. Choose System Administrator Responsibility
ii. Open System Profile Options
iii. Assign the default Operating unit to MO: Default Operating Unit profile option for your responsibility or user.
- Assign MO: Operating Unit(Mandatory for only Single Org or if MO: Security Profile is not defined)
i. Choose System Administrator Responsibility
ii. Open System Profile Options
iii. Assign the Operating unit to MO: Operating Unit profile option for your responsibility or user.
4. Impact of MOAC to Oracle Purchasing
a. All transaction entry forms which needed Operating Unit context in Purchasing will have a new Operating Unit LOV
field that is required. This will show a list of all operating units the user has access to in the security profile. The user
must choose a value for this field before navigating to any other field/block in the form. For eg. Autocreate form the
Operating Unit LOV is required.
b. All View Only forms in Purchasing will have a new Operating Unit LOV field that is optional. This will show a list of all
operating units the user has access to in the security profile. If the operating unit field is empty, all OU sensitive LOV
fields will expand to query across all operating units in the security profile and LOV window will display Operating Unit
column for fields that can have the same value in more than one operating unit (for eg. PO Number).
c. Field Operating unit has been added new folder field in View Only forms that can be used to view details from
multiple operating units.
d. A new field called Operating Unit is included in the Standard SRS screen. For every Purchasing report or concurrent
request users will be required to select an operating unit as a parameter. This is not the same case for Receiving
Reports where Operating Unit need not be supplied.
Following are the list Purchasing and Receiving reports that require Operating Unit as mandatory Input. Output will
have the Operating Unit name printed.
Buyer Listing
Contract Status Report
Item Detail Listing
Financials/Purchasing Options Listing
Savings Analysis Report(by Category)
7/31/2014 Document 397362.1
https://support.oracle.com/epmos/faces/DocContentDisplay?_adf.ctrl-state=1408lwc1mt_206&id=397362.1 4/7
Savings Analysis Report(by Buyer)
Standard Notes Listing
Purchase Agreement Audit Report
Purchase Order and Releases Detail Report
Cancelled Purchase Orders Report
Purchase Order Commitment By Period Report
Encumbrance Detail Report
Open Purchase Orders Report(by Buyer)
Open Purchase Orders Report(by Cost Center)
Matching Holds Report by Buyer Report
Purchase Order Detail Report
Vendor Price Performance Analysis Report
Quotation Action Required Report
Vendor Quality Performance Analysis Report
Invoice Price Variance By Vendor Report
Invoice Price Variance Report
Purchase Price Variance Report
Requisition Import Exceptions Report
RFQ Action Required Report
Backordered Internal Requisitions Report
Buyer's Requisition Action Required Report
Vendor Service Performance Analysis Report
Purchase Summary Report By Category
Item Summary Listing
Location Listing
Quality Code Listing
Unit of Measure Class Listing
Unit of Measure Listing
New Vendor Letter Report
Vendors on Hold Report
Vendor Affiliated Structure Listing
Blanket and Planned PO Status Report
Purchasing Activity Register
Printed Change Orders Report (Portrait)
Printed Change Orders Report (Landscape)
Purchase Order Distribution Detail Report
Printed Purchase Order Report(Landscape)
Printed Purchase Order Report(Portrait)
PO Output for Communication
Purchase Summary Report By Category
Printed RFQ Report(Landscape)
Printed RFQ Report(Portrait)
Printed Requisitions Report
Requisition Activity Register
Cancelled Requisition Report
Requisition Distribution Detail Report
ReqExpress Templates Listing
Purchase Requisition Status Report
Internal Requisitions/Deliveries Discrepancy Report
Internal Requisition Status Report
Buyer's Requisition Action Required Report
Receiving Account Distribution Report
Receiving Transactions Register
Overshipments Report
Receiving Exceptions Report
Substitute Receipts Report
Receipt Adjustments Report
7/31/2014 Document 397362.1
https://support.oracle.com/epmos/faces/DocContentDisplay?_adf.ctrl-state=1408lwc1mt_206&id=397362.1 5/7
Substitute Receipts Report
Expected Receipts Report
Unordered Receipts Report
Uninvoiced Receipts Report
Following are the list Purchasing and Receiving concurrent requests that require Operating Unit as mandatory Input.
Output will have the Operating Unit name printed.
Generate Sourcing Rules and ASLs from Blanket Agreements
Define MassCancel
Requisition Import
Create Internal Orders
Run MassCancel
Create Releases
Send Notifications for Purchasing Documents
Import Standard Purchase Orders
Import Price Catalogs
Mass Update of Buyer Name on Purchasing Documents
Retroactive Price Update of Purchasing Documents Program
Reschedule Requisitions
Accrue Receipts
Receipt Accruals - Period-End
Advanced Shipment Notice Discrepant Receipts
Pay On Receipt AutoInvoice
e. This in effect helps in creating Receipts/ASNs/ASBNs for purchase orders in another operating unit(Procuring Org)
destined for Receiving Org's Ship-To Organization through the same Responsibility.
f. Also Sourcing Documents can be created or viewed for all the Operating Units included in the buyers Security Profile.
g. All Purchase Order APIs have been added with a parameter org_id which can be populated with the org_id for which
the API needs to be called.

5. Implementation Considerations
1. Please remember that Responsibility-level profile options will apply to all OUs in the security profile.
2. In Release 12, when the profile option 'HR:Cross Business Group' is No, all employee LOVs will be restricted to the
business group defined in the 'HR:Business Group' profile option regardless of the OU context. This could be an
implementation problem if a single responsibility has access to OUs that roll up to multiple business groups.
3. If the profile option 'MO: Security Profile' is set and gives access to multiple Operating Units, then the profile value
'MO: Default Operating Unit' if set is validated against the list of Operating Units in 'MO: Security Profile'. If the
Operating Unit is included in the security profile then it is returned as the default value. Otherwise there is no Operating
Unit default. Also, if the Profile Option 'MO: Default Operating Unit' is not set, then there is no default Operating Unit.
4. If the profile option 'MO: Security Profile' is set and gives access to one Operating Unit, the default Operating Unit
will return this value even if 'MO: Default Operating Unit' is set to a different value.
5. If the profile option 'MO: Security Profile' is not set, then 'MO: Operating Unit' value is used as the default Operating
Unit even if 'MO: Default Operating Unit' profile is set to a different value.
6. The profile option 'HR: Security Profile' takes precedence over 'MO: Security Profile'.
7. If an organization has been defined both as a business group as well as an operating unit, it would appear in the
7/31/2014 Document 397362.1
https://support.oracle.com/epmos/faces/DocContentDisplay?_adf.ctrl-state=1408lwc1mt_206&id=397362.1 6/7
LOV for available operating unit only if 'Exclude Business Group' option in the security profile is unchecked.
6. Customizations
Virtual Private Database (VPD) feature introduced will replace usage of CLIENT_INFO(Org Context) function in Multi-Org
Architecture. All calls made to previous org context function will not work any longer. All such views/synonyms will
need to be accessed only through security profile.
For eg. previously following script could be run for accessing information in po_headers view.
begin
dbms_application_info.set_client_info('&org_id');
end;
/
select * from po_headers
/
But in R12 the above will not work unless we request access through security policy in the database.
MO_GLOBAL public api's are available to obtain this access. This applies with workflow packages as well. Please refer
Note 415860.1 for further details.
Also custom forms and reports need to be initialized to secure access through security profile.
In your design you need to consider future possibility of the customizations and extensions being used in a shared
services environment. This will mean additional task for eg. addition of Operating Unit filed to your LOVs or joining your
queries explicitly with org_id when tables or views have Operating Unit sensitive data.
Please refer to Note 420787.1 for further information on means to create/modify your custom code in R12.

7. Troubleshooting
Please use the following instructions to troubleshoot your issues due to implementation of MOAC in Oracle Purchasing.
i. Incase the Operating Unit LOV does not reflect the changes made by adding/removing Operating Units from the
corresponding security profile of the user, please run the Security List Maintenance Concurrent Program for the
corresponding Business Group and review the log file of this program. If you see errors in the program please review it
and correct your setups accordingly.
ii. Incase a transaction has been created in the wrong operating unit, you need to delete/cancel the transactions.
Datafix will not be considered as long as these transactions could be reversed through application without major
business impact.
iii. Please review documentation Oracle Human Resources Management Systems Configuring, Reporting, and System
Administration Guide to enable audit trails. Incase of any security issues due to the setups please review the audit
reports.
iv. While logging a service Request with Oracle Support for MOAC issues in Purchasing please provide the above
information which you have reviewed and also the version of the following files.
Files Directory
AFMOGBLS.pls $FND_TOP/patch/115/sql
POXCOSEU.plx $PO_TOP/resource
POXVMOUS.pls $PO_TOP/patch/115/sql
POXVMOUB.pls $PO_TOP/patch/115/sql
7/31/2014 Document 397362.1
https://support.oracle.com/epmos/faces/DocContentDisplay?_adf.ctrl-state=1408lwc1mt_206&id=397362.1 7/7
REFERENCES
NOTE:415860.1 - How to query in SQL for org-specific data in a MOAC environment
NOTE:420787.1 - Oracle Applications Multiple Organizations Access Control for Custom Code