Last updated on DECEMBER 20, 2016
Applies to:Oracle Approvals Management - Version: 12
Information in this document applies to any platform.
Oracle Consulting have implemented a GL Journal Approval process utilising AME and have created a workflow as per the developers guide (master process that calls getnextapprovers4, spawns a child process for each returned approver and then blocks, waiting for a child process to complete with approve or reject to wake up the master process).
AME is configured for the transaction type with Repeat Approvers = Once per Transaction.
The AME configuration is such that a user can exist in multiple approval groups that are included in a parallel approval stage.
Configuration is as follows:
Journal requires 3 parallel approval groups - GRP1, GRP2, GRP3.
Approver ORG1B is in GRP1 and GRP2
Approver ORG2A is in GRP1, GRP2 and GRP3.
When calling the getnextapprovers(n) for the first time, receive the correct list of approvers to notify -- one for ORG1B, one for ORG2A. If calling getAllApprovers7 after this to see the full list, can see that the approval_status is set to NOTIFIED once for each approver for a chosen approval group. Additional records show approval_status of NOTIFIEDREPEATED for the other associated approval groups. This is as expected.
When ORG1B approves the notification, inform AME with a call to ame_api2.updateApprovalStatus2 (ORG1B). If now calling getAllApprovers7 to see the approval list, can see that the ORG1B approval status is set to APPROVE and APPROVEREPEATED. ORG2A has one record set to BEAT BY FIRST RESPONDER. The remaining ORG2A records have an approval_status of null. So when next calling getNextApprovers (as per the dev guide), the procedure returns a number of (5) duplicate ORG2A approvers.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms