Oracle AME : Approval Management Engine : Questions Answers

Does Oracle HR needs to be fully installed to use AME ?

First, customers using any of the financials products but not Oracle HR also install “Shared HR,” which is a “lite” version of the HR product that includes the common entities that are needed by all applications. These include organizations, locations, jobs, positions, and people. AME will work with Shared HR. Customers do not need to apply the HR Family Pack if they do not install any of the HRMS applications. They will need to set up the people, jobs, or positions that they want to include in their approval rules.

Does AME support parallel approval ? 

In 11.5.10 only serial approval is supported.  Parallel approval is supported in R12.

Can approval rules be defined and leveraged across multiple products ? 

Yes, approval rules can be defined once and be‚ leveraged across multiple products, requiring less maintenance work. Additionally approval rules can be easily extended without having to customize the application or the workflow

How do I enable the Approval Engine for my Requisitions ?

This is done in the Setup Document Type Form in Core Purchasing. The following Approval Transaction Types are seeded and supported:

• PURCHASE_REQ = Purchase Requisition
• INTERNAL_REQ = Internal Requisition
• RCO = Requestor change order

Which Action Types does support and not support with AME integration in 11.5.10

Supported :

1. Chains of authority based on relative job level generate chains of authority by ascending the HR supervisory hierarchy until they reach a manager having a certain job level. The actions differ according to the job levels they require. Job level is based on supervisor hierarchy.
   (E.g. If Kim is the requester and is at a job level of 1; if the rule states Chains of authority based on relative job level = 3, then the approvers would be whomever had a job level of 4 (that is three levels up from Kim)).
2. Chains of authority based on absolute job level – generate chains of authority by an job level number. For example, if a Joe has a job level = 3, and Kim chooses the action type Chains of authority based on relative job level 3, then the approval would route to Joe with a Job Level = 3.
3. Chains of authority based on number of supervisory levels generate chains of authority based only on a supervisor’s position that is ‘n’ levels up from the requesting position.
4. Chains of authority containing only the final job-level approver generate chains of authority based upon the final approver in the requester’s hierarchy.
5. Chain of authority includes requestor’s manager and then the final approver generate chains of authority based on only the requester’s manager and then the final approver in the requester’s chain of authority.
6. Chain of authority includes an approval group
7. Chain of authority includes two sub-chains, each based on job level

Unsupported:

1. One job-level chain of authority per line item. An example of this is a Requisition with multiple lines and then requiring AME to find multiple approvers for each of these lines.
2. The ability to automatically find a required “pre-approver” for any given employee. An example would be like this. “Any requisition that must be approved by the CEO (top level approver), must first be approved by the CFO. However, the CFO is not in the employee supervisor chain for all of the employees submitting requisitions that must go to the CFO (for example the CIO reports directly to the CEO, however, a requisition that is approved by the CIO but still needs final approval by the CEO first must be approved by the CFO per their business rules).” In this case, the system cannot be setup to this because AME does not have the ability to add an approver into the Approval List after it has already been built, which is required in this example.

What Attributes within AME does iProcurement and Oracle Purchasing seed into the system? 

The following attributes are seeded by the iProcurement team

• Requisition total: This is the total of all requisition lines that have not been canceled. The total is in the functional currency. The conversion method is derived from the profile POR: Default Currency Conversion Rate Type value for the user. GL’s currency conversion must be enabled.
• Commodity: This value is derived by looking at the commodity associated with the item category for the requisition line.
• Natural Account: This is the segment of the accounting flex field that is specified as the Natural Account Segment. The value for this attribute is derived from the natural account segments for the charge accounts specified on the requisition line distributions.
• Cost Center: This is the segment of the accounting flex field that is specified as the Cost Center Segment. The value for this attribute is derived from the cost center segments for the charge accounts specified on the requisition line distributions.
• Item Number: This is the item number composed by concatenating all the segments defined on the Item key flex field. This value is derived from the Item number associated with the requisition line.
• Item Category: This is the item category composed by concatenating all the segments defined on the Item Category key flex field. This value is derived from the item category associated with the requisition line.
• Deliver to Location: This value is derived from the deliver-to location specified on the requisition line. Here we use the location code in database base language, because AME does not support MLS in setup forms.

What does Voting Regime mean? 

Voting Regime is region that can be setup in AME when creating an Approval Group. There are four choices available in the Voting Regime region. They are:

• Series
• Consensus
• First Responder Wins
• Order Number

All of the Rule Types Supported?

list of Rules Types are listed below with Explanation.

• List-Creation List-Creation Exception Standard creation of approval list, excluding a specified condition
  Example : Have requisitions between $0 and $1000 approved by up to at most 3 levels except in the Deliver to Location V1 New York).
• List Modification create a standard list-creation rule with some type of modification to that rule.
  Example: If two rules are required such as:
  Invoice amount > $10K go up to VP lst
• Post-List Approval-Group - This approval group will be appended to the end of the chain of authority approval list.

Can different Approval Rules be Setup in AME across different Operating Units? 

No. Approval Rules setup in AME will be used across all Operating Units. If it is necessary to not have rules work in a particular Operating Unit, there are two ways to do this:

• Turn off AME in that particular Operating Unit
• Create a rule that excludes that particular Operating Unit from the rule
• or 1) based on a attribute for operating unit and having different rule with conditions such that different rule will be applicable for different operating unit
  2) Using a dynamic group in rules: The group used returns appropriate user based on operating unit

What functional limitations exist when using AME? 

The followings features cannot be used with AME based Requisition Approval Workflow

• Notification TimeOuts with Reminders
• The Forward Documents form cannot be used with Notifications pending approval that were sent via Requisition Approval Workflow with AME
• The Notifications that are sent only have Approve and Reject response actions. Forward and Approve and Forward are not available at this time.

 

Oracle R12 : Interview Questions Answers on GL / Subledgers

1. What are the tables involved in the Transfer to GL and GL posting?

Subledger Tables
XLA_AE_HEADERS
XLA_AE_LINES
XLA_DISTRIBUTION_LINKS

Transfer Journal Entries to GL (XLAGLTRN) process takes the subledger journals and inserts records into the Interface Tables

Interface Tables
GL_INTERFACE / XLA_GLT_<groupid>

Journal Import (GLLEZL) then reads from the interface table and creates records in the GL Tables

GL Tables 
GL_JE_BATCHES
GL_JE_HEADERS
GL_JE_LINES
GL_IMPORT_REFERENCES

GL Posting process then posts to the GL_BALANCES table.

What are the different methods to transfer Subledger journals to GL?

a) ONLINE MODE
GL Transfer can be spawned during Online Accounting using the ”Final Post” option for a specific document (Example: AP Invoice and AR Transaction).

Example: Navigation in Payables: Invoices/Entry/Invoices: Action: Create Accounting/Final Post. This  spawns the GL Transfer, the Journal Import, Data Manager and the GL Posting processes. This request transfers ALL the final accounted data for that document. This method of transfer uses the interface table GL_INTERFACE to move the journals to the general ledger.

b) BATCH MODE
GL Transfer can also be spawned by the Create Accounting concurrent request when submitted with the “Transfer to GL” parameter set to Y.

Example:  Navigation in Payables: Other/Request/Run: Create Accounting
This spawns the journal import and the data manager processes. The GL Posting process is spawned if the Post to GL parameter is set to Yes when submitting the Create Accounting. This request transfers all the final accounting created by the Create Accounting request that spawned it. This method uses the interface table XLA_GLT_<groupid>.

c) CONCURRENT REQUEST
GL Transfer can be submitted in standalone mode using the concurrent request “Transfer Journal Entries to GL”.

Example: Navigation in Payables: Other/Request/Run: Transfer Journal Entries to GL
This spawns the Journal Import and the Data Manager programs. This request transfers all the final accounting that exists for the given ledger and end date. This method uses the interface table XLA_GLT_<groupid>.

What is the setup option that determines the level of detail in the accounting lines created for a specific transaction in XLA_AE_LINES?

Each Journal Line Type (JLT) can be setup as required to result in either detailed or merged lines in XLA_AE_LINES.

Navigation: Accounting Setups : Subledger Accounting Setup : Accounting Methods Builder : Journal Entry Setups
Form :”Define Journal Line Types”
Field : “Merge Matching Lines”

The different options are as follows:

1) ALL – The matching lines in XLA_DISTRIBUTION_LINKS for the specific accounting header and specific journal line type (example: LIABILITY) are merged to create records in XLA_AE_LINES.

2) DR/CR – The matching lines in XLA_DISTRIBUTION_LINKS, for the specific accounting header and specific journal line type (example: LIABILITY) with debit side entries, are merged to create one debit entry in XLA_AE_LINES. The matching lines with credit side entries are merged to create one credit side entry in XLA_AE_LINES.

3) NO – Lines in XLA_DISTRIBUTION_LINKS for the specific accounting header and specific journal
line type (example: LIABILITY) are not merged and copied into XLA_AE_LINES.

NOTE: This setup applies to merging lines within a specific transaction.

What is the setup option that determines if transfer to GL is in detail or summarised mode?

There are two variables that determine how the data is transferred to GL from the subledger tables XLA_AE_HEADERS and XLA_AE_LINES. These setups determine whether accounting data from across multiple transactions in the subledger will be merged or not merged while inserting into rows in the GL_JE_HEADERS and GL_JE_LINES tables.

a) Subledger Accounting Options

Navigation: Accounting Setups : Ledger Setup : Define : Accounting Setups
Choose the ledger
Click on “Update Accounting Options”
Scroll to Subledger Accounting Options in the Primary Ledger section
Click on Update Icon
Click on Update Icon against the Application to be setup(Example: Payables)

Field: General Ledger Journal Entry Summarization

This can be set to ONE of the following:

• Summarize by GL Period
• Summarize by GL Date
• No Summarization

This setup determines if the accounting header is summarized or not.

b) Journal Line Types

Navigation: Accounting Setups : Subledger Accounting Setup : Accounting Methods Builder : Journal
Entry Setups
Form :”Define Journal Line Types”
Field: Transfer to GL
This can be set to Summary or Detail

This setup determines if the accounting lines in XLA_AE_LINES are summarized during transfer to GL.

Note 1: Lines cannot be summarised if the headers are not summarised.
If “General Ledger Journal Entry Summarization” is set to No Summarization, the “Transfer to GL” setup in the Journal Line Types are irrelevant. The lines and headers are not summarized in this scenario.

Note 2: Irrespective of transfer in Detail or Summary, there is always a one-to-one correspondence between the XLA_AE_LINES and GL_IMPORT_REFERENCES tables.

  What are the different combinations of the two setup options that determine if transfer to GL is in summary or detail and the corresponding outcome?

GL Journal Entry Summarization	JLT -Transfer to GL	Expected behavior
Summarize(By GL Date or Period)	Summary	Summarized at both GL_JE_HEADERS and GL_JE_LINES
Summarize(By GL Date or Period)	Detail	Summarized at GL_JE_HEADERS, detail GL_JE_LINES
No Summarization	Detail	Detailed at GL_JE_HEADERS and GL_JE_LINES
No Summarization	Summary	Detailed at GL_JE_HEADERS and GL_JE_LINES

Note: The last two options cause the level of detail in the GL to be the same as in the Subledger.

What columns associate GL data back to the SLA data?

Since there is always a one-to-one correspondence between XLA_AE_LINES and GL_IMPORT_REFERENCES, they are used to link GL and the subledgers.

GL_IMPORT_REFERENCES.gl_sl_link_id => XLA_AE_LINES.gl_sl_link_id
GL_JE_BATCHES.group_id => XLA_AE_HEADERS.group_id

 

What columns indicate the Transfer Status of accounting data in subledger?

The XLA_AE_HEADERS table shows the transfer status of the accounting data, after successful transfer to the GL and Journal Import:

XLA_AE_HEADERS.gl_transfer_status_code = Y
XLA_AE_HEADERS.gl_transfer_date is not null
XLA_AE_HEADERS.group_id is not nullFor 11i data upgraded to R12, the transfer status can be determined using the followingXLA_AE_HEADERS.gl_transfer_status_code = Y
XLA_AE_HEADERS.gl_transfer_date is null
XLA_AE_HEADERS.group_id is null
XLA_AE_HEADERS.upg_batch_id is not null  –> indicates 11i data
 

Oracle R12 : Multi-Org Access Control (MOAC)

Release 12 sub-ledgers can process transactions for multiple operating units from a single responsibility (without changing responsibilities). Using Multi Org Access Control security features we can control responsibilities access to operating units in a shared services environment. These operating units can span across Business Groups.

For demo purpose let’s use vision instance, in the screen shot below you can see multiple operating units in the List of Values before setting up the security. In this demo we will setup to show only 2 operating units Vision Operations and Vision Construction in the List of Value for Payables,Vision Operations (USA) responibility.

Users need to plan the responsibilities as needed and setup security profiles.

AP Invoice Entry Screen:

To setup this access control three steps were involved:
1. Define Global Security Profile
2. Run Security List Maintenance Program
3. Assign the new security profile to MO: Security Profile
Let’s check the setup in detail:

Step 1: Define Global Security Profile
Responsibility : Human Resources
Navigation : Security–>Global Profile

Step2: Run the Security List Maintenance Program
Responsibility : Human Resources
Navigation : View–>Request–>Submit New Request

Step3: Assign the Security Profile to the MO: Security Profile
Responsibility : System Administrator
Navigation : Profile->System
Note: We use Payables, Vision Operations (USA) for this demo

Note: Check the AP Invoice Entry Screen after assigning the MO: Security Profile

Oracle Cash Management : Cash Pools

Cash pooling is a cash management technique aimed at optimizing the balances of the internal bank accounts held at one or several banks. It is usually performed on a daily basis.

To perform cash pooling, you need to define a cash pool and assign internal bank accounts to the cash pool.

A cash pool is a group of bank accounts with one or more concentration accounts and multiple sub accounts. You can create the following two types of cash pools:

• Notional Cash Pool. A cash pool consisting of one concentration account and multiple sub accounts. This type of cash pool is used for cash leveling similar to zero balancing without the actual funds movement. The cash pool’s closing balance for a day is calculated as a notional sum of the individual balances of the bank accounts included in the pool. The interest is calculated on the notional net balance of all accounts included in the pool and then paid out or charged to the concentration or lead account.

• Physical Cash Pool. A cash pool consisting of one or two concentration accounts and multiple sub-accounts with funds transfer rules specified for each combination of concentration accounts and sub accounts. This type of cash pool is used for cash leveling wherein the user can initiate fund transfers or mirror cash transfers performed by the bank.

Before creating Physical Cash Pools, you have to decide how the physical fund transfers will be recorded in the system. If you are using Oracle Treasure , you can choose to create fund transfers in Oracle Treasury or Oracle Cash Management by choosing one or the other in the site-level system profile option CE: Bank Account Transfers. If you are using Oracle Cash Management only, you will only be able to create fund transfers in Oracle Cash Management

For set up and configuration and more … refer Cash Management User Guide, chpater 8  : http://download.oracle.com/docs/cd/B34956_01/current/acrobat/120ceug.pdf