1. Introduction
As business processes and compliance continue to evolve, companies are placing more and more emphasis
on document and spend approvals. Oracle Fusion Procurement uses Oracle SOA - Approvals Management
extension (AMX) for requisition, purchase order and purchase agreement approvals. AMX provides a
unified way to define and control management processes across Fusion Applications.
In this whitepaper, you can learn about the robust features available and the steps required for setting up
approvals using AMX.
1.1. Oracle SOA Approvals Management
Using Oracle SOA Approval Management extensions, you can define approval rules based on your
business processes and decisions, such as whether to route documents to approvers in serial or
parallel, whether approvals should be based on employee supervisory hierarchy, position hierarchy,
job levels, or approval groups.
There are several key components used in approvals:
• Oracle SOA Approval Management extensions (AMX)
o AMX enables you to define complex task routing rules for business documents.
• Oracle Business Process Management (BPM)
o The BPM Worklist Application is a web-based application that lets users access tasks assigned to them and perform actions based on their roles in the approval process.
o The BPM Worklist Application is used by the Business Process Owner to set up and manages approval rules.
• Oracle Human Capital Management
o AMX integrates with the setup in Oracle Fusion Human Capital Management to derive the supervisory and position hierarchy based approvers.
2. Before setting up approvals
You must first analyze and determine the approval structure that is appropriate for your organization.
2.1. Employee Supervisor Hierarchy
Approvals can be set up to navigate the employee supervisory hierarchy, which is defined in Oracle Fusion Human Capital Management, up to a certain number of levels. Employees must be set up with appropriate jobs and supervisors.
2.2. Position Hierarchy
You can also choose to route document approvals to navigate the position hierarchy defined in Oracle Fusion Human Capital Management, until a specified job level is reached. The position hierarchy must be defined along with corresponding job levels, and the employees must be assigned the appropriate positions.
2.3. Job Levels
Job level routings are based on the supervisory hierarchy defined in Oracle Fusion Human Capital Management. The approval list will be generated based on the starting person specified in a rule and continuing until an approver with a sufficient job level is found. The supervisory hierarchy must be defined along with the corresponding job levels.
3. Understanding Approval Management Extension
Approval Management Extension is a rules engine that enables administrators to organize and author approval routing rules based on numerous seeded document attributes such as requisition amount, ordered amount, price change percent, category etc. Based on your unique business requirements, administrators can choose to send the approval request to approvers in parallel or in sequence. Approvals can be routed up a supervisory chain, position or job level hierarchy, or use a list of approvers. The figure below depicts the key elements that are involved in understanding and setting up approval routing rules.
3.1. Document Approval Request Task
In many end-to-end business processes, human intervention is required such as for approving documents, managing exceptions, or performing activities required to advance the business process. The document approval request task lets you send approval requests to approvers enabling them to make a decision and thus advancing the request-to-pay business process. Both Event Driven and Data Driven configurations must be reviewed and completed for each document approval task before submitting documents for approval.
3.1.1. Event Driven Configuration (Task tab)
The Event Driven Configuration page lets you set up:
• Task Aggregation
a. If the same participant is returned in the same task or stage, you can select a task aggregation setting to reduce the number of tasks the participant receives for the same requisition. The options include:
i. Once per task (default setting for requisition approvals)
• Within the same task, if a participant is returned multiple times based on the approvals rules, then the participant will only receive one worklist task for action or review.
ii. Once per stage
• If the same participant is returned multiple times based on the approval rules within the same stage, then the
participant will receive one worklist task per stage for action or review.
iii. None (default setting for purchasing document approvals)
• No aggregation will be performed.
• Error notification
a. The On Error Notify attribute lets you define an administrator who will be notified when an error occurs in the approval routing process.
• Assignment and Routing Policy
a. Allow all participants to invite other participants
i. Selected by default.
ii. Companies can control if participants can add other approval or
FYI participants in the approval list.
b. Allow participants to edit future participants
i. Selected by default.
ii. Controls if participants can update or remove participants
remaining in the approval list who were not assigned the approval task.
c. Allow initiator to add participants
i. Selected by default.
ii. Deselect to prevent requisition preparers from inserting ad-hoc approval or FYI participants.
d. Enable auto claim
i. Selected by default.
ii. Enabled when a task is assigned to a position, role or a LDAP group. Since there can be multiple users in a position, role, or group, a user has to first claim the task to prevent multiple users
from updating the task. This does not include approvals based on approval groups. Enabling auto claim will not require a participant to first claim before performing an action, hence reducing the number of steps.
• AMX provides the flexibility to include LDAP groups (groups created in the user directory) as participants for approval routing.
e. Complete task when participant chooses Reject or Approve
i. Indicates if the approval task should be completed when a Reject or Approve action is performed by a participant.
ii. The default setting for the requisition approval task is to complete the approval task on Reject.
• Expiration and Escalation Policy
a. Update the expiration and escalation policies to control when tasks should be expired, escalated or renewed.
i. Expiration: If an assignee does not act in the time specified for expiration, the task will be automatically rejected.
ii. Escalation: If an assignee does not act in the time specified for escalation, the task will be escalated to the manager based on the management chain defined in Oracle Identify Management (LDAP), or to another user if a custom escalation java class is used.
a. Maximum escalation levels specify the number of times the task can be escalated if the approver to whom the task is escalated does not act in the time specified for escalation. If the maximum escalation level is reached without any actions, the task will be automatically rejected.
iii. Renewal: You can extend the expiration period when the assignee does not respond within a specified time. The number of times the task can be renewed upon expiration and the duration of each renewal will determine how long the task will remain unexpired.
• Notification Settings
a. Indicates when a user or group is assigned a task or is informed that the status of a task has changed. Notifications can be sent through email, voice message, instant message, or SMS. You can also specify different types of participants to receive notifications for different actions.
b. You can set up reminders to be sent before task expiration or after task assignment.
3.1.2. Approval Rules Configuration (Rules tab)
You can utilize the Configure Task Approval Rules page to create approval routing rules based on your unique requirements using the components (stages, participants, list builder and so on) and attributes delivered by Oracle Fusion Procurement for document approvals.
3.1.2.1. 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 does not 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 is lower or
higher than the dimension of the stage. For example, in a stage with header dimension, rules can be created using line or distribution level attributes. Approval actions within each stage must be completed before entering the next stage if they are in serial.
There can be more than one participant within a stage. Properties set on the participants determine whether approvals would be routed in serial or in parallel. Oracle Fusion 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 and purchase agreements approvals are rule based. Rule based participants are also called rulesets, which is what you would view in the BPM Worklist Application. Approval routing rules are authored within a ruleset. You can create many rules within a ruleset. The following two properties defined on a
Participant are of interest:
• Participant Type – The supported participant types are: Serial, Parallel and FYI. FYI participants cannot 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.
3.1.2.3. Rule
Approval rules are managed under the Rules tab on the BPM Worklist Application’s Administration page. To maintain or review approval rules for a participant, click on the participant name.
Approval Rule Characteristics
An approval rule within a Participant is composed of the following:
- Rule Name
- Condition
- List Builder and List Builder specific attributes
- Response Type
- Auto Action
Approval Rule Name
The Approval Rule Name is used to identify the approval rule.
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 USD and requisitioning BU is US Business Unit.
A condition is defined using attributes seeded in a dimension.
List Builders and List Builder Specific Attributes
A List Builder identifies the type of users needed to approve or receive notification of a document. To add a list builder to a condition, you select the add icon, pick Add Approver to see the menu of list builders that you can add.
The following list builders are supported for document approval and each list builder
has a specific set of parameters or properties that must be defined.
Select the Approval Group to use if you select Approval Group. Approval groups must first be setup under the he Approval Groups tab before you can create an action using the group.
Allow empty groups option determines how the approval task will behave if an approval returned contains no approvers. The approval task will result in an exception if it returns an approval
group with no members when the option is set to False. If the option is set to True, approvals will continue to the next participants if an empty approval group is returned.
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.
Specify the number of levels that are required to perform the approval action if the rule applies. For example to setup the list builder for the policy where requisition amounts that are 1000 USD and below requires approvals from a worker with at least Job Level
3, you will select in the Number of Levels field:
At most 0 relative to absolute
At least 3 relative to absolute
You should always set the value of At most to 0, and use
“absolute” in the relative to option.
The Starting Participant identifies the first participant in a list. The Starting Participant attribute can be set up to:
Be the requester, the preparer or a specific user.
Retrieve the manager of a reference user. For
example, get the manager of the preparer on the
requisition header.
The Top Participant identifies the topmost worker in the management chain, such as the CEO of an organization. Approvals will not be routed beyond this participant.
Utilized Participants indicates if everyone returned in the list of participants from this list builder will be included,the first and last manager from the list will be included, or only the last manager will be included.
Include all managers at last level controls if all holders of the last job level based on the rule will be returned in the approval list. The option should be unchecked.
Specify the Number of Levels required to perform the approval action if the rule applies. For example to setup the list builder for the policy where requisition amounts that are 1000 USD and below
requires approvals from position with at least Job Level 3, you will select in the Number of Levels field:
At most 0 relative to absolute
At least 3 relative to absolute
You should always set the value of At most to 0, and use “absolute” in the relative to option.
The Starting Participant identifies the first participant in a list.
The Starting Participant attribute can be set up to:
Be the position of the requester, the preparer or a specific user.
Retrieve the position of the manager of a referenced user. For example, get the position of the manager of the preparer on the requisition header.
You can use the SQL query below to determine the position hierarchy ID that is used for position hierarchy
based routings. Replace the USERNAME with the username of the person you want to query.
SELECT POSITION_ID FROM PER_ALL_ASSIGNMENTS_M WHERE PERSON_ID = (SELECT PERSON_ID FROM PER_USERS WHERE USERNAME='CVRQST01') AND ASSIGNMENT_STATUS_TYPE (+) = 'ACTIVE'AND ASSIGNMENT_TYPE (+) IN ('E','C','N','P') AND (SYSDATE >= EFFECTIVE_START_DATE AND SYSDATE <= EFFECTIVE_END_DATE)
AND PRIMARY_FLAG (+) = 'Y'
The Top Participant identifies the topmost position in themanagement chain, such as the CEO of an organization. Approvals will not be routed beyond this participant. Utilized Participants indicates if everyone returned in the list of participants from this list builder will be included, if the first andlast manager from the list will be included, or only the last manager will be included.
Specify the Number of levels required to perform the approval action if the rule applies.
The Starting Participant identifies the first participant in a list.
The Starting Participant attribute can be set up to:
Be the requester, the preparer or a specific user Retrieve the manager of a reference user. For
example, get the manager of the preparer on the requisition header.
The Top Participant identifies the topmost worker in the management chain, such as the CEO of an organization. Approvals will not be routed beyond this participant.
The Resource list builder lets you select a user to which approvals is required.
It is not recommended to specify multiple users in the Users field, or to use the Groups or Application Role fields due to upgrade reasons. You can specify a username or use the Procurement
Custom Function in the Users field. If you are specifying usernames and need to include multiple users,
add one Resource list builder per user to the rule.
Response Type
Response Type indicates if the participants are required to approve the task or if they
are FYI participants.
Auto Action
Auto Action Enabled specifies if the list builder will automatically act on tasks. The Auto action value specifies the outcome to be set such as “Approve” or “Reject”. If auto action is disabled, then the auto action value should be updated with ‘null’ (without the quotes).
Rule Name
The rule name field is part of every list builder action added for a rule. This field is used internally by BPM to identify the rule to which the list builder belongs. Populate the field as follows:
Enter the name of the rule without spaces and in quotes
For example, if the name of the rule is Requisition Amount greater than 500,
then the Rule Name field within each list builder action should be
“RequisitionAmountgreaterthan500”.
4. Requisition Approvals Setup
Requisition approvals setup is managed using the Administration pages in the BPM Worklist Application.
To facilitate the approvals setup process for companies, the following policies are available out of the
box for requisition approvals:
- ReqApproval task
- Stages
- Participant
Select the ReqApproval Task to manage approvals for requisition approvals.
The following figure depicts the stages seeded for requisition approvals and the routing sequence of
the stages.
Approvals will be routed to the seeded stages in the following sequence:
1. Header Pre Approval Stage
a. Pre approval stages are used if approvals are required before routing to, for example,
fiscal approvers
2. Header Stage
3. Header Post Approval Stage
4. Post Approval FYI Stage
There are four seeded stages for requisition approvals and within each stage, there are seeded participants. The non FYI participants are seeded as rule based, which lets you pick the list builder (Supervisory, Position, Job Level, Approval Groups) that is applicable for your organization.
Line and distribution level rules can be defined within the stages with header dimension. Refer to Section 6 for more information on how to construct such rules.
1. Header Pre Approval Stage
a. This is used to route requisitions for preapprovals, such as whether the requisition is an emergency requisition.
b. Seeded Participants:
i. Requester FYI
The requester on every line for a requisition will receive a requisition FYI notification. This allows requesters to be notified when a preparer creates a requisition on their behalf. Each requester on every requisition line will be notified. The rule to notify the requester is available out of the box, hence you do not
need to perform additional step for this.
ii. Pre Approval Header Consensus
Approvals are routed in parallel for this participant. This participant is more commonly used in conjunction with approval groups. This participant requires approval from all approvers.
iii. Pre Approval Header First Responder Wins Approvals are routed in parallel for this participant. This
participant is more commonly used in conjunction with approval groups. The first responder to approve or reject will represent the outcome of all remaining approvers.
iv. Pre Approval Header Hierarchy
Approvals are routed in serial for this participant.
2. Header Stage
a. The header stage is often used for fiscal approvals, based on the requisition amount.
b. Seeded Participants:
i. Header Hierarchy
Approvals will be routed in serial. This participant is generally used for supervisory or position hierarchy based routing.
The approvers returned based on all rules that apply in a serial participant will be notified in sequence, even if the rules are evaluated against lines or distributions.
ii. Header Hierarchy 2
Approvals will be routed in serial.
If your organization has a requirement to have a second hierarchy based routing in parallel to the Header Hierarchy participant, rules should be maintained in this participant.
iii. Header Hierarchy 3
Approvals will be routed in serial.
Similar to Header Hierarchy 3, this participant allows another hierarchy based routing in parallel to Header Hierarchy and Header Hierarchy 2 participants.
iv. Header Stage Consensus
Approvals will be routed in parallel for this participant.
This participant is more commonly used in conjunction with approval groups. This participant requires approval from all approvers.
v. Header Stage First Responder Wins
Approvals are routed in parallel for this participant. This participant is more commonly used in conjunction with approval groups. The first responder to approve or reject will represent the outcome of all remaining approvers.
Header Post Approval Stage
a. This is used to route for post approvals.
b. Seeded Participants:
i. Header Consensus
Approvals are routed in parallel for this participant. This participant is more commonly used in conjunction with approval groups. This participant requires approval from all approvers.
ii. Header First Responder Wins
Approvals are routed in parallel for this participant. This participant is more commonly used in conjunction with approval groups. The first responder to approve or reject will represent the outcome of all remaining approvers.
iii. Post Approval Header Hierarchy
Approvals are routed in serial for this participant.
4. Post Approval FYI Stage
a. The Post Approval FYI stage is created to send the requisition preparer a FYI notification on the outcome of the requisition approvals.
b. This stage is not available in the BPM Worklist Administration pages for customization. You do not need to use all of the seeded participants. However, if you do not need to use any of the seeded participants, you simply need to deselect the checkbox for the respective participant in the BPM Worklist Application. The stages should always remain checked even if none of the participants within the stage is used.
The following table shows the participants and their names that are displayed in the Rules tab for
creating approval rules for requisitions.
The table below lists all the attributes within the three requisition dimensions that are available for you
to create approval routing rules for requisitions.
Note: The Type column indicates the type of values that must be provided for the attribute. An attribute may support multiple types of identifier, such as ID, Name or Code. For these attributes, please use the Type listed accordingly. If an attribute does not contain multiple types of identifier, use the actual value for that attribute.
Table 1. Requisition header level attributes
Table 2. Requisition line level attributes
Note: The attribute ReqLineDimension.needByDate is no longer in the list of supported attributes due to future upgrade
compatibility constraints.
Table 3. Requisition distribution level attributes
Note: 1. See Appendix A on how to setup approval rules using Descriptive Flexfields.
2. The attribute ReqDistributionDimension.chargeAccount is no longer in the list of supported attributes due to future upgrade compatibility constraints,
use ReqDistributionDimension.codeCombinationId instead.
4.1. Example: Routing requisitions to project managers
You can use attributes defined on each of the header, line and distribution dimensions in the rule action. To do so, you will need to add the dimensions as part of the rule conditions.
For example, your organization requires a project manager to approve a requisition if any of the distributions contains a project.
• Rule setup in AMX:
If ReqDistributionDimension is ReqDistributionDimension and
ReqDistributionDimension.requisitionLineId is ReqLineDimension.requisitionLineId and
PJCDFFPOR5Requisition is a PJCDFFPOR5Requisition and
PJCDFFPOR5Requisition.PROJECTID isn’t null Then
List Builder = Supervisory
Response Type = Required
Number of levels = 1
Starting Participant =
HierarchyBuilder.getPrincipal(ReqDistributionDimension.projectMgrUsername,-
1,"","")
Top Participant =
HierarchyBuilder.getPrincipal(ReqDistributionDimension.projectMgrUsername,-
1,"","")
Auto Action Enabled = False
Auto Action = null
5. Purchasing Approval Setup
Oracle Fusion Purchasing has provided a task, DocumentApproval, which can be accessed from BPM
Worklist Administration page. The figure below illustrates the stages seeded for purchase order, purchase agreement and their change order approvals.
The figures below illustrate participants seeded within each stage. Note that the participant name conveys both the participant type and the voting regime; for example; Pre Approval (Parallel) First Responder Wins has a participant type of Parallel and voting regime of First Responder Wins which implies that all the approvers will be notified in parallel and the first responder’s decision will be final for that participant
Table below shows the participants and corresponding ruleset names that are visible in the Rules tab
for the approval task in Oracle Fusion Purchasing.
The table below lists all the dimensions and attributes within those dimensions that are available for you to create approval routing rules. These attributes are available in the PurchasingDocumentHeader (for header level attributes), PurchasingDocumentLine (for line level attributes), PurchasingDocumentLineLocation (for schedule level attributes), Requisition Amount (for requisition line level attributes) and PurchasingDocumentDistribution (for distribution level attributes) folder.
Table 4. PURCHASE ORDER AND PURCHASE AGREEMENT HEADER level attributes
Table 5. PURCHASE ORDER AND PURCHASE AGREEMENT Line level attributes
Table 6. PURCHASE ORDER SCHEDULE AND PURCHASE AGREEMENT Price BREAK level attributes
Table 7. PURCHASE ORDER DISTRIBUTION level attributes
6. Business Cases
Business Case 1: Acme Corp Approval Policies
for most facilities and IT services. Any noncatalog service request for these must be routed to
respective category managers for approval. In addition they have set up supervisory hierarchy for
approvals based on requisition amount. The figure below illustrates Acme Corp’s approval policies.
Approach to set up requisition approvals for Acme Corp:
There are two categories for which additional requisition approvals need to come from the category
managers hence create two approval groups:
1. IT Service Category Approval Group
2. Facilities Service Category Approval Group
Rules in Header Hierarchy Participant:
1. No approvals required (such as self approved) for requisitions under or equal to 500 USD.
• Rule setup in AMX:
If ReqHeaderDimension.approvalTotal is same or less than 500 and
ReqHeaderDimension.functionalCurrencyCode is “USD” and
ReqHeaderDimension.reqBuId = 100 Then
List Builder = Supervisory
Response Type = Required
Number of levels = 1
Starting Participant =
HierarchyBuilder.getPrincipal(ReqHeaderDimension.enteredByUsername, -1,
“”, “”)
Top Participant = HierarchyBuilder.getPrincipal(“algreen”, -1, “”, “”)
Auto Action Enabled = True
Auto Action = “APPROVE”
2. One level of supervisory approval required for requisitions more than 500 USD and less than
or equal to 1000 USD.
• Rule setup in AMX:
If ReqHeaderDimension.approvalTotal is more than 500 and
ReqHeaderDimension.approvalTotal is same or less than 1000 and
ReqHeaderDimension.functionalCurrencyCode is “USD” and
ReqHeaderDimension.reqBuId = 100 Then
List Builder = Supervisory
Response Type = Required
Number of levels = 1
Starting Participant = HierarchyBuilder.getManager(“supervisory”,
ReqHeaderDimension.enteredByUsername, -1, “”, “”)
Top Participant = HierarchyBuilder.getPrincipal(“algreen”, -1, “”, “”)
Auto Action Enabled = False
Auto Action = null
3. Two levels of supervisory approval required for requisitions more than 1000 USD and less
than or equal to 2000 USD.
• Rule setup in AMX:
If ReqHeaderDimension.approvalTotal is more than 1000 and
ReqHeaderDimension.approvalTotal is same or less than 2000 and
ReqHeaderDimension.functionalCurrencyCode is “USD” and
ReqHeaderDimension.reqBuId = 100 Then
List Builder = Supervisory
Response Type = Required
Number of levels = 2
Starting Participant = HierarchyBuilder.getManager(“supervisory”,
ReqHeaderDimension.enteredByUsername, -1, “”, “”)
Top Participant = HierarchyBuilder.getPrincipal(“algreen”, -1, “”, “”)
Auto Action Enabled = False
Auto Action = null
4. Three levels of supervisory approval required for requisitions more than 2000 USD.
• Rule setup in AMX:
If ReqHeaderDimension.approvalTotal is greater than 2000 and
ReqHeaderDimension.functionalCurrencyCode is “USD” and
ReqHeaderDimension.reqBuId = 100 Then
List Builder = Supervisory
Response Type = Required
Number of levels = 3
Starting Participant = HierarchyBuilder.getManager(“supervisory”,
ReqHeaderDimension.enteredByUsername, -1, “”, “”)
Top Participant = HierarchyBuilder.getPrincipal(“algreen”, -1, “”, “”)
Auto Action Enabled = False
Auto Action = null
Rules in Header Post Approval Stage – Header Consensus Participant:
1. If category on requisition line is IT service, then approvals from IT Service Category
Approval Group required
• Rule setup in AMX:
If ReqLineDimension.categoryId is equal to 11423; Then
List Builder = Approval Group
Response Type = Required
Approval Group = “IT Service Category Approval Group”
Allow empty group = False
2. If category on requisition line is facilities service, then approvals from Facilities Service
Category Approval Group required
• Rule setup in AMX:
If ReqLineDimension.categoryId is equal to 14125; Then
List Builder = Approval Group
Response Type = Required
Approval Group = “Facilities Service Category Approval Group”
Allow empty group = False
On the approvals rules main page, uncheck the checkboxes for the remaining participants to
disable them.
Rules using distribution level attributes
If your organization policy requires approvals based on requisition distribution level attributes, each
rule using any distribution level attributes must consist of the following condition in order for all
distributions in a requisition to be evaluated:
‘ReqDistributionDimension.requisitionLineId is ReqLineDimension.requisitionLineId’
For example, a rule is created to route the requisition to the cost center manager, Linda West
(username = lwest), if the cost center on a requisition distribution is US100. The rule needs to be set up in AMX as follows:
If ReqDistributionDimension.requisitionLineId is ReqLineDimension.requisitionLineId and
ReqDistributionDimension.costCenter is “US100”
Then
List Builder = Resource
Response Type = Required
Users = “lwest”
Business Case 2: Beta Corp Approval Policies
Beta Corp’s approval policies are driven by spending limits assigned to job levels. In this example, we
will take a look at how spending limits can be modeled using as approval rules.
The following table shows the spending limit assigned to job levels:
Beta Corp also requires all requisitions to be approved by the preparer’s manager, even if the preparer
has the spending limit authority based on the requisition amount.
Rules in Header Hierarchy Participant:
1. Job Level 1 has spending limit of 500.
• Rule setup in AMX:
If ReqHeaderDimension.approvalTotal is same or less than 500 and
ReqHeaderDimension.functionalCurrencyCode is “USD” Then
List Builder = Job Level
Response Type = Required
Number of levels = At most 0 relative to Absolute, At least 1 relative to
Absolute
Starting Participant = HierarchyBuilder.getManager (“supervisory”,
ReqHeaderDimension.enteredByUsername,-1,“”, “”)
Top Participant = HierarchyBuilder.getPrincipal(“algreen”, -1, “”, “”)
Utilized Participants = All Approvers
Auto Action Enabled = False
Auto Action = null
2. Job Level 2 has spending limit of 2500.
• Rule setup in AMX:
If ReqHeaderDimension.approvalTotal is more than 500 and
ReqHeaderDimension.approvalTotal is same or less than 2500 and
ReqHeaderDimension.functionalCurrencyCode is “USD” Then
List Builder = Job Level
Response Type = Required
Number of levels = At most 0 relative to Absolute, At least 2 relative to
Absolute
Starting Participant = HierarchyBuilder.getManager (“supervisory”,
ReqHeaderDimension.enteredByUsername,-1,“”, “”)
Top Participant = HierarchyBuilder.getPrincipal(“algreen”, -1, “”, “”)
Utilized Participants = All Approvers
Auto Action Enabled = False
Auto Action = null
3. Job Level 3 has spending limit of 10000.
• Rule setup in AMX:
If ReqHeaderDimension.approvalTotal is more than 2500 and
ReqHeaderDimension.approvalTotal is same or less than 10000 and
ReqHeaderDimension.functionalCurrencyCode is “USD” Then
List Builder = Job Level
Response Type = Required
Number of levels = At most 0 relative to Absolute, At least 3 relative to
Absolute
Starting Participant = HierarchyBuilder.getManager (“supervisory”,
ReqHeaderDimension.enteredByUsername,-1,“”, “”)
Top Participant = HierarchyBuilder.getPrincipal(“algreen”, -1, “”, “”)
Utilized Participants = All Approvers
Auto Action Enabled = False
Auto Action = null
4. Job Level 4 has unlimited spending limit.
• Rule setup in AMX:
If ReqHeaderDimension.approvalTotal is more than 10000 and
ReqHeaderDimension.functionalCurrencyCode is “USD” Then
List Builder = Job Level
Response Type = Required
Number of levels = At most 0 relative to Absolute, At least 4 relative to
Absolute
Starting Participant = HierarchyBuilder.getManager (“supervisory”,
ReqHeaderDimension.enteredByUsername,-1,“”, “”)
Top Participant = HierarchyBuilder.getPrincipal(“algreen”, -1, “”, “”)
Utilized Participants = All Approvers
Auto Action Enabled = False
Auto Action = null
7. Custom Hook for Document Approval
Organizations have varied and diverse requirements around document approvals. Some of these requirements may include attributes that are not present in the seeded dimension. These attributes may
be captured along with master data such as item, supplier etc, or within other transactions such as projects, or may be captured in some custom tables. Oracle Fusion Procurement provides a custom hook that you could use to author document approval rule conditions using such attribute values or use to fetch users who should be involved in the document approval.
The following is the outline of the custom hook framework:
• Four global java functions, for each of the two tasks mentioned above (ReqApproval and DocumentApproval), that can be accessed while authoring routing. Each function has seven generic string arguments which can be used to pass any meaningful parameters such as item ID, project ID etc. Type casting might be required if using an attribute that is not of String type. You can use <attribute>.toString to pass the attribute as a string parameter. If any of the attributes is not applicable, you can specify NULL as the value for the argument in the function. These functions can be used as part of a rule condition or rule action. When using these functions as part of the action for a rule, select Resource as the list builder.
Table 9. Tasks and Java Functions
- Two functions are provided with the intention of deriving attribute values to be used within conditions and the other two for deriving approval list to be used within list builder. You can access these functions by clicking on the LOV icon while creating rules, then selecting the expression builder icon on the Condition Browser dialog and finally selecting the Functions tab in the Expression Builder dialog.
A PLSQL package containing four functions that are invoked by each of these java functions.
These are listed below. Note that the same PLSQL package and functions are shared between
the two tasks to enable sharing of such approval routing rules.
o POR_CUSTOM_DATA_PROVIDER.GET_CUSTOM_ATTR1(p_arg1, p_arg2, p_arg3,
p_arg4, p_arg5, p_arg6, p_arg7)
o POR_CUSTOM_DATA_PROVIDER.GET_CUSTOM_ATTR2(p_arg1, p_arg2, p_arg3,
p_arg4, p_arg5, p_arg6, p_arg7)
o POR_CUSTOM_DATA_PROVIDER.GET_CUSTOM_ATTR_LIST1(p_arg1, p_arg2,
p_arg3, p_arg4, p_arg5, p_arg6, p_arg7)
o POR_CUSTOM_DATA_PROVIDER.GET_CUSTOM_ATTR_LIST2(p_arg1, p_arg2,
p_arg3, p_arg4, p_arg5, p_arg6, p_arg7)
Note: You should use seeded attributes as much as possible. Excessive usage of custom functions in the conditions section may result in performance issues while documents are submitted for approvals.
The following are few examples where Custom Hook can potentially be used:
• If Project Type is ‘Consulting’ then include the project manager.
o Use getCustomAttr1 java function and pass Project ID. Return ‘Y’ if Project Type on
the Project is ‘Consulting’ in get_custom_attr1 PLSQL function.
o Use getCustomList1 java function and pass Project ID. Return the Project Manager’s
username in get_custom_list1 PLSQL function.
- If Item Type is ‘Outside Processing Item’ then send FYI notifications to all persons specifiedon the item.
- If the UNSPSC Code is ‘26140000’ then include persons in the ‘Nuclear Equipment Approval Group’
8. Considerations
1. Rules using translatable attributes, such as Requisitioning BU or UOM, can be defined using codes or IDs – see above tables on whether an attribute is supported as codes or IDs. This streamlines rule definitions without requiring you to specify each and every language translation in a rule. IDs can be looked up in the database tables.
For example, use below query to get Requisitioning BU ID:
select req_bu_id from por_requisition_headers_all where requisition_header_id = <requisition_header_id>;
2. For amount specific approval rules you should either include the requisitioning business unit in the condition along with specifying the approval amount in the functional currency of the requisitioning business unit (optionally include the functional currency) or, you should use the currency conversion rate function.
If FunctionalCurrencyApprovalTotal is same or less than 500 and FunctionalCurrency is “USD” and
SoldToBuID is 204 Use the following currency conversion rate function to convert the amount in document
currency to the amount in the approval rule currency:
If DocumentCurrencyApprovalTotal * CurrencyConversionGlobal.getRate(DocumentCurrency, "USD",
ConversionRateDate, DocumentConversionRateType, LedgerId) is same or less than 500
Note: The entire path of the attribute is not shown in the above examples.
3. For each participant that is in use, at least one rule must apply when a document is submitted
for approvals. AMX does not auto approve if the document attributes do not meet the
conditions of any of the existing rules within a participant.
a. Example 1: You use the Header Hierarchy participant to set up rules based on
requisition amounts with the following conditions:
i. Requisitions more than 500 USD and under 1000 USD requires 1 level
ii. Requisitions more than or equal to 1000 USD and under 2000 USD requires
2 levels
iii. Requisitions more than or equal to 2000 USD requires 3 levels
This means that requisitions under or equal to 500 USD does not require approvals.
In this case, you will need to create a rule to automatically approve by the requisition
preparer.
b. Example 2: You use the Pre Approval Header Consensus participant to set up rules
based on categories on the requisition line. You need additional approvals routed for
the following two categories:
i. IT Equipment
ii. Office Furniture
You must add an auto-approval rule for the remaining categories in this participant.
c. Example 3: You use the Pre Approval Header Consensus participant to set up rules
based on smart forms on the requisition line. You need additional approvals routed
for the following smart form:
i. Work Visa Request
• Condition: If ReqLineDimension.noncatalogRequestTemplate is not null and ReqLineDimension.noncatalogRequestTemplate is 1234
a. Make sure to add a condition to check that the attribute is not null. This applies to all rules using attributes in a document that may contain no value.
Since not every requisition line will have a smart form associated, you must add an
auto-approval rule for the following:
i. If (ReqLineDimension.noncatalogRequestTemplate is not null and is not 1234) or ReqLineDimension.noncatalogRequestTemplate is null
d. How to setup an auto-approval rule:
- Set the condition as: If 1 is 1; Then
- List Builder = Supervisory
- Response Type = Required
- Number of levels = 1
- Starting Participant = HierarchyBuilder.getPrincipal(“supervisory”,
ReqHeaderDimension.enteredByUsername, -1, “”, “”)
- Top Participant = HierarchyBuilder.getPrincipal(“supervisory”,
ReqHeaderDimension.enteredByUsername, -1, “”,“”)
- Auto Action Enabled = True
- Auto Action = “APPROVE”
4. All approvers returned within a participant that is routed in serial will be ordered and notified
in sequence.
a. For example the following rules are evaluated to true in the Header Hierarchy participant for a requisition with 2 lines:
- Line 1 satisfies rule 1: If requisition line belongs to the IT category and amount is less than 500 USD, then approval is required from the IT Manager and IT Director.
- Line 2 satisfies rule 2: If requisition line belongs to the Facilities category and amount is greater than 1500 USD, then approval is required from the Facilities Manager and Facilities Director
In this case, within the Header Hierarchy participant, approvals will be routed in the following order:
IT Manager IT Director Facilities Manager Facilities Director
If your organization has a need to route a document for approvals to more than one
hierarchical path concurrently, you should use more than one serial based participant. You
can use Header Hierarchy, Header Hierarchy 2 and Header Hierarchy 3 participants in the
Header Stage to maintain your rules based on your organization’s requirements.
5. Only one rule within a participant with first responder wins voting regime within a participant
should evaluate to true for a given document.
a. If more than one rule applies within a first responder wins participant, the approvers by each rule will be grouped together where only one response from this group will determine the approval outcome
1. For example, within the Header First Responder Wins participant:
a. The following rules are defined
i. Rule 1 would include approvers from the IT Approval
Group if a requisition contains a line from the IT category
ii. Rule 2 would include approvers from the Legal Approval
Group if a requisition contains a line from the Legal
category
b. If both conditions are met and the two rules are triggered, then approvers from both the IT Approval Group and the Legal Approval Group will be returned. However, if an approver from the IT Approval Group approves the requisition, this participant is considered approved, and no actions would be required from the Legal Approval Group.
2. To satisfy the requirement where at least one rule must apply within a participant, you can set up a rule to use an empty approval group rule for the conditions where no approvals are required in a first responder wins participant. This option will ensure that the participant does not get autoapproved in the event where the document contains objects that satisfy both rules that require approvals and rules that do not require approvals. Using the supervisory hierarchy based auto-approval option would be treated as an approval response for the participant, hence bypassing the other rules that actually would require approvals.
• Auto-approval rule using an empty approval group
o Set the condition as: If 1 is 1; Then
o List Builder = Approval Group
o Response Type = Required
o Approval Group = “No Approvals”
This group has to be created in the Approval Groups tab without any participants specified
o Allow empty group = True
- You can utilize the first responder wins based participants across the different stages
if your organization requires different groups of approvers to provide approvals
independently.
1. Using the same example above,
a. Rule 1 can be added to the Pre Approval Header First Responder Wins participant
b. Rule 2 can be added to the Header Stage First Responder Wins participant
c. A response from Pre Approval Header First Responder Wins participant will be required from the IT Approval Group. And a separate response from the Header Stage First Responder Wins participant will be required from the Legal Approval Group.
9. Document approvals in Oracle Fusion Procurement
Once document approvals are set up, users can review approvals generated based on these rules before
the document is submitted. Users can also insert additional approvers or FYI participants if necessary.
The approvals list is displayed in both tabular and graphical layouts.
Upon submission of the document, approvals are triggered and the document will be routed to
approvers or FYI participants for review and action through the BPM Worklist application. Approvers
and FYI participants can also be notified through other methods, such as email, SMS, or voicemail,
depending on your setup. Submitters can view the approvals progress and status for submitted
document. Application stores every action performed by a user on a document including who
performed the action and when it was performed.
10. Approval Notifications
10.1. Worklist Task
Approvers can access worklist tasks for documents pending their disposition with Fusion applications. The actions that the approver can perform on the worklist tasks are:
- Reassign or Delegate tasks
o The reassign action transfers the task to another user or group. The task will then be routed based on the specified user’s hierarchy.
o The delegate action allows another user to act on your behalf
- Request information from the preparer, a previous approver or another user in the enterprise
- Approve or Reject the task
- Add attachments to the worklist task
- Add comments to the worklist task
- Insert additional approvers to the approval task
- Modify a requisition if the approver has the privilege to edit requisitions pending his approval
10.2. Email notifications
When an approval task is sent out as an email, it contains only key information to help the
approver make his approval decision. The approver can approve or reject via email
response. To perform other actions, the approver should access the worklist task within
Fusion applications.
11. Conclusion
Oracle Fusion Procurement provides a highly flexible and robust rule based engine to author your
unique document approval routing policies and manage them effectively. It also provides full visibility
of future and current approvers and a comprehensive audit trail of actions performed on a document is
captured by the application.
The above document is an Oracle White Paper if you have metalink Id you can download the above document directly from Oracle Knowledge Base.
Thaks & Regards,
S.Grace Paul Regan