Batch Element Entry (BEE) enables payroll to enter batches of element entries, validate that the entries are correct and then transfer the entries to the employee’s element entries.

Batch Element Entry also provides the following functionality:

* Batch Header identifies the batch and determines what happens if any of the batch lines duplicate existing element  entries.

*  Batch Lines enable payroll to create batches by Element with the relevant Input Values for processing in payroll.  Defaults can be initiated for faster data entry.

*  BEE provides the ability to validate batches prior to submitting.  
    This feature enables payroll to identify incorrect employee assignment numbers, elements that are not eligible for
    employees, etc.

*  Provides the ability to use Control Totals to help validate the batch.

*  Messages that indicate if batches are out of balance with control totals, in valid employee assignment numbers, etc.

*  BEE Spreadsheet Interface - Enables the loading of payroll data from various sources into BEE using the delivered BEE Spreadsheet Interface tool. 

*  BEE API -   PAY_BATCH_ELEMENT_ENTRY_API.CREATE_BATCH_HEADER for Header

                    PAY_BATCH_ELEMENT_ENTRY_API.CREATE_BATCH_LINE for Element Line Data

 

The BEE could be implemented with the help of following approaches:

1. Programmatically populating the header records and the line records in the BEE tables based on the data file available.
2. Entering input values and other data for one element, and running a concurrent process to create identical batch lines for all the assignments in an assignment set.
3. Creating an element set and making entries for each element in the set, one assignment at a time.
   
4. Selecting an element and creating or updating lines for this element using defaults to speed entry, and changing defaults as necessary when working through the batch.

 

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.