The Feature

Confused About Setting Up MOAC in R12?

August 20, 2010 on 12:48 pm | by Marian Crkon | In Feature of the Week | Enter Comments |  Print |  Email

Don’t despair, you are not alone. This feature applies to Oracle EBS R12. If you are implementing, or upgrading to R12, you’ve probably already heard of the new Multi-Org Access Control (MOAC) functionality. In fact, it is one of our main talking points, when we solicit new R12 projects…

Multiple Organizations feature (MOAC) provides security profiles which enable users to access, process, and report data in multiple operating units from a single “global” responsibility.

Both in 11i and R12, the MO:Operating Unit profile option ties a responsibility to a single operating unit. If the MO:Operating Unit profile option is blank at the responsibility level, the MO: Default Operating Unit profile is used for all responsibilities.

In order to make responsibilities “global” and give them access to multiple operating units, you have to define the MO: Security Profile system profile option. Note that if the MO: Security Profile is set, then the MO: Operating Unit profile is ignored, (regardless of which level the options are set at).

When it get tricky is when you need to define a combination of responsibilities intended for one operating unit and responsibilities that cross multiple operating units. In this case you need to carefully design the use of both MO Operating Unit and MO Security Profile options.

And another heads up: you should probably never set the MO: Security Profile at the site level because this overrides the MO: Operating Unit setting at the responsibility level and all responsibilities have access to all operating units.

How to Add a New Operating Unit to Existing Configurations

September 5, 2007 on 1:06 pm | by Marian Crkon | In How To Guides | 20 Comments |  Print |  Email

The following steps are required to add new operating units to your existing organizational structure:

1. Revise the Organization Structure.

2. Define Sets of Books (optional).

3. Define Locations.

4. Define Organizations.

5. Define Relationships.

6. Define Responsibilities.

7. Set Profile Options for Each Responsibility linked to the new Operating Unit.

8. Run the Replicate Seed Data concurrent program.

9. Set profile options specific to operating units.

10. Define Inventory Organization Security (optional).

11. Implement the Application Products.

12. Secure Balancing Segment Values (optional).

13. Run the Setup Validation Report (recommended).

14. Implement Document Sequencing (optional).

15. Define Intercompany Relations (optional).

16. Set the top reporting level (optional).

17. Set up conflict domains (optional).

The trick with adding a new operating unit to the existing configurations was to figure out which configurations were operating unit specific. The attached three documents capture those steps for a typical installation of Oracle Projects and Financials.

• BR100 Application Configurations – Multi-Org
• BR100 Application Configurations – Financials
• BR100 Application Configurations – Projects

Another dilema we had was how many operating units to define in the same set of books. We started with the “best practice” approach to have one set of books for all operating units with the same 3 Cs (Chart of Accounts, Calendar and Currency). The challenge with this approach was how to manage some financial operations, including closing the periods, securing journals by operating unit, or defining default accounting rules. And because we needed to completely separate three legal entities, we ended up with multiple sets of books – one for operating unit. There are several improvements to the multi-organization structures in the release 12 but I will right about those after I can “put my hands on them”.