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.

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.

Calling application send a request (to get list of approver) to the AME by means of sending Runtime data of transaction to AME API. For example, PO data to AME API 

AME execution Engine process the data. 

AME engine evaluate rules for that transaction types (rules are define in AME schema for  a transaction type).A transaction may have more than 1 rule associated with it. 

AME evaluate each rule depend on the conditions/attributes. 

Rules then execute action Type. 

AME then return calling application list of approvers(Sorted based on Setup in AME). 

(Please note when we call AME, it generate list of approvers, Identify next approver, check the status history to check if people has already approved or Not). 

Calling application receive response from AME and then send Notification to Approvers. 

PLUS calling application update the status of the Approver in AME by means of calling a AME API ( Updatestatus API). 

AME is done when approves is complete.