Multi-Org Access Control allows companies that operate shared service centers or those that have centralized their

accounting and administration functions to more efficiently process business transactions. For example, say you operate in multiple countries, and your headquarters provides some or all accounting services to the other subsidiaries. You may not have implemented a formal shared service center, but you can still reap the benefits from Multi-Org Access Control. MOAC allows companies to gain processing efficiencies because users can more easily access, process, and report on data across multiple operating units from a single responsibility without compromising data security or system performance. The new and changed features for Multi-Org Access Control include: Multi-Org or multiple organization access which is basically the ability to access multiple operating units from a single application responsibility. Multi-Org Preferences allows the user to control and limit the number of operating units they have access to based on their work environment. Cross organization reporting has been enhanced to be more consistent with the new Multi-Org Access Control. Users can run reports across multiple operating units that belong to the users security profile that share the same ledger. Users can also run reports for any operating unit that belongs to the users security profile.

Before I get into the details of MultiOrg Access Control, I want to talk a little but about how the Multi-Org functionality worked in In Release 11i. In 11i, when a user had to enter or process data for multiple operating units, he or she had to login to different responsibilities because each responsibility could only access one operating unit. So if you had a centralized payment processing center where a single user processed payments for multiple organizations, he would have to keep logging in and out of different responsibilities to process payments for a different organization or operating unit. Now in Release 12, Multi-Org Access Control enables companies that have

implemented a Shared Services operating model to efficiently process business transactions by allowing users 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. Data security and access privileges are still maintained using security profiles that will now support multiple operating units.

In 11i, if you had three operating units in the center you were managing, such as a Belgium Operating Unit, a Holland Operating Unit, and a Denmark operating unit, you needed to define three different responsibilities. If you had one user who processed payables invoices across all three operating units, then you would need to assign the three responsibilities to that user and then the user would need to log in and out of each responsibility to process invoices. Thats really inefficient. In Release 12, you can create a Security Profile and assign as many operating units as you want to that security profile. So in this example, you could assign all three operating units to a security profile. Then, you 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. Processing payables invoices is just one example, with Multi-Org Access Control, you can efficiently perform other processes, such as processing receivables invoices, viewing consolidated requisitions, performing collections using Advanced Collections, and process receiving and drop shipments.

The benefits should be obvious. Youre going to improve processing efficiency because it takes time to switch in and out of different responsibilities. As more and more companies move to shared service centers, their users will be able to process data and transactions faster for multiple operating units. It also provides better information for decision making. A lot of info. in the E-Business Suite is striped by operating unit. For example, Customer account sites and supplier sites are striped by operating unit. Some products that have up taken MOAC, have given users the ability to view all of that info. across different OUs. So if your security profile had access to three operating units, you will be able to view all of the supplier sites across all three operating units. By viewing data from multiple operating units from a single responsibility, users have more information which enables them to make better decisions. For example, in Oracle Purchasing, users can now view global consolidated requisition demands for each supplier. With this view, users are armed with the information to negotiate purchase discounts. Youre ultimately going to reduce costs because users will be able to enter data across operating units more quickly faster and you will not have the overhead of setting up and maintaining tons of responsibilities.

he setup and processing is fairly similar to 11i. In Release 12, when you define your security profile in HR using the Security profile form or the Global Security profile form, you just need to assign all of the operating units that you would want a responsibility to access. Then you need to run a concurrent request called Run Security List Maintenance from HR which will make those security profile available and allow you to assign them to a responsibility via a profile option called MO: Security Profile. In terms of processing, things operate basically the same way as in 11i. Each product team has implemented MOAC to best suit their business process flows. For example, in AP, theres a new operating unit field on their Invoice Workbench. The OU list of values will read from the Security Profile assigned to the responsibility to determine which OUs should be displayed in the LOV. In general, when a user logs in to a responsibility and opens an application, the application will determine which operating units can be accessed and used for processing. The user can then view or process transactions for multiple operating units. Please see individual product TOIs to see how processes have been enhanced for multi-org access.

Let me show you some screen shots. Navigation: Accounting Setup Manager = Financials : Accounting Setup : Accounting Setup Manager Oracle HRMS Organization Form = Work Structures : Organization : Description In Release 12, you can define your operating units in two places. You can continue to define them in the Oracle HRMS Organization Form or you can define them in the new Accounting Setup Manager feature in General Ledger. For more information about Accounting Setup Manager, please see the General Ledger Transfer of Information. The Accounting Setup Manager streamlines the setup and implementation of Oracle Financial Applications. It centralizes the setup and maintenance of common financial components, such as legal entities, operating units, and ledgers. So, here when you create an accounting setup, assign a legal entity and create the ledgers that will perform the accounting for that legal entity, you can also define and assign the relevant operating units. By leveraging Accounting Setup Manager to define your OUs, you can streamline your setup. The small change we made in R12, is instead of attaching an OU to a LE, you assign it to a default legal context. Please see the Legal Entity Configurator TOI for more information on that. All Release 11i HR Organizations classified as Operating Units will be preserved in Release 12. If operating units are assigned to a set of books, then they will be associated to a primary ledger in an accounting setup. You will be able view all operating units assigned to an upgraded primary ledger using Accounting Setup Manager.

Navigation: HR Responsibility Processes and Reports : Submit Processes and Reports When youre done with setting up your security profile, you open the Submit Request window and run the Security List Maintenance program. And this will ensure that all of your security profiles that you created will be available for assignment to your responsibilities. This is an important step to do, otherwise you will not see your security profile in the list of values when you try to assign to the MO: Security Profile profile option. So make sure you run this program and make sure it completes successfully. In the next setup step, when you set your system profile options, you will see that your newly created security profiles will be available.

Here, we have the list of profile options related to Multiple Organizations or MO for short in Release 12. The first two are new. Actually they both existed in 11i, but they didnt do anything. Now in Release 12, the MO Security Profile controls the list of operating units that a responsibility or user can access. So you would assign the Security Profile that you just created to this profile option. The second profile option called MO: Default Operating Unit is optional and allows you to specify a default operating unit that will be the default when you open different subledger application pages. Because users can access multiple operating units, you may want to set up a default one instead of forcing users to constantly have to choose one. When we talk about the User Preferences later, you can also specify a default operating unit at the user level. The last profile option is really for backwards compatibility and to support products that do not use Multiple Organizations. Whatever your Release 11i setting was for this will be preserved during upgrade. That leads me to my next point. If youre happy with how you processed transactions in 11i, then when you upgrade to R12, you dont have to do anything. You only need to define a security profile and assign it to the first profile option if you want to take advantage of this exciting feature. If you specify a security profile for the MO: Security Profile, then those products that use Multiple Organizations will ignore the MO: Operating Unit profile option. If you set the security profile at the responsibility level, then all users using that responsibility will have access to only the operating units available in the security profile. If you set the security profile at the user level, then the user will have access to only those operating units, irrespective of application responsibility that they log into. Use the MO: Default Operating Unit profile option to set the operating unit context or default operating unit when accessing an applications. The Release 11i MO: Operating Unit profile option will continue to be supported in Release 12 as not all customers or Oracle products require multiple organizations.

So you can define operating units using the HRMS organization form or you can define them in the new Accounting Setup Manager while you define other common financial components, such as legal entities, and ledgers. Then you use HRMS to define your Security Profile and run the concurrent program. You can also use Accounting Setup Manager to define operating units while you define other common financial components, such as legal entities, and ledgers. From Accounting Setup Manager, you can view all operating units assigned to a primary ledger. Multi-Org Access Control integrates with all E-Business Suite products that use operating units.

Here are just some examples of products that leverage Multi-Org Access Control. This is not a complete list. This will probably make more sense when you go through different products TOIs to learn more about how they implemented Multi-Org Access Control. In summary, for Payables, they allow you to enter invoices for different operating units from their Invoice Workbench. Theres a new operating unit field, which happened to be the first field you specify when entering an invoice. It does not mean that you can enter an invoice with invoice lines that cross operating units. An invoice is still for one operating unit, but you can select different operating units without having to change responsibilities. In Receivables, there are some new cross-organization reports. So when you run a report, it will run the report for all the operating units you have access to based on your security profile. In Purchasing, you will be able to view consolidated requisition demands that cross OUs. In Collections you can manage customers and accounts across OUs. As I mentioned earlier, you can define operating units and assign them to a primary ledger using the new Accounting Setup Manager feature. So when you create your legal entities and ledgers, you can create your operating units at the same time.

In summary, you access, process, and report on data across multiple operating units from a single responsibility without compromising data security or system performance. This will help increase the effectiveness of companies who operate shared service centers as well as companies who may not have a formal share service center but do have centralized accounting or business functions

Multi-Org Preferences really allows the user to control the list of operating units they have access to. So the system administrator may create a security profile that has 10 operating units assigned and assign it to the user or his/her responsibility. But, lets say that a user only deals with 5 of them on a

daily basis and he doesnt want his work space cluttered with extraneous operating units. The user could set up Multi-Org preferences to restrict the list of OUs. And because the user has complete control over this, he can change it at anytime. In addition, the user can specify a default operating unit. Of course, this default operating unit will override the Default Operating Unit profile option.

Navigation: HR Responsibility Security : Profile or Security : Global Now, Im going to explain how to define a security profile. Using Oracle HRMS, you can define your security profile using two forms: The Security Profile form or the Global Security Profile form that is shown here. Both forms look almost identical. The Security Profile Form allows you to select operating units from only one Business Group. The Global Security profile Form allows you to select operating units from multiple Business Groups. So the Global Security profile allows you to operate across Business Groups. The decision on which form to use is really up to you and depends on your HR implementation and how you want to partition data. All you need to do is enter a name, and select the Security Type called Secure organizations by organization hierarchy and/or organization list. This allows you to assign multiple OUs. When assigning operating units, first select classification Operating Unit, and then select the organization or Operating Unit name. You can assign as many operating units as you want.

Most products have added the Preferences user interface to their responsibility menus. But if you dont see it, you can certainly add that function to your menus. For the user setup, you can select

preferred operating units which would represent a subset of operating units assigned to their security profile. And the user can set a default operating unit. The processing of transactions will be exactly the same if the user never specified user preferences.

System Administrator > Application > Menu Application Developer > Application > Menu To enable and display Preferences in your menu, request your System Administrator to add the function, FNDMOPREFS to your menu definition. The System Administrator should use either the System Administrator or Application Developer responsibility and select the Menu (Application) option. Select your products menu and add the function named User Preferences (FNDMOPREFS). This screenshot is an example using the Oracle Payables setup menu.

This is the Multi-Org Preferences page. This is new. At the header level, you will see the user name that the user is logged in as, the responsibility name, and the Security Profile that you are currently assigned to as defined by the MO: Security Profile profile option. The Default Operating Unit region is where you select a default OU. The List of values will display all operating units assigned to your security profile. The next region called Preferred Operating Units is where you select the subset of operating units you want to work with.

Enhanced Multi-Org reporting is not the same as cross-organization reports that allows you to run a report at the ledger level to obtain results for all operating units assigned to that ledger or obtain results for all the operating units for a GRE/LE. What Im discussing here is Multi-Org Reporting which allows you to select any operating unit you have access to when submitting a report. So its in line with Multi-Org Access Control. Basically all this is allowing you to report on data for multiple operating units from a single application responsibility.

So in a nut shell, you can run subledger reports for multiple operating units without changing responsibilities.

you can run subledger reports for multiple operating units without changing responsibilities.