Introduction to Oracle Approvals Management

Overview of Oracle Approvals Management

The purpose of Oracle Approvals Management (AME) is to define approval rules that determine the approval processes for Oracle applications. 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.

Transaction Deviations

At the time of transaction approval, deviations such as addition of adhoc approvers or deletion of approvers can occur. It is possible to record these transaction deviations by setting the Record Approval Deviations configuration variable to Yes at transaction type level, and running the Approvals Deviations Report after the approval of a transaction. The report displays transaction deviations to the generated approver list.

AME generates an approver list based on the rules setup according to the business requirements. At the time of transaction approval, deviations such as addition of adhoc approvers or deletion of approvers can occur. Any such change to the generated approver list is a deviation. It is possible to record these transaction deviations by setting the Record Approval Deviations configuration variable to Yes at the corresponding transaction type level, and running the Approvals Deviations Report after the approval of a transaction. You can track the deviations by running the Approvals Deviations Report. This report displays the deviations between specified dates.

See: Oracle Approvals Management

See: Running the Approvals Deviation Report

Oracle Approvals Management

Oracle Approvals Management (AME) is a self-service Web application that enables you to define business rules governing the process for approving transactions in Oracle applications that have integrated AME.

What are the advantages of using Oracle Approvals Management?

Oracle Approvals Management enables you as a business user to specify the approval rules for an application without having to write code or customize the application. Once you define the rules for an application, that application communicates directly with AME to manage the approvals for the application's transactions.

Are all the AME features mentioned in this guide available within integrating applications such as iExpenses or SSHR?

You should review the product documentation to see if a particular feature such as parallel approvers is available in the integrating application you are interested in. AME delivers new features in each release; therefore it is possible that there will be a time lag between delivery and implementation by any given development team.

What kind of approval hierarchies are supported?

You can define approvals by job, supervisor hierarchy, positions, or by lists of individuals created either at the time you set up the approval rule or generated dynamically when the rule is invoked. You can link different approval methods together, resulting in an extremely flexible approval process.

Can you use the same rules for different applications?

Yes. You can define rules to be specific to one application or shared between different applications.

How can you ensure that the rules you create are valid?

AME has built-in testing features that enable you to confirm the behavior of new or edited business rules before live execution.

How is a transaction in progress affected by changes in your organization?

As AME recalculates the chain of approvals after each approval, a transaction is assured to be approved under the latest conditions, regardless of organizational changes, changes to transaction values, rule changes, or currency conversions.

What is a deviation?

A change to the standard approver list generated by AME for approval of transactions is a deviation. AME generates a standard approver list based on the rules set up for transaction types, either by the Approvals Management Administrator or the Approvals Management Business Analyst. Any change to this standard approver list is a deviation.

Can I capture transaction deviations generated to an approval list?

Yes, you can capture deviations generated to the standard approver list by running the Approvals Deviations report.

How can I track the deviations?

You must set the configuration variable Record Approval Deviations at transaction type level to Yes to track deviations.

Approval Processes

Approval Process

Oracle Approvals Management (AME) provides a parallel approval process. The approval parallelization shortens the time that a transaction's approval process requires. The approval process time is reduced as AME imposes a hierarchical (tree) structure on the transaction's approver list, and enables each part of the tree at a given level to progress through its notification-approval cycle in parallel. See: Parallel Approval Process for details.

A transaction's approval process can have two components:

• List of approvers

• Set of productions

Approver Lists

A transaction's approver list has a hierarchical structure. The transaction's approver list may contain several items' approver lists. Each item's approver list may have three sub-lists. Of these sub-lists, the authority sub-list can have a chain of authority generated by one or more action types. Each approver group or chain of authority can contain multiple approvers.

Items

AME can generate an approver list for a transaction's header, and a separate approver list for each item in the transaction. A transaction type can define multiple item classes. For example, a transaction type might generate separate approver lists for each transaction's header, line items, and cost centers. All transaction types include a header item class, which always has one item (the transaction's header). All other item classes are optional.

Sub-Lists

An item's approver list may contain three sub-lists:

• Pre-chain of authority

• Authority

• Post-chain of authority

The pre- and post-chain sub-lists contain zero or more approver groups; the authority sub-list contains zero or more chains of authority.

Action Types

An action type is a set of actions having a common purpose. Each sub-list can contain approver groups or chains of authority generated by several action types. For example, actions in the absolute-job-level action type all generate chains of authority by ascending the HR supervisory hierarchy until they reach a manager with a particular job level. The actions differ according to the job levels they require.

Approver Groups

An approver group is a collection of approvers that you define. Typically, approver groups contain subject-matter experts.

Chains of Authority

A chain of authority ascends a hierarchy of approvers that are normally defined in applications other than AME, for example HRMS (supervisor position hierarchies). The start point of the chain, and how far it ascends the hierarchy, usually varies between transactions. You can also treat an approver group as a chain of authority. In this case AME ignores the approver group's group-specific properties. Generally, chains of authority contain managers.

Approver groups and chains of authority behave differently in certain circumstances. For example, when one approver forwards a notification requesting approval to another approver. Otherwise, approver groups and chains of authority behave similarly.

Approvers

An approver has the following two properties:

• Approver Types

  An approver type is any Workflow Directory Services originating system that defines entities, which can receive Workflow notifications requesting an approval. For example, the HR application defines its set of employees as a Directory Services originating system, so an HR employee can be an approver.

• Approver Categories

  AME can generate approvers belonging to either of two approver categories: action and informational (for-your-information or FYI) approvers. Action approvers must approve a transaction. FYI approvers merely receive a notification describing the transaction. The exact content of all notifications depends on the application that generates the notification.

Productions

In AME, a production assigns a value to a variable name. For example, AME might generate a production that assigns the value digital certificate to the variable name eSignature. AME does not interpret the productions it generates. In fact, AME does not even define any standard production variable names. Rather, it leaves these tasks to integrating applications and their transaction types.

AME generates the following kinds of productions:

• Transaction-level productions that are variable name or value pairs associated with a whole transaction.

• Approver-level productions are associated with specific approvers within a transaction's approver list.

• Item-level productions are associated with each item in the transaction.

What Happens at Run Time

Once you have defined a set of rules for a transaction type, and the application associated with the transaction type is configured to use AME, the application communicates directly with AME to manage the transaction type's approval processes. Typically, the application communicates with AME when a transaction is initiated in the application, and then each time an approver responds to the application's request for approval of the transaction, until all approvers have approved the transaction. AME records each approval, and recalculates the approver list for a transaction each time an approver responds to a request for approval of the transaction.

AME recalculates the approver list each time an approver responds. This enables AME to account for several possible circumstances that can affect a transaction's approver list:

• An attribute value changes, thereby affecting which conditions are true and so which rules apply to the transaction.

• A condition or rule is added, changed, or deleted, again affecting which rules apply to the transaction.

• A change occurs in the organizational hierarchy used by the transaction type's set of rules, thereby changing the membership of the applicable chain of authority.

• Currency exchange rates change, thereby affecting which conditions on currency attributes are true and so which rules apply to the transaction.

By accounting for such changes, AME guarantees that transactions are always approved according to the most current business data possible.

Approval Process Execution

Approval-Process Execution

Integrating applications can communicate with AME in many different ways. For example, an integrating application can ask AME for a transaction's entire approver list, for the rules satisfied, or for the set of approvers the application should notify next.

The Standard Algorithm

Typically, an integrating application follows a simple procedure for managing a transaction's approval process:

1. Ask AME for a transaction's entire approver list.

2. Display the approver list to the requestor, optionally prompting them to suppress or add approvers.

3. Communicate any approver suppressions or additions to AME.

4. Ask AME whether the transaction's approval process is complete, and if not, what approvers (if any) to notify.

5. If AME indicates that no further approvals are required, stop.

6. Notify any approvers identified by AME in step 5.

7. Wait until an approver responds to a notification.

8. Communicate the response to AME.

9. Go to step 4.

Approver-Notification Order

The order in which AME presents approvers for notification at step 4 of the standard algorithm depends on a variety of ordering modes and order numbers that together determine a unique ordering of the approvers in a transaction's approver list.

An ordering mode tells AME how to order the collections of approvers at a given level of the hierarchy constituting a transaction's approver list. For example, the sub-list ordering mode basically tells AME whether to notify pre-approvers at the same time as authority approvers, all other things being equal. AME typically uses ordering modes, before a transaction is submitted to AME for approval, where the number of things to be ordered is unknown. For example the approvers generated by a particular action type maybe notified sequentially or in parallel.

Order numbers establish a fixed ordering of a collection of approvers at a given level of the hierarchy constituting a transaction's approver list, for example, the approvers in an approver group are assigned order numbers. Order numbers are not necessarily unique. Thus several approvers in an approver group can have the same order number. AME typically uses order numbers where you know the number of things to be ordered before a transaction is submitted to AME for approval.