AME Part Two – Components of AME

In the last blog post, I provided a quick overview of what AME is and what some of the benefits of using AME are. In the second post in my series on AME, I’ll be looking at the different components of AME and how they interact.

Before you start using AME, it is important that you understand exactly what the different parts of the Engine are, what you need to configure, and how they all work together. There is frequently a requirement to modify the seeded components or to create new ones for an organization, in order to develop their business rules.

Transaction Types

A Transaction Type defined the type of transaction for which the business rules and approval routes will be based. This is an eBusiness Suite transaction, for example creating a new vacancy in iRecruitment or creating purchase orders. There are many different Transaction Types seeded within the application to meet the requirements of the most common transactions which occur within the eBusiness Suite that would require an approval to take place. If you are integrating a bespoke application with AME, then new Transaction Types can be defined within AME. However, the creation of new Transaction Types is not a straightforward task, and Oracle discourage this because of the amount of programming effort that is required to integrate a new Transaction Type with AME.


Within AME, Attributes can be defined as business variables which represent the value of an element in a transaction. For example, in the case of an invoice approval, a typical attribute would be the supplier name, or the invoice value. When defining the business rule, the attributes that are available to you will help define the rule itself and it’s implementation within AME. The reason for this is that the value of an Attribute for a transaction is usually evaluated as part of the rule in order to determine whether the condition has been met or not – for example, is this invoice worth more than £500? Within AME, Attributes can be created as static (where they have a constant value which remains the same for every transaction associated with the Attribute), or as dynamic (where they use a SQL query to determine the value of the Attribute at run time). Most Attributes that are used within AME are dynamic.

Within AME, there are different types of Attribute available to you:

  • Strings can be alphanumeric and have a maximum length of 100 characters.
  • Numeric attributes can have any numeric value that is acceptable in PL/SQL, including decimals and negative numbers. When using a numeric Attribute within AME, the number must be converted to a canonical form – within the FND_NUMBER package there is a function NUMBER_TO_CANONICAL which will do the conversion for you.
  • Currency Attributes are used when the organization is using multiple currencies. This allows Oracle to perform currency conversions when retrieving the Attribute value. If currency Attributes are used, the SQL query which retrieves the value must include the numeric column, currency and conversion method. Additionally, any AME conditions which use currency Attributes must include a condition for EACH CURRENCY that the transaction might use.
  • Boolean Attributes can only have a valid value of true or false. Any dynamic Attributes which are defined as Boolean MUST return one of these two states – NULL is not a valid value in an AME Boolean Attribute. When using Boolean Attributes, AME provides a format string which should be used – AME_UTIL.BooleanAttributeTrue and AME_UTIL.BooleanAttributeFalse.
  • Date Attributes are commonly used within AME – for example the invoice date, shipping date, and so forth. Again, AME is particular with the format and requires all date Attributes to be in the format YYYY:MON:DD:HH24:MI:SS. There is a format string again provided in the AME_UTIL package – AME_UTIL.versionDateFormatModel which can be used to return a date in the required format.

Every Transaction Type that is defined in AME as standard uses several mandatory Attributes which can be considered runtime parameters, since they are commonly used to determine the behaviour of AME during execution. The mandatory attributes which are defined for all Transaction Types are:


For more information of the mandatory Attributes and how AME interprets them, you should consult the AME Implementation Guide.

In addition to mandatory Attributes, AME also includes the concept of a required Attribute. These are similar to mandatory Attributes (in that they must be populated), the only difference being that required Attributes are defined for a specific Transaction Type rather than for all Transaction Types.

Requires and mandatory Attributes are seeded with default values, which can be modified to meet the exact requirements of a specific Transaction Type.


The next component to look at within AME is Conditions. These are used to evaluate the value of an Attribute (or Attributes) for a particular transaction – this is where the “IF” part of each business rule is defined.

Each Condition returns either a true or false flag, and the result is then used by AME to determine whether the business rule has been met or not. If the approvals code were to be written in plain PL/SQL, then this would be an IF statement.

In the example from the last post of “if the invoice value is over £500 then additional approval is required”, AME would retrieve the value of the invoice total Attribute and determine whether the Condition “> 500” was met or not.

There are three different types of Condition within AME – Ordinary-Regular, Ordinary-Exception and List Modifier:

  • Ordinary-Regular Conditions associate an Attribute with a value or range of values – for example, SELLER_NAME = ‘Smith Widgets Ltd’, or 20000 > INVOICE_AMOUNT > 1000 (i.e. invoice amount is greater than 500 and less than 20000).
  • Ordinary-Exception Conditions are similar to Ordinary-Regular Conditions, but are limited to the types of rules to which they can be applied. When we look at Rules later in the post, I will go into more detail.
  • List-Modifier Conditions are used to modify the approval list based on the contents of the existing approval list. For example, “If Bob is the last approver, then include his supervisor”

Action Types and Actions

Within AME, Actions define what should the Engine do when a transaction satisfies a particular Condition. It is these Actions which helps to determine which approvers are included in or excluded from the list being generated.

Action Types are collections of Actions which have similar functionality, such as the approval hierarchy that should be used when generating an approver list. For example, the Actions which relate to building an approval list based on the HR hierarchy would be grouped together as one Action Type – all Actions for this Action Type are all related to using the same hierarchy, but would differ based on the number of levels that need to be retrieved. Each of the Actions within the Action Type would typically describe the number of levels used by the common hierarchy, and they are then collected together in one Action Type based on the hierarchy used.

As standard, a range of different, common Action Types are provided by AME, which generally meet the requirements of most organizations, but custom Action Types can be defined if necessary. The different seeded Action Types can be grouped into four different hierarchy types that they support:

  • Chain of Authority
    • These Action Types typically use the position or supervisor hierarchy from HR to generate the approver list. These Action Types typically use the position or supervisor hierarchy from HR to generate the approver list. Depending on your patch set, you may not have all of the following Action Types (or, conversely, you may have additional Action Types not listed here!):
Action Type Description Example
Absolute job level Follows the HR hierarchy until an approver at the specified job level is found Requires approval up to Senior Manager Grade.
Dual chains of authority Uses the HR hierarchy to generate two separate lists of approvers, both of which must have an approval action. Require approval from two different supervisors, for example during an employee transfer from the current and new managers.
Final approver only Uses the HR hierarchy, but only requires approval from the last person found in the hierarchy. Only require approval from a divisional manager.
HR Position Uses the HR hierarchy to find a specified job position. Require approvals up to the Invoice Manager.
HR Position Level Uses the HR hierarchy to find a specified number of positions. Require approvals up to Management Grade 4.
Line-item job-level chains of authority Uses the HR hierarchy, and enables the approval chain to be based on individual line items. Require approval from the cost centre manager for each invoice distribution line.
Manager then final approver Uses the HR hierarchy, but only seeks approval from the immediate supervisor and the last person found in the chain. Approval from the manager and CEO is required.
Relative job level Follows the HR hierarchy for n levels from the start point Requires three levels of approval.
Supervisory Level Uses the HR hierarchy to find n supervisors, irrespective of job level. Require approval from three supervisors.
  • List Modification
    • As with the Chain of Authority Action Type, the List-Modification uses the HR supervisor hierarchy to generate the approver list. However, the List Modification (as the name suggests!) is used to modify the generated list to either include additional approvers, or to exclude approvers that have been identified from the hierarchy. For example, if there is a business rule that stipulates that for all IT purchases, the most appropriate final approver is the IT Manager rather than the Finance Manager (who normally approves the transactions), then a List Modification would be applied to modify the generated list of approvers. There are two types of List Modification Action Type:
Action Type Description Example
Final Authority Ends the approval chain at a designated approver, thereby granting final authority to them when they would normally not be the final approver. If the Approver is the IT Manager, then they are the final approver.
Non-final Authority Adds additional approver(s) to the approval chain, thereby revoking the final authority that the person previously had. If Bob is the final approver, then add his supervisor as well.
  • Substitution
    • Substitution Action Types allow for one approver to be substituted for another whenever the approval chain involves them. For example, in the absence of one person, route the approval to a different person.
  • Approver Groups
    • Approver Group Action Types allow either a static or dynamic approver list to be generated. If the list is static, then the names of specific individuals responsible for the transactions is included when the group is defined; if the list is dynamic then the name(s) included in the list are returned by a SQL statement.
Action Type Description Example
approval-group chain of authority The Chain of Authority list is built in a similar manner to the List Creation and List Modification Action Types. However, rather than using the HR position or supervisor structure to generate the list of approvers, it uses a group of approvers that is predefined. If a vacancy is being created, then require approvals from Matt, Pat and John.
pre-chain-of-authority approvals / post-chain-of-authority approvals Either inserts a new approval list before, or appends a new approval list after, the standard approval list has been generated. If the vacancy is for the Finance department,require approval from two Finance Managers and then follow the normal approval process of three supervisors required.


As with Actions and Action Types, Rules also use Rule Types to determine the list to build if the results of the Rule are true. Depending on the Transaction Type, different Rules are available – the following table discusses the Rule Types that are available for iRecruitment Vacancy Approval in Release 12.1.1:

Rule Type Description
List Creation Generates a Chain of Authority list of approvers that uses an organizational hierarchy to build the list.
List Creation Exception As with List Creation, builds a Chain of Authority list of approvers. This list is typically used to suppress a List Creation rule so that approval from a specific group of approvers is required if a condition is met. For example, based on the recruiting department, force the transaction to be approved by a different group of people.
List Modification Grant or revoke final authority to / from an approver, based on certain transaction conditions.
Substitution Delegate approval from one person to another, for example during absence.
Pre List Approver Group / Post List Approver Group Allows for additional approvers from outside the normal approval group to be added to the chain.
Combination: List Creation / Combination: List Modification Combines Actions from Action Types from different Rule Types.

Configuration Variables

One final component of AME which I have not mentioned so far are Configuration Variables. Configuration Variables are normally set during the initial AME build / configuration, as they impact every AME transaction – in the same way that profile options can be set at different levels, AME Configuration Variables can be set on a system-wide or a Transaction Type basis.

The Configuration Variables for AME in Release 12.1.1 are as follows:

Variable Name Description
Administrator Approver An Adminstrator who should be notified in case of any exceptions in Approvals Management.
Allow All Approver Types Whether Approvals Management allows all approver types
Allow All Item Class Rules Whether Approvals Management allows to create subordinate item class rules
Allow For Your Information Notifications Whether Approvals Management allows For Your Information notifications
Currency Conversion Window How many days Approvals Management should look back, at most, to find a currency-conversion rate
Distributed Environment Whether Approvals Management runs in a distributed-database environment (yes or no)
Production Functionality What types of production-rule functionality are allowed
Purge Frequency How many days temporary Approvals Management data ages before being purged
Record Approval Deviations Whether to record approval deviations or not
Repeated Approvers How many times to require an approver’s approval, in the absence of forwarding

In the next post, I will be looking at providing the correct grants and roles to users in eBusiness Suite to be able to configure AME – please check back soon for the next post, and feel free to leave any comments / questions you may have.


4 thoughts on “AME Part Two – Components of AME

  1. Hi

    We have a situation where one approver can authorise multiple cost centers, this is a problem when one expense spans multiple cost centers, then the approver has to approve multiple times..i have been reading up on supressing repeated approvers, is this the correct functionality? If so please can you detail the navigation path to configure this.


  2. HI Matt,

    Need a help.

    I have two approvers at same job level in the hierarchy and using absolute job level. How do I restrict to notify only 1 person in same job level?

    Eg:- When I create a PR with value USD 40000 and using action type Absolute job level with action atleast level 4. Now the problem is level 4 is assigned to two persons in the same hierarchy A and B. What we require is the PR should stop at A itself and he should be the final approver.
    Thanks in Advance.

Comments are closed.

By continuing to use the site, you agree to the use of cookies. more information

In common with almost all professionally run websites, this website logs the IP address of each visitor in order to keep it running reliably. This is also essential for protecting the website and its visitors from malicious attacks, including infection with malware.

This website provides information as a service to visitors such as yourself, and to do this reliably and efficiently, it sometimes places small amounts of information on your computer or device (e.g. mobile phone). This includes small files known as cookies. The cookies stored by this website cannot be used to identify you personally.

We use cookies to understand what pages and information visitors find useful, and to detect problems such as broken links, or pages which are taking a long time to load.

We sometimes use cookies to remember a choice you make on one page, when you have moved to another page if that information can be used to make the website work better. For example:
- avoiding the need to ask for the same information several times during a session (e.g. when filling in forms), or
- remembering that you have logged in, so that you don’t have to re-enter your username and password on every page.

You can prevent the setting of cookies by adjusting the settings on your browser (see your browser Help for how to do this). Be aware that disabling cookies will affect the functionality of this and many other websites that you visit.