Document 397362.

Page 1 of 9

(sanjiv.x.gupta@oracle.com) Favorites Profile Contact Us Help Site Map Sign

Home Knowledge Configs and Projects Certifications Patches and Updates Service Request

Browse
Search By

| Subscriptions | Authoring Wizard | Documents In Progress | Query By Attribute

Keyword ID

397362.1

Filter

Oracle Products

Advanced Recent Recent Search Documents Searches

Knowledge > Browse > Advanced Search > Search Results > Document Display

Multi Org Access Control (MOAC) in Oracle Purchasing (Doc ID 397362.1)

Modified 25-SEP-2008 Type BULLETIN

Next Steps

In this Document

Purpose Scope and Application Multi Org Access Control (MOAC) in Oracle Purchasing 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

Add Comment View Document Statistics Help Us Help You Rate this document Excellent Good Poor Did this resolve the problem? Yes

@ (AuthWiz 2.5.4)

No Just Browsing Was this easily located? Very Easy Somewhat Easy Not Easy

Applies to:
Oracle Purchasing - Version: 12.0.0 to 12.0.1 Oracle Inventory Management - Version: 12.0.0 to 12.0.1 Information in this document applies to any platform.

Purpose
This article will discuss the features specific to uptake of Multi Org Access Control (MOAC) in Oracle Purchasing.

https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=397362.1&h=Y

6/1/2010

Document 397362.1

Page 2 of 9

Scope and Application

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.

Multi Org Access Control (MOAC) in Oracle Purchasing

Agenda

1. 2. 3. 4. 5. 6. 7.

Overview How it works Setups Required Impact of MOAC to Oracle Purchasing Implementation Considerations Customizations 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.

https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=397362.1&h=Y

6/1/2010

Document 397362.1

Page 3 of 9

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 (Please view the attachment for details) i. Enter a unique name for the security profile. 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 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.

https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=397362.1&h=Y

6/1/2010

Document 397362.1

Page 4 of 9

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

https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=397362.1&h=Y

6/1/2010

Document 397362.1

Page 5 of 9

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

https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=397362.1&h=Y

6/1/2010

Document 397362.1

Page 6 of 9

Substitute Receipts Report Receipt Adjustments Report 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.

https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=397362.1&h=Y

6/1/2010

Document 397362.1

Page 7 of 9

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

https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=397362.1&h=Y

6/1/2010

Document 397362.1

Page 8 of 9

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

References
NOTE:415860.1 - How to view org-specific data in a MOAC environment NOTE:420787.1 - Oracle Applications Multiple Organizations Access Control for Custom Code

Attachments R12 Moac (1.21 MB) Related Products Oracle E-Business Suite > Procurement > Procurement > Oracle Purchasing > Setups > Others Oracle E-Business Suite > Logistics > Logistics > Oracle Inventory Management > Receiving Functions > Receiving Options Knowledge Categories EBS > Mfg > Procurement > PurchaseOrders > OTHER-Other issues (Primary) Keywords

https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=397362.1&h=Y

6/1/2010

Document 397362.1

Page 9 of 9

AFMOGBLS.PLS SECURITY LIST MAINTENANCE MULTI-ORG DBMS_APPLICATION_INFO.SET_CLIENT_INFO Document Attributes Author Owner Alias Visibility Created By Modified By Reviewer Source Comments Comment Please link to Note 420787.1 as well typos Type Status Priority From To Modified By VJOSEPH.IN VJOSEPH.IN EXTERNAL VJOSEPH.IN VJOSEPH.IN IMPORT.US AWIZ Status Publisher Content Type Priority Created Date Modified Review Date PUBLISHED(EXTERNAL) starr.smelley@oracle.com TEXT/X-HTML 2 01-NOV-2006 25-SEP-2008

IMPLEMENTED 3 IMPLEMENTED 2

chandu.tadanki@oracle.com OWNER karen.jones@oracle.com OWNER

Favorites Profile Contact Us Help Sign Out

Copyright (c) 2008, Oracle Corporation. All Rights Reserved. Legal Notices and Terms of Use | Privacy Statement

https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=397362.1&h=Y

6/1/2010