Questions

Q1: Multi-Org Access Control (MOAC)

1. Multi-Org Access Control, or MOAC, enables users to access multiple operating units from a single application responsibility.
2. Operating unit security will be preserved such that companies can effectively implement security and shared services at the same time.
3. Enhanced Multi-Org Reporting provides the ability to process and report critical financial information at different levels of the enterprise.

Prior to Release 12, each responsibility could access only one operating unit.  Therefore, users who had to manage multiple operating units had to log in and log out of multiple responsibilities to perform their tasks. In Release 12, users can perform tasks for multiple operating units without changing responsibilities and its achieved by setting up MO: Security profile.
Usage Example:
In 11i, If a company had three operating units Belgium, Holland, and Denmark, the company would have to create three responsibilities, one for each operating unit.  And users, who had to enter invoices into all 3 operating units, had to log into each one of the EMEA responsibilities separately. 
With Multi-Org Access Control in R12, each application responsibility can access multiple operating units. The company can create a single EMEA responsibility for all three operating units and users would only have to log in once to perform tasks such as: entering payables invoices, viewing consolidated requisitions, performing collections, and processing receiving and drop shipments.
It is required to set up either the MO: Operating Unit or MO: Security Profile profile option for each application responsibility to use Multiple Organizations context sensitive applications. If the MO: Security Profile is set, then the MO: Operating Unit profile is ignored.
Data security is maintained using security profiles that are defined for a list of operating units and determine the data access privileges for a user When drilling down on balances from Oracle General Ledger, General Ledger ignores the operating unit profile setting to allow you to drill down to your subledger details, regardless of which operating unit originated the transaction.
The OU field visible for all relevant transactions and relevant setups.  On data entry, the system will derive the OU, when possible.  E.g. if user enters a PO default invoice, the supplier site determines OU.
Setups

1. Create Security Profile
2. Run Security List Maintenance program
3. Setup profile option MO: Security Profile
4. Setup profile option MO: Default Operating Unit

Note: If a responsibility has to access only one operating unit, then set the profile option - MO: Operating Unit. If a responsibility has to access multiple operating units, then define a security profile with multiple operating units assigned and assign it to the MO: Security Profile profile option.

MOAC - What's the buzz all about?

Multi-Org or multiple organization access (MOAC) is basically the ability to access multiple operating units from a single application responsibility. In Release 11i, when one had to enter or process data for multiple operating units, one had to login to different responsibilities because each responsibility could only access one operating unit. If one was managing Payables for Sweden, Norway and Finland one needed to define three different responsibilities. In Release 12, one would create a Security Profile and assign as many operating units as you required. One can tie that security profile to a single responsibility using a profile option called MO: Security Profile. For example, you could assign the security profile to the EMEA Payables responsibility to allow that responsibility to process invoices across all three operating units.

In Release 12, define a security profile in HR using the Security profile form or the Global Security profile form, and assign all of the operating units that one would want a responsibility to access. The one needs to run a concurrent request called “Run Security List Maintenance” from HR which will make those security profile available and allow one to assign them to a responsibility via a profile option called MO: Security Profile.

One can define an operating unit using the Accounting Setup Manager in Oracle General Ledger or Organization Definition form in Oracle HRMS or Inventory. We shall discuss about Accounting Setup Manager in a future blog post. An operating unit is then attached to a default legal context (as compared to Legal Entity in Release 11i)
Define a security profile using either of the two forms: Security Profile form or the Global Security Profile Form that is shown below. Both forms look almost identical where Security Profile Form allows one to select operating units from only one Business Group where as Global Security profile Form allows one to select operating units from multiple Business Groups. One can define another profile option called MO: Default Operating Unit which is optional and allows one to specify a default operating unit that will be the default when you open different subledger application forms.

What is a Multi Org Structure?

If an enterprise or a business wants to implement multiple organizations such as multiple Ledgers (Sets of Books), or Legal Entities, or Business Groups within a single installation of Oracle Applications, then we can summarize that the enterprise is planning to implement a multi org setup.

How About a Close to Real Life Case Study?

Before we dive into this topic, let us draw a multi org structure on a whiteboard. It would help to analyze a real picture, as we pick at the concepts that go into designing a multi org structure.

The above is the organization structure for Office Smart Solutions, which is a major office supplies retailer, headquartered in Naperville, Illinois, USA. The organization operates in three countries – the US, Canada and India.
Office Smart has an organization structure with the following:

• 2 Business Groups – one in the US, which controls the organization structure in North America, and one in India
• 3 Legal Entities – one in the US, one in Canada, and one in India
• 3 Primary Ledgers – one in the US, one in Canada, and one in India
• 3 Operating Units – one in the US, one in Canada, and one in India
• 5 Inventory organizations – two in the US, one in Canada, and two in India
• Subinventories and locators exist beneath the inventory organizations, but they are not relevant for the session on multi org structures.

---

---

R12 Multi-Org Access Control (MOAC)

Release 12 came with a new feature of accessing the multiple Operating Units with the single responsibility. In R12 they call it Multi-Org Access Control (MOAC).

Multi-Org Access Control (MOAC) 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.

Features of MOAC Access multiple operating units within a single application responsibility
Perform tasks for and across multiple operating units:
1. Set-up controls, Negotiate sales agreements
2. Enter quotes, orders and returns
3. Schedule orders, Apply and Release holds
4. Run reports and concurrent programs
5. Setup Transaction Type, apply and release holds

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.

Ability to view data from multiple operating units from a single responsibility, gives users more information. This enables them to make better decisions. For example when performing scheduling actions, users can now look at orders across multiple operating units and make more informed decisions on inventory allocation.

Setup required for MOAC
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 you do not set these profiles the application will behave as it does now.

There are almost 13 profile options in OM that has been converted to System parameters.

To support Multi-Org Access Control the Operating Unit has been added as a hidden folder field in the following forms:

All of the Sales Order Form Windows like Sales Order window, Order Organizer Find window (All tabs), Order Summary, Quick Sales Order window, Quick Sales Order Organizer, Quick Order Summary, Quote window, Quote Organizer, Quote Summary, Find Customer window

All of the Sales Agreement Form Windows, these are –
The Sales Agreement window, Sales Agreement Organizer, Sales Agreement Summary

Other Form Windows including –
The Scheduling Organizer window, Pricing and Availability window, Order Import Corrections window, Open Interface Tracking window, Retro-bill Organizer window, Retro-bill Requests tab

Since operating unit is a hidden field we can made it visible (using folder tools) in both the Order Organizer Find Window and the Summary Window.

In the Find Window, if you 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) you can search for transactions across all the Operating Units that you have access to via your MO: Security Profile.

You can also restrict your 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).

Benefits1. Improve accessibility
2. Increase information for decision making
3. Reduce costs

Setup Required for MOAC
You can create global security profiles that enable users to work on organizations in multiple business groups.
You do this by setting up a global hierarchy, which can contain organizations from any business group on your database, and associating it with a global security profile. This enables you to create a security hierarchy that gives users access to organizations across business groups.

Enter and Schedule Orders Across OU's
A new Operating field has been added to all the forms that allow you to view and manage Sales Agreements, Quotes, Orders and Returns across multiple Operating Units. With R12 you can:
- Choose an Operating Unit when entering a transaction
- Query transactions across multiple Operating Units
- Perform various actions on transactions from multiple Operating Units

How to do setupGo to Responsibility > Human Resource
Navigaton > Security > Global Profile.

Create global security profiles that enable users to work on organizations in multiple business groups.

Set up the global organization hierarchy.
Setup top Organization
Define the organizations from any business group in your database, and associating it with a global security profile. This enables you to create a security hierarchy that gives users access to organizations across business groups.
Run Concurrent Request "Security List Maintenance".

Q2: Oracle EBS 11i: Define Organization structure / Oraganization Hierarchy 

Defining Organization structure is the first step in any ERP implementation and is the most critical part of any implementation. You have to carefully study and understand the companys' reporting requirements, management hierarchy, business geographies, legal requirements, data security etc while finalizing it's organization structure.

First let me define the key components of Organization structure in Oracle ERP perspective. To better explain these, lets assume assume Amazon.com is implementing Oracle financials for it's US business.

1. Set of Books
Set of book is the top level of Organization hierarchy. This defines 3 key components of a ledger. So any transaction in a ledger automatically inherits followings from set of books,

a. Chart of Accounts
b. Currency
c. Calender

To set this up for Amazon.com US business in Oracle ERP, the values for above would be,

a. Chart of Accounts: To determine how many segments would be used in Chart of Accounts depends on several factors like financial reporting requirement, financial reporting to management, what level of reporting is required etc.
Typical Oracle ERP implementation varies from 5-8 segments. Following minimum level of segments should be there in any implementation,

Company (Balancing segment)
Cost center / Department
Natural Account

Generally every Organization require above segments as part of their Chart of accounts to track financial transactions, for financical reporting purpose etc.

Other segments like followings vary upon type of businesses,

Project
Product

For Amazon.com US business lets assume we have 7 segment chart of accounts with 2 segments for future usages.

b. Currency: This is the functional currency of the country in which you are doing business. For Amazon.com US business, this would be USD.

c. Calender: This is the financial calender that company wants to follow. Most of the US companies have financial calender as JAN to DEC but it is not mendatory to have JAN to DEC. Some companies like CISCO has financial period from AUG to JUL. So, based on company's requirement and business practice setup Calender.

Basically these three components make up a Set of book in Oracle. If anyone changes then you have to create a new Set of book. For our e.g., if Amazon.com starts business in UK then a new set of book needs to be created for UK currency (Generally Chart of accounts and calender remains same for any company across different countries).

Set of books is not for outside reporting. This is the Oracle way of handling financial transactions (GL Journal entries) and securing data within Oracle ERP. Set of books is defined in Oracle General Ledger module. A set of book can have multiple Legal entities / Operating units.

2. Legal Entity

Legal entity is the next level in Oraganization hierarchy and this is what is visible to outside world. For our e.g., if Amazon.com US business has been registered with AMAZON.COM LLC then the legal entity name for Amazon.com's US business would be "AMAZON.COM LLC". Note that the name is case sensitive and must match with the company registered name. All legal / financial reporting for a company happens by Legal entity name. Any financial deals (like Purchase orders, Sales Orders, Employement etc) in a company happens by Legal entity name.

Oracle classifies an Organization as Legal entity by "GRE/Legal entity". Organization is defined in Oracle Purchasing Module. A legal entity can have 1 and only 1 set of books but can have 1 or many operating units.

3. Operating Unit

Next level after Legal Entity is Operating unit. This is Oracle way of securing financial data and is nothing to do with Outside world. All subledger transactions (POs, Payable Invoices, Receivable Invoices etc.) are secured by Operating units in Oracle EBS 11i. Oracle classifies an Organization as Operating unit by "Operating Unit" type. Organization is defined in Oracle Purchasing Module. An Operating unit can have 1 and only 1 Legal entity and Set of book. Until Oracle EBS 11i, subledger data is secured by assigning Operating unit to each subledger responsibilities via profile option "MO:Operating Unit".

So, these are the key components an Organization structure in Oracle perpective.

Let's see how we can define Organzation structure for our e.g. AMAZON.COM which recently acquired ZAPPOS.COM.

A> Set Of Books
To decide how many SOBs are required for AMAZON.COM's US business, lets answer following questions which would help in determing if we need multiple SOBs,

Does AMAZON.COM and ZAPPOS.COM share the same 3Cs of SOB (Calender, Currency, COA)?
I think yes. It is because we are implmenting for US where functional currency is USD. Calender would be same as AMAZON.COM acquired ZAPPOS.COM so they would share the same AMAZON.COM calender. We can keep same COA as of AMAZON.COM
So, from above analysis we do not need a new SOB for our implementation / merger.

B> Legal Entity
To decide on number of Legal entities, we need to find out how many companies are registered under AMAZON.COM
In this case as AMAZON.COM aquired ZAPPOS.COM, we definitely would have to define two legal entities if AMAZON.COM wants to continue with ZAPPOS.COM as a registered company. If AMAZON.COM decides that both would be only 1 company going forward and there would be no ZAPPOS.COM then only 1 legal entity would be enough. But generally with any acuiqisition company do not close the aquired company immediately for several reasons like brand, reporting requirements, legal reasons etc.

So, here in our e.g., we will have minimum two legal entities. If AMAZON.COM has another registered company under it's parent company then that also needs to be defined. So, the logic behind this is how many companies are registered legally for which you are obliged for financial reporting.

Both the legal entities can have the same SOB that we define in the previous step.

In real life there can be more complex hierarchy depending upon legal requirement, the way companies are registered etc.

C> Operating unit:

For our e.g. we would definitely need minimum of two operating units because we have two legal entities for which we have to do financial reporting. 1 for AMAZON.COM and 1 for ZAPPOS.COM
However we can have more than 2 operating units as well. Think about a scenario where if you want to logically divide AMAZON.COM/ZAPPOS.COM business into east coast and west coast (region wise) and want to secure data by region. Although all are part of same legal entities and share the same SOB but you want to divide by region. In that case you can achieve that by having two operating units each for AMAZON.COM and ZAPPOS.COM
I just mentioned an example. In real world however company does that at country level not on region level within a country.

So, here we saw what is an Organization structure and how we define Organization hierarchy.

---