Various Aspects of Approval Rules

Stage

A stage lets you organize your approval routing rules into logical groupings. Each stage is associated with a dimension, however dimensions for an approval task don't necessarily have to map to a stage. A dimension contains a set of attributes at a specific procurement document level, such as header and lines. However, approval rules can be defined within a stage using attributes from a dimension that's lower than the dimension of the stage. For example, in a stage with header dimension, rules can be created using line or distribution level attributes. Each procurement document has a set of stages seeded for your usage. Approval actions within each stage must be completed before entering the next stage if they're in serial.

Participant

There can be more than one participant within a stage. Properties set on the participants determine whether approvals are routed in serial or in parallel. Oracle Procurement approval tasks are seeded with one or more participants within each stage to enable flexibility in approvals routing. Most seeded participants for requisitions, purchase orders, purchase agreements and supplier registration approvals are rule based. You can create many rules within a participant. The following two properties defined on a participant are of interest:

Participant Type: The supported participant types are: Serial, Parallel and FYI. FYI participants can't directly impact the outcome of a task, but in some cases can provide comments or add attachments.
Voting Regime: The supported voting regimes are: Serial, Consensus, and First Responder Wins.

Within a participant, more than one rule can evaluate to true for a given document submitted for approvals.

Note: When accessing the approval tasks using the BPM Administration pages, you will see options to modify the stages and participants, including delete, edit or remove. There are currently known issues with this BPM functionality, and we strongly advise you against performing any such modifications on the seeded participants.

Rule

Approval rules are managed using tasks that belong under Define Approval Management for Procurement in Functional Setup Manager. Select the corresponding approval task for which you want to manage. For example, for requisitions, go to the Manage Requisition Approvals task.

From the Manage Requisition Approvals page, select the participant for which you want to maintain rules.

Approval Rule Characteristics

An approval rule is composed of these: Rule Name, Condition, and Action.

Rule Name

The Rule Name is used to identify the approval rule. In cases where there are large numbers of rules, users can filter search results in the Query by Example fields.

Condition

The Condition indicates when the approval rule will be applied. For example, a rule is created to conditionally apply if the requisition approval amount is less than 10,000 USD. If a user submits a requisition that has an approval amount of 500 USD, this rule will apply.

A rule can contain multiple conditions, and you can select the "and" or "or" operators to indicate if all conditions in the approval rule must be true or if only one condition must be true for the approval rule to apply. For example, if requisition amount is less than 10,000 and requisitioning BU is US Business Unit.

Action

An action defines what needs to be done if the conditions of a rule are met. It identifies if approvals or FYI notifications are required and the type of users needed to approve or receive notification for a document.

The supported action types are:

Approval required

Approval actions required from the recipients of the approval tasks.
Automatic

Automatically approve or reject the approval task.
Information only

FYI notifications sent to recipients.

The following routing types are supported for both approval required and information only action types. Each type has a specific set of parameters or properties that must be defined.

Approval Group: Specify the Approval Group to use.
Automatically approve if group returns no approvers: Select this option if the approval task should be automatically approved if the selected approver group returns no approvers. An approval group may return no approvers due to updates to the approver group definition or if dynamic approval groups are used, no approvers are found.
View, edit existing, or create approval groups from the Approvals Group tab on the BPM Worklist Application Administration page. You can create a static approval group by adding specific participants to the approvals group.

Job level
Approval Chain Of: Specify whose approval chain the routing should be based on. It can be based on persons associated to the document for which the rules are maintained, such as requester or preparer on a requisition, an overriding approver, or a specific worker selected within the action.
Start With: Select if the list generated should start with the person the approval chain is based on, or his manager.
Minimum Job Level: Specify the minimum job level that's required to perform the approval action if the rule applies. For example, for requisition amounts of 1000 USD or less, a minimum of Job Level 3 is required to approve. If a submitter has job level 2 and submits a requisition with total of 500 USD, it will be routed up his supervisory hierarchy chain to an approver with at least Job Level 3.
Top Worker in Hierarchy: This field identifies the topmost worker in the supervisory hierarchy, such as the CEO of an organization. Approvals won't be routed beyond this worker.
Include: Specify if everyone returned in the list of participants will be included, the first and last manager from the list will be included or only the last manager will be included.

Position Hierarchy: Specify the position hierarchy that the action should be based on.
Position Chain Of: Specify whose position chain the routing should be based on. It will be based on persons associated to the document for which the rules are maintained, such as requester, preparer or an overriding approver on a requisition.
Start With: Select if the list generated should start with the person the position chain is based on, or the next position up.
Minimum Job Level: Specify the minimum job level associated with a position that's required to perform the approval action if the rule applies. For example, for requisition amounts of 1000 USD or less, a minimum of Job Level 3 is required to approve. If a submitter has a position with job level 2 submits a requisition with total of 500 USD, it will be routed up the position hierarchy to an approver with a position that has at least Job Level 3.
Top Worker in Hierarchy: This field identifies the topmost worker in the supervisory hierarchy, such as the CEO of an organization. Approvals won't be routed beyond this worker.
Include: Specify if everyone returned in the list of participants will be included, the first and last manager from the list will be included or only the last manager will be included.

Single Approver
User Type: Select the type of single user you want to include in the list. It can be a specific worker in your organization, or persons associated with the document for which you're setting up rules, such as the requester, preparer, project manager, assigned buyer or principal investigator on requisitions.

Supervisory Hierarchy
Approval Chain Of: Specify whose approval chain the routing should be based on. It can be based on persons associated to the document for which the rules are maintained, such as requester or preparer on a requisition, an overriding approver, or a specific worker selected within the action.
Start With: Select if the list generated should start with the person the approval chain is based on, or his manager.
Number of Approval Levels: Specify the number of levels required to perform the approval action if the rule applies. The number of levels includes the start with person identified. For example, if the Start With value is Manager, and the Number of Approval Levels is 1, then only the manager needs to approve. If the Number of Approval Levels is 2, then it will be routed first to the manager, then to the next level after the manager.
Top Worker in Hierarchy: This field identifies the topmost worker in the supervisory hierarchy, such as the CEO of an organization. Approvals won't be routed beyond this worker.