Videos

Oracle Approvals Management


The purpose of Oracle Approvals Management (AME) is to define approval rules that determine the approval processes for Oracle applications. You can use AME to derive lists of approvers based on user defined rules and maintain a history of approvers statuses when :

  • Authorizing expenses
  • Transferring employess from one division/cost center to another
  • Approving purchase orders with line or total order values
  • Paying invoices

The following graphic illustrates the typical approval process used in an organization:

Approval Rules
An approval rule is a business rule that helps determine a transaction's approval process. Rules are constructed from conditions and actions. For example an approval rule can be as follows:
If the transaction's total cost is less than 1,000 USD, and the transaction is for travel expenses, then get approvals from the immediate supervisor of the person submitting the transaction.

The following graphic identifies the components of the approval rule:
The approval rule's if part consists of zero or more conditions, and its then part consists of one or more actions. A condition consists of a business variable (in AME, an attribute) and a set of attribute values, any one of which makes the condition true. An action tells AME to modify a transaction's approval process in some fashion. The conditions in the sample rule in the graphic refer to two attributes: the transaction's total cost, and the transaction's purpose. The sample rule's action tells AME to add the requestor's supervisor to the transaction's approver list.

AME enables you to define rules that express a wide variety of approval rules. For example, rules that:
• Require subject-matter-expert approval
• Require managerial approval
• Create exceptions for rules requiring managerial approval
• Substitute one approver for another in special cases
• Revoke a manager's signing authority in special cases
• Grant a manager extra signing authority in special cases
• Generate a production that assigns a value to a variable name such as the value digital certificate to the variable name eSignature.
• Send for-your-information notifications.

You can prioritize the approval rules. This enables you to apply rules of sufficient priority to any given transaction.

Transaction Types
An application that uses AME to govern its transactions' approval processes is termed an integrating application. An integrating application may divide its transactions into several categories where each category requires a distinct set of approval rules. Each set of rules is called a transaction type. Different transaction types can use the same attribute name to represent values that are calculated in different ways or fetched from different places. This allows several transaction types to share approval rules (thereby implementing a uniform approval policy across multiple transaction types). A rule use occurs when a transaction type uses a particular rule for a given time period, optionally at a given priority level.

New tab

Attributes



Attributes are business variables with a single value for a particular transaction.

Examples of attributes are:

  • Transaction's total amount
  • Percentage of discount
  • An item's category
  • A person's salary
Approval rules use the attributes to determine the outcome such as a value for the transaction's total amount or a value for the percentage of discount. Attributes have an item class such as Header, Line Item, Cost Center, and Project Code. The above graphic uses the example of a purchase order to illustrate attributes and their values.

Creating attribute names and defining attribute use are two important steps in the implementation process for a transaction type. Often a transaction type predefines the attribute names and attribute use that your organization requires. You can use the predefined attributes or create attributes to meet your business requirements.

Attribute Properties
An attribute has the following properties:

Name
An attribute name is a string that represents a decision variable. An attribute name can be at the most 50 bytes long (50 characters long) when you have configured your Oracle Applications to use a single-byte character set. In AME, attribute names always appear in upper case, for example, TRANSACTION_AMOUNT.

Note: If you enter an attribute name in lower or mixed case, AME converts it to upper case before storing it.
All attribute names are shareable. After you create an attribute name, it is available for use in all transaction types. When you create an attribute name, ensure its level of generality reflects your intentions.


Item Classes
An attribute item class determines what class of items have a value for the attribute. For a given transaction, each of the items in an attribute's item class has its own value for the attribute. An attribute always has the same item class, regardless of the transaction type. Attributes belonging to the header item class are sometimes termed header-level attributes. Attributes belonging to subordinate item classes are sometimes termed line-item-level attributes or cost-center-level attributes.

Use
An attribute use tells AME how to get the attribute's value for a given item and transaction, in a given transaction type. Every transaction type can define its own use for a given attribute. This means several transaction types can share conditions and rules, so that an organization can define a single set of rules that applies to several transaction types, thereby implementing a uniform approvals policy across severalapplications. It also means that an attribute name can exist without a given transaction type having access to it, or to conditions defined on it, because the transaction type has not yet defined a use for it.

Attribute use can be of two types:
• Static
A static use specifies a fixed value for the attribute, for all items and transactions. It is a common practice to give static use to most or all of the mandatory attributes. One reason is that a static use requires less runtime overhead than a dynamic use. Another is that a static use expresses uniform business policies for all transactions
in a given transaction type.

• Dynamic
A dynamic use specifies an SQL query that AME executes at run time to fetch the attribute's value for each item in the attribute's item class, for a given transaction. The execution of dynamic attribute use constitutes the majority of AME's run time overhead. Therefore, optimizing your dynamic use can have a big impact on AME's
performance. Ensure you optimize these queries thoroughly, especially if the transaction type that owns them processes a high volume of transactions.

New tab