Thursday, 25 August 2011

MultiOrg in Oracle R12

You all know by now that Multi Org model in Oracle Release 12 will be changing. They call it Multi Org Access Control. I would like to explain to you the reasons behind this change, and how this will impact you. I will also explain to you how this will not impact you at all [if you don't wish to use MOAC- Multi Org Access Control]
For those that are not familiar with pre-Release12 multiorg model, you must read Link Oracle R12 Multi Org Basics.That link explains how the current multi-org model feature works, i.e. prior to Release 12.

Credits Reference Link : Whitepaper on User Group Site
Please reference this link for the screenshots of Multi Org Access Control in R12

Business Reason for this change
Four years ago, I was tasked to design a Payables Invoice scanning process that had following requirements:-
1. My client had 100s of legal entities and organization units.
2. They wanted to receive all paper payables invoices at a central location. Effectively, they would have a single Address where invoices for all the Legal Entities/Operating Units were received.
3. All the invoices would be scanned at that central location.
4. The scanned images were then placed in a queue that were  then keyed(typed) into the system by Bangalore Team(their shared service

Here lies the issue:-
Scanned Invoices had ţo be first sorted per operating unit.
Why? Because, there was a different "Payables Clerk" responsibility for each operating unit. The poor clerk had to switch responsibility depending upon which operating unit the invoice was being entered against. Also it will never be possible to force all your suppliers to post their invoices to XML Gateway. Hence clerk had to ensure that each paper invoice is coded/entered into the right organization/operating unit.

How does Oracle Release 12 come to the rescue here?
In R12, the clerk will no longer be a "poor clerk", because they will no longer need to keep changing the responsibility for different legal entities. Here lies the strength in the design of Oracle Release12, it caters to the need of Shared Service solution.

Does this mean the payables clerk responsibility will have access to all the operating units?
This is possible now in R12 if that's what your business needs. You can assign a node of organization hierarchy or a list of operating units to your responsibility. Effectively, you are now able to assign multiple operating units to a single responsibility. This is made possible either through Organization Hierarchy or by an Organization List.

This sounds very much like HR Security Profiles as we saw in link
Oracle HRMS Security Profiles ?
True, in fact Oracle Release12 multi-org model uses Security profiles (so I am told). Read this linked article above to get your concepts on HRMS security profile clear.

Does this mean, a security profile will be attached to responsibility as profile option?


What if I don't wish to implement this enhanced feature? Will this break my existing multi org setup?

Oracle is great when it comes to upgrades. Unless you implement security profile feature, your multi-org will keep working as pre R12.

Will R12 multi-org access control still populate org_Id column?

Of course. Each record will still remain tied to an individual org.

Can we re-use security profiles that we defined for HRMS?
I suggest you keep MultiOrg security profile separate from HRMS security profile, as HR security profiles also cater for positions and various other hr related attributes. We will know this once MultiOrg Access Control gets launched.

Coming back to payables clerk, while keying in the invoice, how will they attach specific invoice they key that invoice against a specific
operating unit?
By entering value in the operating unit field in the screen. Prior to Release12, this was a hidden column. But now all screens that use security profile multi-org will have an enter-able field.

Oh dear, an additional field to be entered by the user in R12?
Not really, if you wish, you can specify default operating unit per responsibility. This too by means of a profile option.
Name of profile option is [i don't know yet], but it exists, so I am told.

So, we have two new profile options?

Indeed, one for attaching security profile and other for default org.

What happens to dbms_client_info.set_client_info(101)?
This will become redundant functionally. Use mo_global package instead. This package already exists in 11.5.10 instance. And if you open this, you will find this using Row Level Security. Technically I think dbms_client_info.set_client_info will still work, but will produce unexpected results if you have enabled the MultiOrg Security Profile feature too  .

How does this effect my customizations?
Statement 1 :- If you have hard-coded client-info command, then obviously that will no longer work[with disclaimers, but I think so will be the case]
Statement 2 :- Also, if you have been using fnd_profile.org_Id, that again will not work.
Both statements above are false if you decide not to implement Multi Org Access Control feature in Release 12.

No comments:

Post a Comment