Approvals Management Engine R12 (AME) Demystified

By Sujay Kamath

Prisio Technologies

Introduction

In today’s world, many organizations are in need of implementing proper controls in place for faster transaction
processing. The most important aspect to have proper controls in place is to have an automated approval process.
Oracle E-Business Suite provides an application within its suite that will enable organization to implement
automated approval process. This application is called Oracle Approvals Management. It is also referred by the
name Approvals Management Engine (AME).

In simple terms, Oracle AME can be defined as a Self-Service Oracle Web Application that enables organizations to
define business rules for approving transactions processed in E-Business Suite. AME provides a framework to
define approval rules that determine the approval processes for Oracle Applications. The transactions that use AME
are the transactions that are created in the source application such as Expense Report in iExpenses, Purchase
Requisitions in iProcurement, etc…

This whitepaper demystifies Approvals Management Engine (AME) and explains the features through the 12.1.3
release in simple non-technical language tailored for business analysts and application manager. This document also
presents real life examples coupled with tips and techniques that improve maintainability of AME rules and
improved performance of the engine. This document uses Purchase Requisition as an example transaction type to
demonstrate the features and usage of AME.

Advantages of using AME

• Enables business analysts to specify the business rules in the form of “Approval Rules” for an application
without having to write code or customize the application.
• Provides a framework to define business rules for an application so that the application can communicate
directly with AME to manage the approvals of a transaction.
• Rules can be defined either specific to one application or shared between different applications.
• Provides parallel approval process, thus shortening transaction processing time.
• Supports the approval hierarchies such as:
o Job
o Supervisor Hierarchy
o Position
o By list of individuals created during approval rule setup or generated dynamically when the rule is
invoked

Integrating Application

Before understanding what AME is made up of, it is important to understand how the E-Business Suite applications
communicate with AME. Any application within Oracle E-Business Suite that uses AME to generate an approver
list for its approval process is called an “Integrating Application”.

COLLABORATE 12 Copyright ©2012 by Sujay Kamath Page 1

 Figure 1: Integration of AME with Oracle E-Business Suite Application

Following is the list integrating applications within Oracle E-Business Suite that are enabled to integrate with AME:

# Integrating Application # Integrating Application

1 Advanced Benefits 21 Oracle Deal Management
2 Bills of Material 22 Oracle Price Protection
3 Cash Management 23 Partner Management
4 Contracts Core 24 Payables
5 Engineering 25 Payroll
6 Enterprise Asset Management 26 Process Manufacturing Logistics
7 Enterprise Performance Foundation 27 Process Manufacturing Process Execution
8 E-Records 28 Process Manufacturing Product Development
9 Field Service 29 Process Manufacturing Regulatory Management
10 Financial Consolidation Hub 30 Public Sector HR
11 Financials Common Modules 31 Purchasing
12 Human Resources 32 Quality
13 iAssets 33 Quoting
14 Internal Controls Manager 34 Receivables
15 Inventory 35 Service
16 iSupplier Portal 36 Service Contracts
17 Labor Distribution 37 Sourcing
18 Learning Management 38 Student System
19 Lease and Finance Management 39 Work in Process
20 Manufacturing Execution System for Process
Manufacturing

Structure of AME
AME is a framework of well-defined approval rules constructed using the following 5 components for a given
transaction type:
1. Transaction Type
2. Attributes
3. Conditions
4. Actions
5. Approver Groups
6. Rules

Each component of AME plays an important role in generating an approver list for a given transaction’s approval
process.

COLLABORATE 12 Copyright ©2012 by Sujay Kamath Page 2

 Figure 2: Structure of a Rule in AME

A “Transaction Type is a distinct set of approval rules used by certain category of transactions in an integrating
application. Examples of transaction types are:
Purchase Requisition Approval (Purchasing)
Requester Change Order Approval (Purchasing)
OIE Expense Reports (Payables)
Payables Holds Resolution (Payables)
Payables Invoice Approval (Payables)

A “Rule” is defined using “Conditions” and “Actions”. The structure of an AME Rule is exactly similar to the IF
function in Microsoft Excel office application. The syntax of IF function in excel is as follows:
IF(logical_test, [value_if_true], [value_if_false])
The “logical_test” section represents the “Condition” component. The “[value_if_true]” section represents the
“Action” component. Below diagram depicts an AME rule compared to an Excel IF function.

Figure 3: Microsoft Excel IF condition mapped to AME Rule

The “Condition” component consists of a business variable (known as “Attribute”) and a set of attribute values. For
the rule to apply to a transaction, all the conditions must be true so the “Action” component can be invoked.

The “Action” component tells AME to modify a transaction's approval process in some fashion. This results in the
“Action Type” and “Approver Group” generating the Approver List

COLLABORATE 12 Copyright ©2012 by Sujay Kamath Page 3

“Action Type” component is a collection of actions having similar functionality. Every action belongs to an action
type.

“Approver Group” component is a collection of approvers (or subject-matter-experts)

Setup and Usage of AME for a Transaction Type

The setup and use of AME is best explained when it is configured for a specific transaction type. In this whitepaper,
the transaction type used is “Purchase Requisition Approval” from Oracle Purchasing application. The first and
foremost step in setting up AME for Purchase Requisition Approval transaction type or any transaction type is to
access the AME setup pages. Until 11i.AME.A patchset version, users can be directly assigned with AME
responsibilities listed in the table below. However, with the introduction of 11.AME.B version, AME uses the Role
Based Access Model (RBAC) to provide users access to AME functions.

AME uses roles and responsibilities to define access levels and security at 2 levels:
o Data Security:
o Function Security
While the “Data Security” enables to define access to Transaction Types for a limited role, the “Function Security”
enables to define access to AME functions (modules) for a business analyst and administrator

Users accessing AME dashboard must have access to one of AME responsibilities:

# User Type Responsibility Usage

Enables access to areas of the user interface that do

not require expertise in SQL or PL/SQL
a Business User (Non-technical) Approvals Management Business Analyst
programming, or technical knowledge of Oracle
Applications
Full access to AME's user interface
Administrative User Must grant at least one user administrative
b Approvals Management Administrator
(Technical) privileges in AME, to perform technical tasks such
as setting AME's configuration variables

In R12 / 11.AME.B onwards, getting access to AME setup and starting the configuration is a 2 step process:
1. Assign pre-defined roles to user
2. Grant data access to user

1. Assign pre-defined roles to the user

Using System Administrator login (User ID = SYSADMIN) and then using User Management dashboard page,
assign the following 5 roles to the application user responsible for setting up AME:

# Role Usage

View-only access to Business Dashboard, Attributes, Conditions, Action

a Approvals Management Process Owner Types, Approver Groups, Test Workbench, Rules.
Access to the Setup Report page

b Approvals Management System Viewer View-only access to the Admin dashboard and Setup Report

Business dashboard View access, attributes, conditions, groups, test, rules

c Approvals Management Business Analyst access with create, update, delete permissions.
Access to Setup Report page and Configuration Variables page with

COLLABORATE 12 Copyright ©2012 by Sujay Kamath Page 4

 # Role Usage

permission to change transaction specific configuration values.

Can create, update, delete Actions; create, update, delete Action Type
Configuration Values but cannot create, update, delete Action Types
Admin dashboard access, Setup Report, Exceptions Log access,
d Approvals Management System Administrator Configuration Variables access with permission to define transaction type
specific values
Access rights of Business Analyst and System administrator.
e Approvals Management Administrator Create, update, delete Action Types.
Modify default Configuration Values

Figure 4: Assign pre-defined AME roles to the user

2. Grant Transaction Type access to the user using Functional Administrator responsibility.

Figure 5: Grant data access to all Transaction Types

COLLABORATE 12 Copyright ©2012 by Sujay Kamath Page 5

Configure AME for a given Transaction Type
Once the Roles and Grants setup is completed, the AME Dashboard can be accessed. This whitepaper uses Business
Analyst Dashboard page (using Approvals Management Business Analyst responsibility) to configure approval rules
for Purchase Requisition approval process in iProcurement.

Figure 6: AME Dashboard Home

To define business rules (approval rules) in the system for generating list of approvers for a Purchase Requisition
created in iProcurement, the AME business analyst needs to complete certain configuration steps needed for
Purchase Requisition Approval” transaction type. The configuration steps involve setting up the components of
AME listed under “Approval Process Setup” section located on the right-side of the AME Dashboard Page. The
components are: Attributes, Conditions, Action Types, Approver Groups and Rules.

Attribute
Attributes in AME are placeholders for transaction data elements. They are basic elements of an AME rule.
Attributes can be static (fixed value) or dynamic (SQL Query based). AME comes with several seeded attributes for
each of the transaction types in the system. If the seeded attributes cannot be used for approval rules, then
organizations can define their own attributes. Attributes can be shared across various transaction types. Attributes
can be defined at 3 different levels – Header, Line Item and Cost Center level.

COLLABORATE 12 Copyright ©2012 by Sujay Kamath Page 6

 Figure 7: List of seeded AME Attributes for Purchase Requisition Approval

Figure 8: Picture depicting Attribute usage for a Purchase Requisition Approval

Condition

The “Condition” component is used to tell AME engine to trigger an AME rule if the result of the condition is
TRUE. One or more attributes are used to define a condition. In the condition setup, an attribute is associated with a
value or range of values. At runtime, the transaction type value is evaluated against the attribute value. If the value
transaction type value qualifies with the attribute value, the outcome of the condition is TRUE and the AME rule is
eligible to trigger. Otherwise, the condition will yield FALSE and the rule shall not apply.
Below is an example of 3 conditions defined for “Purchase Requisition Approval” transaction type.

Condition 1: “DELIVER_TO_LOCATION in (US.0219)”. At runtime, if the requisition in iProcurement has

“Deliver To Location” as “US.0219”, then tell AME to enable the rule associated with this condition to fire.

Condition 2: This condition states if the Requisition Total is > 1000 and < 1999 and the currency is “USD”, then tell
AME to enable the rule associated with this condition to fire.

Condition 3: This condition states if the Requisition Total is > 2000 and < 2999 and the currency is “USD”, then tell
AME to enable the rule associated with this condition to fire.

COLLABORATE 12 Copyright ©2012 by Sujay Kamath Page 7

 Figure 9: Conditions defined for Purchase Requisition Approval

Action Type
An Action Type is a collection of one or more Actions having similar functionality. An Action tells AME how to
modify a transaction’s approval process in a certain way. As shown in Figure 2: Structure of a Rule in AME, a rule’s
“THEN” part consists of one or more actions. AME provides several seeded action types or one may define a
custom action type. The seeded Action Types available in AME can be used to ascend organization hierarchies.
Seeded Actions Types available in AME cannot be used with any transaction type.

Action Types are grouped based on “Approver Types”. Following table lists the popular action types for each
approver type:

Approver Type Action Type

absolute job level
final approver only
Job based manager then final approver
relative job level
supervisory level
hr position
HR Position based
hr position level
pre-chain-of-authority approvals
Approver Group based post-chain-of-authority approvals
approval-group chain of authority

Explanation of each Action Type is well understood with the help of an example. In the example shown below, the
action type defined is “approval-group chain of authority”, which is Approver Group based. While the meaning of
“Approver Group” is defined in the next topic, think of approver group where the approvers are stored. For Purchase
Requisition Approval transaction type, the action type defined below tells AME to build a “chain-of-authority” (i.e.,
ascend the hierarchy of approvers). These approvers are derived from integrating applications (example:
HRMS/Custom Table).

COLLABORATE 12 Copyright ©2012 by Sujay Kamath Page 8

 Figure 10: Action Type chosen for Purchase Requisition Approval

The “Ordering Mode” for Action Type can be either Serial or Parallel, which tells AME how to establish the
notification order for approvers. If more than one Action Types are listed, then they can be assigned with an “Order
Number", which tells AME how to prioritize action types. The “Voting Method” for an action type tells AME how
to treat the responses of the approvers based on the notification order.

Approver Group
Approver Group is used to fetch approvers from Oracle Applications (HRMS). They can be static or dynamic in
nature. In static approver group, the approvers are constant, added at the time of Approver Group setup and will be
listed as Group Members. In the case of Dynamic approver group, the approvers are generated at run time using an
SQL Query in the approver group setup and are later identified as Group Members at run time. Approver Group may
have a voting method assigned such as Consensus, First Responder Wins, Order Number and Serial. The voting
method assigned to an approver group determines the order in which the Group Members are notified and also how
the decision of the group’s approval.

COLLABORATE 12 Copyright ©2012 by Sujay Kamath Page 9

 Figure 10: Approver Groups and its definition

Below table lists the name and meaning of each voting regime:
Voting Regime Name Description
Serial Members are notified one after the other; All members
must approve for the group to approve.
Consensus Members are notified in parallel; All members must
approve for the group to approve.
First-Responder-Wins Response of the first member to respond to the
notification requesting approval becomes the group's
approval decision.
Responses of the remaining group members are stored in
the AME transaction log and their responses are ignored.
Order-Number Members are notified in the order of their order
numbers. Members with same order numbers are
notified in parallel.

Approver groups defined here will be automatically associated with the Action Types (see Figure 10).

COLLABORATE 12 Copyright ©2012 by Sujay Kamath Page 10

Rule
A Rule (also called as “Approval Rule”) in AME is used to transform the business rules into approval rules to
specify approvers in the transaction’s approval list. Rule is the last component step in AME configuration process. A
rule is constructed using the following components:
1. Rule Type
2. Item Class
3. Category
4. Conditions
5. Actions

Figure 11: Structure of AME Rule

AME provides 8 rules types. 7 out of 8 rule types generate approver list for transactions. A brief introduction of each
rule type is shown in the table below:

# Rule Type Description of usage

1 List Creation Generate chains of authority
Uses action types that ascend an organizational hierarchy to generate one or
more chains of authority
A required attribute typically identifies the first approver in each chain
A specific action determines how many approvers are in each chain
2 List Creation Exception Generate chains of authority
Suppresses selected list-creation rules
Contains at least 1 ORDINARY condition and at least 1 EXCEPTION
condition

COLLABORATE 12 Copyright ©2012 by Sujay Kamath Page 11

3 List Modification Modify the default chain of authority generated by all applicable “List
Creation” and “List Creation Exception” rules
Must have exactly 1list-modification condition
Commonly used to REDUCE and EXTEND an approver's signing authority
and
4 Substitution Delegate one approver's authority to another approver
Must have exactly 1 list-modification condition
5 Pre List Approver Group Used to add approvers BEFORE chain of authority
6 Post List Approver Group Used to add approvers AFTER chain of authority
7 Combination Used when several business rules apply to exactly the same business case
8 Production In AME, the Action Type generates variable-name or value pair in the Action’s
parameters called “Productions”. The Production Rule’s purpose is to pass
those Productions (Variable Name or Value) to Oracle Purchasing application
or any integrating application.

After choosing a Rule Type during Rule setup, the approver list that needs to be generated can be specified using
Item Class. Item Class can be Header or Line-Item level. A rule can be activated or deactivated using Start Date and
End Date. If there a multiple rules defined for a transaction type, they can be prioritized using rule priorities. Rules
can also be categorized as “FYI” or “Approval”. For a rule to trigger, one or more conditions can be added and
finally specify the Action using the Action Type. Conditions are optional. If no conditions are identified in the rule,
the action is always executed. If one or more conditions are defined and the result is TRUE, only then the action part
is executed.

AME Test Workbench

Once all AME components are defined, the business rules can be tested using the utility available in Business
Analyst dashboard called “Test Workbench”. Test Workbench is an AME diagnostic utility to test and validate the
approval rules setup for a given transaction type. Using this utility, business analyst or administrators can create
several test cases to validate the approval rules and ensure they trigger based on the conditions and actions specified
for a given transaction.

Figure 12: AME Test Workbench

Enabling AME for a Transaction Type

Once the business rules are defined in AME using Business Analyst dashboard, it is time to connect those setups
with the integrating application that wishes to implement the business rules. For this whitepaper, the example shown
below how to enable AME business rules for a Purchase Requisition approval process in Oracle Purchasing
application. For Purchasing Requisitions created using iProcurement, Oracle Purchasing provides a seeded
document type called “Purchase Requisition”. In the definition of this document type, there is a placeholder to

COLLABORATE 12 Copyright ©2012 by Sujay Kamath Page 12

specify approval transaction type. To enable AME rules for Purchase Requisitions created in iProcurement, the
“Approval Transaction Type” value should be set to “PURCHASE_REQ”

Figure 13: Enable AME for Purchase Requisition approval in iProcurement

Implementation Considerations and Tips/Techniques

Before implementing AME for any transaction type, it is very important to prepare and document a set of business
cases. Each business case must clearly define the details necessary to configure the components of AME –
Variables, Attributes, Conditions, Actions, Action Type, Approver Groups and Rules. Lastly, every business case
document must be represented with at least one test case scenario. The business case document should be
comprehensive to that extent that it should include all types of cases such as Repeated Approvers, Special
Forwarding and Parallelization.

It is also important to document representation of approval rules in the form of either Approval Matrix or Decision
Tree. Approvals Matrix is in the format of a table that has one row per business rule. Decision Tree has one column
of nodes for each attribute with each branch leaving a node representing a set of allowed values for the attribute
represented by the node. Decision Tree format are considered more flexible than Approval Matrix.

With the introduction of R12, AME patch-set level 11.AME.B has been benefited with some enhancements. Some
of the key enhancements related to Requisition approval are:
• Position Hierarchy based Approvals
• Parallel Approvals
• Support for FYI Notifications

About the Author

Sujay Kamath is an experienced information technology professional. He is currently involved in implementing

Procure-to-Pay (P2P) solutions using Oracle e-Business Suite R12. He has over 13 years of experience in the field of
Oracle ERP and delivered end-to-end ERP solutions for numerous fortune 500 customers. He can be reached at
[email protected]

COLLABORATE 12 Copyright ©2012 by Sujay Kamath Page 13