I got a very interesting requirement from a customer. The requirement was to customize the flow of Requisition and PO approval. The TO-BE process is given below.
| Process | Comments |
| Approvers in the Requisition/PO hierarchy are given an alternate approval group. | This was done by enabling a DFF |
| User raises Requisition/PO | Standard process |
| User sends the document for approval | Standard process |
| The Requisition/PO workflow will check the amount of the document and a field value that will determine whether document was raised for an existing contract or not. | A DFF segment was enabled for Requisition and PO header. |
| The document will go to the approver | Standard process |
| The approver approves the document | Standard process |
Oracle checks whether the approved document is for an existing contract or not.
| This is a major customization. We had to create custom PL/SQL code to bypass the usual approval check.The seeded Requisition and PO workflows were customized to incorporate the custom approval authority check. |
| Depending on the previous check the workflow will go to the next approver or end. | Standard process |
The development process is given below. I have illustrated the development and testing done for Requisitions. The same was applied to PO as well.
Configuration & Development
DFF setup
Approval Group Assignment DFF
We have enabled the DFF segment on the Approval Group assignment form.
Responsibility: System Administrator
Navigation: Application > Descriptive > Segments
Query for,
Application: Purchasing
Title: Position Controls
Click on Segments
Add an entry for a segment.
Number: 10
Name: EY Alternative Approval Group
Window Prompt: EY Alternative Approval Group
Column: ATTRIBUTE1
Value Set: EY_PO_CONTROL_GROUP_VS
Double click on the segment to open the Segments window
Ensure that Required field is unchecked. Click on Value Set button to open the value set.
This Validation Type is Table. Click on Edit Information button.
As we can see, the value set is pulling the records from PO_CONTROL_GROUPS_ALL table. This means the value set is going to display the Approval Group names that are defined for a particular operating unit.
Save and close all forms. Ensure that the DFF is also compiled.
Requisition Header DFF
We have enabled a segment on Requisition Headers as well. This DFF value will determine whether a contract/tender is required for the requisition raised or not.
Open the DFF form and query for the DFF as follows,
Application: Purchasing
Title: Requisition Headers
Unfreeze the flexfield
Now click on Segments button.
Add a segment
Number: 1
Name: Tender Required
Window Prompt: Tender Required
Column: Attribute1
Value Set: XXEY_GL_YES_NO
Double click on the Segments and uncheck Required field.
Click on Value Set button.
The value set is set as Validation Type: Independent . Save and close all forms and compile the DFF.
Navigation: Application > Validation > Values
Enter the name as XXEY_GL_YES_NO (This is the value set of the Requisition Header DFF segment we have enabled)
Click on Find button
We have set 2 values, Yes and No. Hence we shall get only these 2 values on the DFF.
Workflow modification
Workflow name: PO Requisition Approval (REQAPPRV)
3 Functions have been added to the seeded workflow
- XXEY Set Preparer Notification Attrib
This function is calling the DB object, XXEY_GET_ALL_APPROVERS.GET_ALL_APPROVERS.
- XXEY Update Approval Control
This function is calling the DB object, xx_change_approval_control_pkg.update_approval_control.
- XXEY Update Approval Control Revert
This function is calling the DB object, xx_change_approval_control_pkg.update_approval_control_rev.
The following processes have been modified.
- Modified: Main process
The following functions have been added to the main process.
- XXEY Update Approval Control
- XXEY Set Preparer Notification Attrib
The entire process diagram becomes the following,
- Modified: Response with Approve Action
Add the function XXEY Update Approval Control in the process.
Database packages to be written
The following database packages had to be written as these will be called from the workflow functions that have been created previously.
- XX_CHANGE_APPROVAL_CONTROL_PKG
- XXEY_GET_ALL_APPROVERS
You can get the code at the link below,
Test the customization
We shall define an alternate approval groups for a requisition approver. First let us select an approver from the requisition hierarchy. You can refer to this article if you need details on position hierarchy and approval groups.
Step 1: Select a position
Open the hierarchy form for requisitions. Select the approving position, “7079.Manager Procurement. Finance”.
As per the hierarchy, position 7080 sends requisitions to position 7079 for approval.
Step 2: Check the approval group assignment
Let us check the approval groups attached to position 7079.
Note the approval assignments for Internal and Purchase Requisitions
We shall assign alternate approval groups for both types of requisitions.
Set DFF value for Internal Requisition
Set DFF value for Purchase Requisition
Save and close the form.
Step 3: Check the approval group limits
We shall check approval groups,
- EY Level 4 (For Purchase Requisitions)
- EY Level 7 (For Internal Requisitions)
- EY Level 10 (For both Internal & Purchase Requisitions as the alternate Approval Group)
EY Level 4
EY Level 7
EY Level 10
Therefore we see that approval group limit for,
Level 4 is 100,000
Level 7 is 10,000,000
Level 10 is 50,000,000
Step 4: Raise a requisition as position 7080
As per the customization and setup done, a purchase requisition with an amount of more than 100,000 (limit of Level 4) can be approved by position 7079 if it requires a tender (based on the requisition DFF value) as this position’s alternate approval group (Level 10) has a limit of 50,000,000.
We shall test this now with 2 scenarios by logging in as position 7080 and raising requisitions.
Scenario 1: Raise a purchase requisition for more than 100,000 and setting the DFF value for Tender Required, on the requisition header, to No.
Scenario 2: Raise a purchase requisition for more than 100,000 and setting the DFF value for Tender Required, on the requisition header, to Yes.
Scenario 1 testing
Open the Requisitions form. Create a new Purchase Requisition for more than 100,000.
Send the requisition for approval by clicking Approve button. Note the requisition number, 112001468.
Once the requisition is sent for approval you can trace the workflow in Workflow Status monitor. The item type is REQAPPRV and the user key is 112001468. You can refer to this article if you need details on how to track a workflow.
You will find the workflow is waiting for an approval from position, 7079, i.e. Uzair Khan.
Open the notification and approve it.
Note: Check the approval sequence within the notification
In the sequence you find the entire hierarchy displayed and it displays the position beyond 7079 (Uzair Ahmed Khan). This means that the workflow will go to the approver after Uzair, i.e. Adil (Num 4) as shown in the list.
You might need to execute “Workflow Background process” if the workflow goes into deferred mode. Check the workflow activity again.
You will find that the workflow has gone to the next position in the hierarchy for approval. 
Approve the notification again. . You might need to execute “Workflow Background process” if the workflow goes into deferred mode. Check the workflow activity again.
Now the workflow has ended.
In this test scenario we have seen that the requisition approval follows the standard setup.
Scenario 2 testing
Open the Requisitions form. Create a new Purchase Requisition for more than 100,000.
We have created the requisition with exactly same details as Scenario 1. We shall now enter the value of the requisition header DFF. Click on DFF field on the requisition header.
Click on the LOV of the field named, Tender Required.
Select Yes and press OK. Save the form. Now the form shows the following.
The DFF value has been entered. Send the requisition for approval now.
Check the workflow as you have done in scenario 1.
The workflow is pending on Uzair Khan’s approval, as expected. Now open the notification.
Note:
Position 7079 or Uzair Khan’s name shows as the last person on the approval sequence list.
Position 7079 or Uzair Khan’s name shows as the last person on the approval sequence list.
Approve the notification. Trace the workflow again. You may need to execute “Workflow Background Process” program.
The workflow now completes with only the approval of position 7079 (Uzair Khan). This shows that the customization has kicked into effect and is working as expected.
0 comments