Oracle Cloud ERP - Financial Approval Workflow Best Practices

Financial Approval Workflow
Configuration in ERP: Best

Practices, Tips and Tricks
Gabriela Patrascu
Customer Support Manager, Fusion Financials
1 Copyright © 2019 Oracle and/or its affiliates.

Agenda
I. Best Practices for a Successful Approval Flow
1. Best Practices, Tips and Tricks for Approval Routing
2. Best Practices, Tips and Tricks for Approval Rules Definition
3. Best Practices and Tips for migrating the rules from one instance to another
4. Best Practices and Tips for Approval Notifications
II. What’s New from R13 for Approval Workflow
III. Q&A
Copyright © 2019 Oracle and/or its affiliates.

I. Best Practices for a Successful Approval Flow
Before creating any rules in the application there are three most important points
that should be taken into consideration in order to have a successful approval flow:
 BusinessNeeds
 Maintenance of Rules and the Impact of Changes
 Performance issues and errors that can arise if rules are not configured properly

1. Best Practices, Tips and Tricks for Approval Routing
Taking into consideration the Business Needs the first thing that should be decided is the Approval Routing, who are the approvers,
how many, how are they structured in the organization (are they having the same job levels, same positions) as based on this the
correct routing for your approval flow can be decided.
Figure 1: Approval Routing  Supervisory/Management Chain- business will need to have approvals from specific
number of persons up to the hierarchy of the Creator/ Submitter of the transaction. It is
very important to determine correctly the starting point for hierarchy in order to have a
successful routing.
Supervisory/Man Job Level Figure 2: Example for Supervisory Routing using Creator or Submitter as starting point
agement Chain /Position
Approval
Group Resource
Best Practice: Every employee should have assigned in Manage Users (Navigator->Setup and Maintenance->Manage Users) the
manager in order for the process to be able to find the hierarchy and avoid errors.

Example of Common Issues ,Best Practices and Tips to avoid them:
Duplicates usernames are available in the application and approval flow is not able to
“The supervisor or Job level does not exist. identify which user hierarchy to use.
(FUN-720337)
Cause The list builder used in the configuration
Approval State: Error
of approval rule is not coherent with the HCM
Supervisory or Job level hierarchy. Approval Status: Required
Action Correct the list builder definition in
approval rules or HCM employee supervisory Tip: Following query can be used to see if there are multiple users having the same
hierarchy or Job level hierarchy.” username:
SELECT USERNAME , COUNT(USERNAME ) FROM fusion.per_users GROUP BY
USERNAME HAVING COUNT(USERNAME )>1;
Duplicate user can be removed using SCIM REST API : Fusion Security: Using SCIM
REST API (Doc ID 2346455.1)
Starting Participant is set to Task.Workflow Submitter and Auto Post process is run
automatically by a dummy user which is not employee so it is not defined in Manage Users
or it is set to Journal Batch.Created By but the user does not have any Manager assigned in
Manage Users so the approval will error :
“Check the underlying fault. Check target SOA
Approval State: Error component for cause.
Approval Status: Required (transaction will be withdrawn by sistem) oracle.fabric.common.FabricBusinessFaultExce
ption
Action: Assign the employee manager in Manage Users, for AutoPost/Initiate Workflow for oracle.j2ee.ws.client.jaxws.JRFSOAPFaultExce
ption: Client received SOAP Fault from server :
Invoices scenario change the Starting Participant to look for Creator/Requester/Owner of the
JBO-56012: SQLException from preparing or
transaction and not submitter. executing sql statement with original Jbo error
code JBO-27122. Please contact service
Note: From R13.19C there is a new feature available in Auto Post screen that will show provider on details.”
the Auto Post process submitted by the person that created the journal if the check is flagged.

Routing for approval to an Inactive User. Possible comments in Alerted Tasks:“
When transactions are routed to an Inactive user “Error in workflow service Web “Error on escalating the task on expiration. The task has expired
those will not go in error state but: service operation invocation. and the system could not compute the management chain for
Verify that the SOAP connection user xyzw up to levels 2 up to title Manager to identify the next
Approval State :Assigned information for the server is user to escalate the task to. Make sure the escalation policy is
Approval Status : In Process correct.Error occurred while
specified correctly. Also verify that the users are seeded correctly
displaying the tree table.”
->no Approve/Reject action will be possible on the to compute the management chain.”
transaction.
This can happen when Maximum Escalation Levels is set for
Action: Withdraw the transaction, correct the rule example to 2 and Highest Approver Title to Manager, because it
in order not to be routed to an inactive employee will look to escalate the task to 2 levels having title as Manager
and resubmit for approval. and as the manager for user gabriela.patrascuMGR@oracle.com
is gabriela.patrascuDIR@oracle.com with Director title the
approval will go in Alerted state.
Escalation or Expiration is enabled and the hierarchy is

not set up as expected for users in Manage Users .
Figure 3. Escalation Settings that can
Approval State :Alerted Figure 4. Task assigned to Manager
cause issues
Approval Status : In Process
Action: Withdraw the transaction, correct the Escalation

settings and resubmit.
Tip: Exact details on why the task went to alerted state can
be see in BPM->Alerted Task->Comments section
Best Practice: While defining Escalation use Maximum

Escalations Levels OR Highest Approval Title and not
both as those can lead to alerts.

Figure 5. Alerted task with Comments Figure 6. Users details from Manage Users and Manage Job
Tasks can go in alerted state also when Starting Point for hierarchy is not identified
anymore .
Most common scenario is when the username was changed between the moment when
the journal was created and when the transaction was submitted for approval.
” Error in routing slip. The task is assigned to an invalid user S_C in realm jazn.com. The
routing slip is associated with the task definition
default/FinApInvTransactionsInvoiceApprovalComposite!
18100755_29112091/FinApInvoiceApproval. Verify that the user is specified correctly in
the routing slip in the task definition.”
Best Practice: Do not modify usernames as this can seriously impact the approval flow
and not only.

 Approval Group- when there is no specific pattern that can be used to route for approval like specific job levels/hierarchy/role then
Approval Groups can be created to add specific persons to route the transaction for approval.
Empty Approval Group
Tip: Enable the Allow empty group in

order to avoid the transaction to go in
alerted state, with this flag checked the
transaction will go in completed and
approval status will be again in
Required state.
Approval Group was deleted

or name was changed
Tip: While exporting the rules from one instance and importing those to
Best Practice: If you change the Approval Group name in another one, you need to make sure the Approval Group names are the
Approval Groups it will not be automatically changed in the rules same in both instances or manually modify them in the new instance
so once you modify it or delete go to rules select the new approvalafter import in order to avoid the transactions to go in alerted state as the
group. group will not be found.
 Job Level/Position-transaction is routed for approval based on job levels or positions based on the supervisory hierarchy continuing
until an approver with sufficient job level is found.
Figure 7. Example of Job Level routing
Best Practices: Make sure the jobs/positions are defined correctly in

Manage Jobs/Manage Positions and that the job is assigned to
employees in Manage Users in order for the approval to be able to
compute the approval chain.
Tips:
Starting Participant: This will be the 1st participant for approval and
is not affected by any other condition like at-least, at-most, Top
Participant. When using getManager – using supervisory is equivalent
to using joblevel as joblevel references the supervisory hierarchy.
Top participant: If this participant comes in approval flow (and not
skipped), then approval request will not go beyond this participant. It
cannot be overridden by AT LEAST condition.
If the Manager assigned in Manage Users for the Invoice Requester has any
other job level than 6 the approval will go into error as it will look for the
supervisory of the Invoice Requester having Job Level at least 6 with at
most 6 so it will take into consideration only job level 6.

 Resource - this is used when there will be a unique approver or when the routing is based on a specific role.
Figure 8. Configuration Tab
” Error in routing slip. The task

is assigned to an invalid user
S_C in realm jazn.com…”
Best Practice:
Do not modify the usernames as the approval flows are not automatically changed
once you change the username and this can cause approval errors.
For role routing use Custom Roles to have an appropriate routing based on business
scenario and assign those to the users that should approve the transaction.
Tips & Tricks: Enable “Skip Creator for Approval List” in Configuration Tab from
the specific task and/or Assign to Creator’s Manager in order to avoid the creator to
be able to approve his own journal if he has the role to which the approval is routed.
The same applies to Approval Group as well.
If Auto-Claim is enabled everyone having the specific role will see the transaction in
“Requiring My Approval” otherwise one of the approvers will need to claim it first in
order to be able to see it in “Requiring My Approval” and available for the creator in
“Pending Approval from Others”.

CONCLUSIONS FOR BEST PRACTICES APPROVAL ROUTING
 Assign Managers to employees in Manage Users if you are using Hierarchy routing
 Make sure users are active
 Do not modify usernames once defined
 Use Maximum Escalations Levels OR Highest Approval Title for Escalations
 If you change Approval Group names you need to modify them in the rules as well as this is not done automatically
 Enable “Skip Creator for Approval List” is you want to avoid creator of the transaction to approve his own transaction if he is part
of the approval flow
TIPs& TRICKs: Workflow rules are not checking the privileges assigned in roles so even if an user has only Employee and
Financial Analyst role which is Read Only (user will not be able to edit the journal in UI) and the approval is routed to him as he is
part of an approval group/supervisory/job level etc he will be able to take action-Approve/Reject the transaction.

2. Best Practices, Tips and Tricks for Approval Rules Definition
 Always define the Approval rules in Advance Mode if conditions are at line level/distribution level/
expense item level and use Surround in order to avoid approval going into error with timeout error for “The journal/invoice approval process has
stopped due to a system error. Contact
transactions with big number of lines your help desk. (FUN-720342).Unable to
invoke endpoint URI
"http://fa-
Example of rule in Advance Mode using Distribution Level in Invoices internal.oracleoutsourcing.com:10663/fsc
mService/JournalApprovalBCService"
Figure 9. Example of Rule in Advance Mode for PO/Non PO Match in successfully due to:
Invoices javax.xml.soap.SOAPException:
javax.xml.soap.SOAPException: Message
send failed: Read timed out after 300sec.”
Use the Surround->None/At least

One/Each to minimize the number of
checks.
->None ->at the moment when it finds the first line that has a PODistributionID null and Lookup is ITEM it will stop, will not
go through all the lines.
->At least one, once it finds the first distribution line matching the condition the iteration stops.
Example of rule in Advance Mode using Line Level in Journals
Figure 10. Example of Rule in Advance Mode using Account Combination
YES in Journals
Tip: If you need to verify a specific segment and route for approval
based on it always use Account Combination or Concatenated Segment
as in the example and not the COA structure as this can cause
performance issues and produce timeout errors.
Example of rule in Advance Mode using Expense Item

in Journals
NO

 Always make sure all scenarios are covered when defining the rules in order to avoid errors, for example if you have 3 cost centers and
individual rules are defined for each of them, a catch all rule is still needed for the situation when none of those cost centers are used in the
transaction.
 If you are using in the rules standard attributes defined by application like Sources/Categories/Types make sure you use .toUpperCase() or
.toLowerCase() .
 If you are using other languages too make sure you add the names for like Sources/Categories/Types in other languages also
Figure 11. Example of Rule with Upper Case and condition for different languages
 If you are using in the approval flow attributes that are not mandatory in the transaction like Invoice Requester before adding the condition is
recommended to add one condition to check if the field is empty or not in order to verify first this condition.
Figure 12. Example of Rule with Requester Name

 While using IDs is recommended to use in condition .longValue() is new Long("300,000,000,974,009") as the ids are having 15 digits
Figure 13. Example of Rule using .longValue()
 It is recommended not to change the Vote Outcome for Stages but if you really need to modify it, please test it accordingly to make sure it
satisfy your needs (Example: 2 stages ->1 AutoApprove ->One with approval required ->50% Vote Outcome)
The error below will be seen if Default Outcome for Voting is changed to By Expression instead of Approve/Reject without adding an expression.
Usually the Vote Outcome is set to 100% Approve/Reject

“System error in evaluating
routing slip. A system error
Figure 14. Example of Vote Outcome
occurred in evaluating the
routing slip.
The error is Error in routing slip.
Error in evaluating parameter
forEach/defaultOutcome in the
routing slip.”

Tips on what to verify when approval is in error
1. Verify if the stage is enabled 2. Verify if participant is enabled
Figure 15. Stage details for enablement Figure 16. Participant details for enablement
3. Check if the rule that should evaluate for the transaction is enabled
Figure 17. Rule details for enablement
4. If all of them are enabled, check if the conditions in the rule are matching
your transaction
5. If the conditions are matching your transaction you can try to remove one
by one and retest or open an SR with Oracle Support to investigate further.
3. Best Practices and Tips for migrating the rules from one
instance to another
• Composite instance versions should be the same in both instances
1
• Import only the composites where you have added rules

2
• If COA attributes are used in the rules make sure same KFF name is used in both instances as in the libraries it will always look for the KFF name that was available in source system
and it will not be possible to change it in target instance
• ->workaround would be to create the same Flex Structure in the environment where the rules were imported
3 • ->restore the base version on target environment which will need approvals and development review as script is needed
“Caused by: oracle.rules.rl.exceptions.UndefinedException: The symbol

"oracle.bpel.services.workflow.task.model.FinGlJournalApprovalRules.TestIn
stanceCOA" is undefined.
at line 107 column 14 in /Ruleset(main)
at
oracle.rules.rl.exceptions.ExceptionFactory.createUndefinedException(Except
ionFactory.java:409)”

4.Best Practices and Tips for Approval Notifications
• 1. Best Practices
• If users want to withdraw the transaction from • Withdraw can be done from BPM also
• Withdraw transaction from Notification this should be done from first and in here as well it is recommended to
UI especially when parallel notification received that is the Submission one do it from the first notification received if
assignment is in place which does not contain assignees as otherwise it will you need to withdraw the entire
withdraw only the notification assigned to that transaction and not just one notification
person and not the entire transaction
Withdraw from UI Withdraw from Notification Withdraw from BPM
Figure 18. Notifications assigned in parallel
If you withdraw from any other task than the base

one (213202) it will withdraw only the
notification for that user and not the entire
transaction so you will need to withdraw all the
Figure 19. Withdraw from BPM notification form last task 213206 notifications or withdraw directly the base task.

Figure 20. Notification Mode
• 2. Tips
2.1 What to verify when notifications are not received
a) Verify in Administration tab from BPM (Bell Notifications->More Details->Administration)

if “Notification Mode” is set to All or Email if you need only emails
b) Verify for the specific task Figure 21. Notifications->Task Status->Assign

FinFlJournalApproval/FinApInvoiceApproval/FinExmWorkflowExpenseApproval in
Notifications tab if the notification is defined for Task Status: Assign
c) If a and b are fine go back to Administration tab and add your email address available in
the system on which you should receive the notification to “Test Notification Email Address
“ and if you still don’t receive the notification, add in a different email address to see if you
receive the notification on another address
If while using a different email and not the company one you are receiving the notification
this means there might be some restrictions at your company server level or outlook
conditions and you will need to check with your IT team as from Oracle the notifications are
sent.
! Please remove the Test Notification Email Address once the test is completed.

• 2.2 What to verify if notifications are received but no action buttons are available
 Verify for the specific task

FinFlJournalApproval/FinApInvoiceApproval/FinExmWorkflowExpenseApproval in
Notifications tab ->More if “Make notification actionable “ is enabled and “Make
notifications secure” is disabled
 Task Status : Assign ->Edit should contain null and not “null”.
Figure 23. Task Status->Assign->Edit
Figure 22. Make notification actionable and Make notifications secure

• 2.3 What to verify if multiple notifications are received for the same transaction
Go to specific task FinFlJournalApproval/FinApInvoiceApproval/FinExmWorkflowExpenseApproval and in Configuration Tab verify if Task Aggregation is set to None and set
it to Once per Task (in the same task if the participant is returned multiple times then the participant will only receive one worklist task for action or review) or Once per Stage (in the same
task if the participant is returned multiple times within the same stage then the participant will only receive one worklist task per stage for action or review)
Figure 24. Task Agregation

• R13.17D-18A-18B-19A - Configurable Email Notification (Journal/Invoice/Hold/Payment/Expense Report/Expense Reimbursement/Expense Audit and Receipt
Management/Cash Advance---Intercompany/Invoice Account Coding Notification/Expense Audit Info Request/Receipt Received/Receipt Overdue/Cash Advance Rejected by
Auditor/Cash Advance Paid by Check Notification/Cash Advance Paid by Direct Deposit---Budgetary Control Override Requests---Bank Transfer Approval Notification)
Figure 25. Modified Layout ReportTemplate
1. Prerequisites:
a) Sign in with application consultant job
b) Download BI Desktop and install
2. Download the Report Layout Template
3. Copy and Modify the Data Model
4. Export Data Model with sample data
5. Edit the Report Layout Template
6. Upload the Modified Report Layout Template

Figure 26. Email notification before changes
Figure 27. Email notification after changes

• R13.18C- Simplified Workflow Rules Configuration
Figure 28. Example of Simplified Workflow Rules for Journals
Figure 29. Stages created based on Approval Routing
Based on the Approval Routing you select the Participant

Type would be created in the Application, in this scenario, the
first set of rules contains Supervisory so the Stage will be
Serial Type Participant, the second set of rules contains
Approval Group in Parallel so the Stage will be Parallel
Type Participant and the third set of rules contains Group
First Responder Wins so the Stage will be Single Type
Participant.

Figure 30. Some of the rules created in the application
Tip: If you will add to rules in the same block Group

in Serial and Group in Parallel in the the upload will
go into error as the system cannot find the type of
participant you want to use.

Figure 31. Example of Simplified Workflow Rules for Invoices
Figure 33. Participants created This is Requester one

Figure 32. Data Sets for Job Level vs Amount

Figure 34. Rule 1 created from spreadsheet

Figure 35. Output of the Approval Groups Report
- Approval Groups Report
Navigator->Schedule Processes-
>Approval Groups Report no
parameters are needed as it will list all
the groups.
The Approval Group Report can be
seen in xlsx or xml.
Figure 36. Output of the Workflow Rules Report

- Workflow Rules Report
Navigator->Schedule Processes->Workflow
Rules Report ->in parameters select
Invoices/Journals or Expenses and Submit
Rules can be extracted in xlsx or xml.
You can use this report to see your rules from
period to period and if those were modified.
This report can be scheduled as any other BI
report.

• R13.19C-Workflow Transactions Listing Report and Payables Workflow
Transactions Listing (Invoice Account Coding)
Figure 38. Output of the Workflow Transactions Listing Report for Pending Transactions
Navigator->Schedule Processes->Workflow Transactions
Listing (Lists transactions that are pending or rejected in the
workflow)
Report can be seen in xlsx or xml.
Figure 37. Output of the Workflow Transactions Listing Report for Rejected Transactions

• Use Batch Creator as Approval Submitter in AutoPost Criteria
In History and Notification will show

sent for approval by the person that
created the journal even if the AutoPost
was run by another user. Figure 42. AutoPost Process run by different user than creator of journal
Figure 40. AutoPost Criteria Set with “Use Batch Creator as Approval Submitter”
Figure 43. Notification showing from creator and not from submitter
Figure 41. AutoPost Process run by different user than creator of journal

• Synchronize Transaction Workflow Status
Navigator->Schedule Processes->Synchronize
Transaction Workflow Status (This process
ensures that the workflow status is updated
correctly in SOA and Oracle Fusion
Applications.)
->2 options: View Transaction Workflow
Status or Synchronize Transaction Workflow
Status.
Figure 44. Output of the Synchronize Transaction Workflow Status for View
1.Run the report for View Transaction Workflow Status to see the stuck transactions
Figure 45. Output of the Synchronize Transaction Workflow Status for Synchronization
2. Run the report for Synchronize Transaction Workflow Status to update the status
in the application or withdraw the transaction

Thank You
Gabriela Patrascu
Executive Vice President

Applications & Product Development

Session Survey
Help us make the content even

better. Please complete the
session survey in the Mobile
App.

Safe Harbor
The preceding is intended to outline our general product direction. It is intended for information purposes only,
and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or
functionality, and should not be relied upon in making purchasing decisions. The development, release,
timing, and pricing of any features or functionality described for Oracle’s products may change and remains at the
sole discretion of Oracle Corporation.
Statements in this presentation relating to Oracle’s future plans, expectations, beliefs, intentions and prospects are
“forward-looking statements” and are subject to material risks and uncertainties. A detailed discussion of these
factors and other risks that affect our business is contained in Oracle’s Securities and Exchange Commission
(SEC) filings, including our most recent reports on Form 10-K and Form 10-Q under the heading “Risk Factors.”
These filings are available on the SEC’s website or on Oracle’s website at http://www.oracle.com/investor. All
information in this presentation is current as of September 2019 and Oracle undertakes no duty to update any
statement in light of new information or future events.

Oracle Cloud ERP - Financial Approval Workflow Best Practices

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle Cloud ERP - Financial Approval Workflow Best Practices

Uploaded by

Copyright:

Available Formats

Financial Approval Workflow

Configuration in ERP: Best

Customer Support Manager, Fusion Financials

1 Copyright © 2019 Oracle and/or its affiliates.

I. Best Practices for a Successful Approval Flow

1. Best Practices, Tips and Tricks for Approval Routing

2. Best Practices, Tips and Tricks for Approval Rules Definition

4. Best Practices and Tips for Approval Notifications

II. What’s New from R13 for Approval Workflow

Copyright © 2019 Oracle and/or its affiliates.

Copyright © 2019 Oracle and/or its affiliates.

Copyright © 2019 Oracle and/or its affiliates.

Copyright © 2019 Oracle and/or its affiliates.

Escalation or Expiration is enabled and the hierarchy is

Action: Withdraw the transaction, correct the Escalation

Best Practice: While defining Escalation use Maximum

Copyright © 2019 Oracle and/or its affiliates.

Copyright © 2019 Oracle and/or its affiliates.

Empty Approval Group

Tip: Enable the Allow empty group in

Approval Group was deleted

Best Practices: Make sure the jobs/positions are defined correctly in

Copyright © 2019 Oracle and/or its affiliates.

” Error in routing slip. The task

Copyright © 2019 Oracle and/or its affiliates.

Copyright © 2019 Oracle and/or its affiliates.

Use the Surround->None/At least

Example of rule in Advance Mode using Expense Item

Copyright © 2019 Oracle and/or its affiliates.

Copyright © 2019 Oracle and/or its affiliates.

Figure 13. Example of Rule using .longValue()

Usually the Vote Outcome is set to 100% Approve/Reject

Copyright © 2019 Oracle and/or its affiliates.

• Import only the composites where you have added rules

“Caused by: oracle.rules.rl.exceptions.UndefinedException: The symbol

Copyright © 2019 Oracle and/or its affiliates.

Withdraw from UI Withdraw from Notification Withdraw from BPM

Figure 18. Notifications assigned in parallel

If you withdraw from any other task than the base

Copyright © 2019 Oracle and/or its affiliates.

a) Verify in Administration tab from BPM (Bell Notifications->More Details->Administration)

b) Verify for the specific task Figure 21. Notifications->Task Status->Assign

Copyright © 2019 Oracle and/or its affiliates.

 Verify for the specific task

Figure 23. Task Status->Assign->Edit

Figure 22. Make notification actionable and Make notifications secure

Copyright © 2019 Oracle and/or its affiliates.

Figure 24. Task Agregation

Copyright © 2019 Oracle and/or its affiliates.

Figure 25. Modified Layout ReportTemplate

2. Download the Report Layout Template

3. Copy and Modify the Data Model

4. Export Data Model with sample data

5. Edit the Report Layout Template

6. Upload the Modified Report Layout Template

Copyright © 2019 Oracle and/or its affiliates.

Copyright © 2019 Oracle and/or its affiliates.

Figure 29. Stages created based on Approval Routing

Based on the Approval Routing you select the Participant

Copyright © 2019 Oracle and/or its affiliates.

Tip: If you will add to rules in the same block Group

Copyright © 2019 Oracle and/or its affiliates.

Figure 33. Participants created This is Requester one