How To Diagnose Purchase Order And Requisition Workflows in Deferred

Status? (Doc ID 884391.1)

To Bottom

In this Document
Purpose
Background for the reader
Troubleshooting Steps
SUMMARY
DIFFERENT SCENARIOS IN WHICH CASE IT IS STANDARD FUNCTIONALITY
THAT WORKFLOW IS GET DEFERRED
A. Profile option PO:Workflow Processing Mode is set to Background
B. The approval authority is delegated
C. Purchasing document is forwarded through the Forward Documents form
D. Documents are approved when using granted worklist access
E. Requisitions Using Find Notification Form
F. When Approving Requisitions In Succession Some Requisitions Get Deferred
G. Approval deferred whenever the notifications are approved from the default
worklist/full list or homepage
HOW TO PROGRESS THE DEFERRED WORKFLOW PROCESSES?
RECOMMENDED PATCHES TO PREVENT UNNECESSARY DEFERRING
DEFERRED ACTIVITIES NOT BEING PICKED UP WHEN RUNNING
WORKFLOW BACKGROUND PROCESS AFTER RDBMS UPGRADE TO 10G
References
APPLIES TO:
Oracle Purchasing - Version 11.5.10 to 12.3 [Release 11.5 to 12.3]
Information in this document applies to any platform.
FORM:POXDOFDO.FMB - Forward Documents
PURPOSE
Background for the reader

When attempting to approve purchase orders and requisitions in some cases workflow
activities become deferred. In some cases this is standard behavior, while in other cases this
might be a known bug. This note describes:
- Known cases in which it is inevitable that the workflow becomes deferred
- Known bugs causing the approval to get deferred
- Solutions to both cases
TROUBLESHOOTING STEPS

SUMMARY

There are several scenarios that cause workflow processes to get deferred in case of purchase
order and/or requisition approval. These scenarios can involve the following cases, in which
case 'deferring' is inevitable:

A. Profile option PO:Workflow Processing Mode is set to Background

B. The approval authority is delegated
C. Purchasing document is forwarded through the Forward Documents form
D. Documents are approved when using granted worklist access
E. Requisitions Using Find Notification Form
F. When Approving Requisitions In Succession Some Requisitions Get Deferred
G. Approval deferred whenever the notifications are approved from the default worklist/full
list or homepage

DIFFERENT SCENARIOS IN WHICH CASE IT IS STANDARD FUNCTIONALITY THAT

WORKFLOW IS GET DEFERRED
A. Profile option PO:Workflow Processing Mode is set to Background

When purchase orders and requisitions are getting deferred a common issue is that the profile
option 'PO:Workflow Processing Mode' is set to Background. When you submit the
requisition or purchase order for approval the following activity becomes deferred:
Wait for Background Process

This scenario can be reproduced using the following steps:

Requisition:
1. Set the profile option 'PO:Workflow Processing Mode' to "Background"
2. Navigate to Requisitions > Requisitions
3. Create a requisition and submit it for approval
4. Navigate to Requisitions > Requisition Order Summary
5. Query up the requisition and choose Inquire > View Approval Through Workflow
6. The following activity is deferred:
Wait for Background Process
Function: PO_REQAPPROVAL_INIT1.DUMMY

In case the profile option "PO: Workflow Processing Mode" is set to Background for
requisitions also the following activity might be deferred:

START_OF_APPROVE_REQ/NOOP
How the profile option 'PO:Workflow Processing Mode' is set can be checked in 2 ways:
1. Start up a System Administrator responsibility
Navigate to Profile > System
Find Profile: PO:Workflow Processing Mode
2. Execute the following query:
SELECT t.user_profile_option_name "Profile Option"
, decode(a.level_id, 10001, 'Site', 10002, 'Application', 10003,
'Responsibility', 10004, 'User') "Level"
, decode(a.level_id, 10001, 'Site', 10002, b.application_short_name, 10003,
c.responsibility_key
, 10004, d.user_name) "Level Value", a.profile_option_value "Profile Value"
FROM fnd_profile_option_values a, fnd_application b, fnd_responsibility c,
fnd_user d
, fnd_profile_options e, fnd_profile_options_tl t
WHERE a.profile_option_id = e.profile_option_id
AND e.profile_option_name in ( 'PO_WORKFLOW_APPROVAL_MODE')
AND a.level_value = b.application_id(+)
AND a.level_value = c.responsibility_id(+)
AND a.level_value = d.user_id(+)
AND t.profile_option_name = e.profile_option_name
AND t.LANGUAGE = 'US'
ORDER BY e.profile_option_name, a.level_id DESC;

If you do not want the approval to be deferred, please set the profile option 'PO:Workflow
Processing Mode' to "Online".
B. The approval authority is delegated

When responding to delegated notifications it is standard behavior to defer the workflow.

This involves notifications delegated through a vacation rule, and notifications delegated by
manually reassigning them.
This scenario can be reproduced using the following steps:
Requisition:
1. Create a Vacation Rule to delegate responses from Approver A to Approver B
2. Create a requisition and submit it for approval to Approver A
3. Login as Approver B and open the delegated notification
4. Choose Approve to submit the requisition for approval
5. Navigate to Requisitions > Requisition Order Summary
6. Query up the requisition and choose Inquire > View Approval Through Workflow
7. The following activity is deferred:

Update Approval List Response

Function: PO_APPROVAL_LIST_WF1S.UPDATE_APP_LIST_RESP_SUCCESS

Note: also the following Activities may also be deferred in this delegate scenario:
Display Name: Is Forward-To Valid
Internal Name: IS_FORWARD_TO_VALID
Display Name: Update Action History (Approve) AME
Internal Name: AME_UPDATE_ACTION_APPROVE

Purchase Order:
1. Create a Vacation Rule to delegate responses from Approver A to Approver B
2. Create a purchase order and submit it for approval to Approver A
3. Login as Approver B and open the delegated notification
4. Choose Approve to submit the purchase order for approval
5. Navigate to Purchase Orders > Purchase Order Summary
7. Query up the purchase order and choose Inquire > View Approval Through Workflow
8. The following activity is deferred:
Set Forward-To/From For Approve Action
Function: PO_REQAPPROVAL_FINDAPPRV1.SET_FWD_TO_FROM_APP_TIMEOUT

In case the purchase order is manually reassigned the the following activity is deferred:
Notify Approver Subprocess/End

C. Purchasing document is forwarded through the Forward Documents form

In order to forward a document, occasionally the context of the recipient was switched for the
workflow to proceed correctly. This caused security and functional issues. In order to prevent
the security and functional implications of online context switching, all workflow responses
which require a context switch are deferred to the workflow background process. This
includes forwarding documents to an approver.
As of 11.5.10.2 when forwarding requisitions or purchase orders through the Forward
Documents form (POXDOFDO.fmb) it is standard behavior as to defer the workflow at the
following activity:

Is Forward to Valid

This scenario can be reproduced using the following steps:

Requisition:
1. As preparer navigate to Requisitions > Requisitions
2. Create a requisition and submit it for approval to Approver A
3. Navigate to Management > Forward Documents
4. Enter the requisition number and Find Document
5. Select as new approver Approver B, select the line and save the changes
6. Navigate to Requisitions > Requisition Order Summary
7. Query up the requisition and choose Inquire > View Approval Through Workflow
8. The following activity is deferred:
Is Forward-To Valid?
Function: PO_REQAPPROVAL_FINDAPPRV1.IS_FORWARD_TO_VALID

Purchase Order:
1. As preparer navigate to Purchase Orders > Purchase Orders
2. Create a purchase order and submit it for approval to Approver A
3. Navigate to Management > Forward Documents
4. Enter the purchase order number and Find Document
5. Select as new approver Approver B, select the line and save the changes
6. Navigate to Purchase Orders > Purchase Order Summary
7. Query up the purchase order and choose Inquire > View Approval Through Workflow
8. The following activity is deferred:
Is Forward-To Valid?
Function: PO_REQAPPROVAL_FINDAPPRV1.IS_FORWARD_TO_VALID

D. Documents are approved when using granted worklist access

After granting worklist access from 115.10.2 on it is inevitable that the workflow activities
become deferred when using this access to approve a purchase order / requisition.
This scenario can be reproduced using the following steps:
Requisition:

1. As Approver A grant Worklist Access to Approver B

2. Create a requisition and submit it for approval to Approver A
3. As the worklist access has been granted to Approver B, this user will receive the
notification in the worklist too
4. Open the notification and choose Approve
6. Navigate to Requisitions > Requisition Order Summary
7. Query up the requisition and choose Inquire > View Approval Through Workflow
8. The following activity is deferred:
Update Approval List Response
Function: PO_APPROVAL_LIST_WF1S.UPDATE_APP_LIST_RESP_SUCCESS

Purchase Order:
1. As Approver A grant Worklist Access to Approver B
2. Create a purchase order and submit it for approval to Approver A
3. As the worklist access has been granted to Approver B, this user will receive the
notification in the worklist too
4. Open the notification and choose Approve
5. Navigate to Purchase Orders > Purchase Order Summary
6. Query up the purchase order and choose Inquire > View Approval Through Workflow
7. The following activity is deferred:
Set Forward-To/From For Approve Action
Function: PO_REQAPPROVAL_FINDAPPRV1.SET_FWD_TO_FROM_APP_TIMEOUT

E. Requisitions Using Find Notification Form

Requisitions approved in the Find Notifications form go to Deferred status. This hapens when
the sysadmin tries to approve them on behalf of 1st approver. This issue can be reproduced as
followed:
1. Create a requisition and submit it for approval to approver A
2. Log in as Sysadmin
3. Choose "Find Notifications"
4. Query up the notifications for the approver and approve it
5. At this moment the workflow will get deferred
This is a context setting issue which is causing the Requisitions approved in the Find
Notification go to Deferred status.
When the approval workflow is processed it should be processed in the context of the
Preparer/Approver depending on the location where the approval workflow is currently.

If the document is forwarded to an approver, the response to the approval notification has to
be processed in the approver's context. That means while processing the response to the
notification, the session should be as if the approver is performing the response.
If the sysadmin takes the action on the notification then the current session will be that of the
system administrator. But the action has to be processed as if the approver is performing. All
the profile options should be selected as that of the approver. All the who columns [last
updated] should be updated with the approver name instead of sysadmin.
Hence it becomes essential that the action by sysadmin should be processed in the session of
approver. This needs re-setting the current session.
If the sysadmin has logged in to the application, then the current session cannot be reset.
Hence there is no other choice than deferring the sysadmin's response.
F. When Approving Requisitions In Succession Some Requisitions Get Deferred

Upon attempting to approve multiple requisitions in the notifications window, requisitions

submitted for approval are not becoming approved. This issue can be reproduced as followed:
1. Create multiple requisitions and submit them for approval
2. Login as the approver / supervisor and navigate to the notifications worklist
3. Select multiple notifications pending approval
4. Hit Open button
5. Choose approve to the first, then second and submit them one after another.
6. The first requisition will be approved, but the others remain in process.
When the first requisition is approved, the current context may get changed in either the
requisition approval process or if the create PO is set as online then also the context would
have got changed. Hence, when responding to the second notification in the same session,
since the context is changed, the workflow gets deferred.
G. Approval deferred whenever the notifications are approved from the default
worklist/full list or homepage

Note that after appliance of Patch 8927490 and Patch 8339900 , whenever the notifications
are approved from the default worklist/full list or homepage, they will move to DEFERRED
status.
HOW TO PROGRESS THE DEFERRED WORKFLOW PROCESSES?

All the above mentioned cases are standard functionality at this time and when such an issue
is encountered the Workflow Background Process should be run to pick up the deferred
workflow processes. In order to run the Workflow Background Process please execute the
following steps:
In case of deferred requisition activities:

1. Login using a System Administrator responsibility

2. Navigate to Requests > Run
3. Choose Single Request
4. Choose 'Workflow Background Process'
5. Enter the following parameters:
Item Type: "PO Requisition Approval" (or "Requisition")
Process Deferred: Yes
6. Submit the request
In case of deferred purchase order activities:
1. Login using a System Administrator responsibility
2. Navigate to Requests > Run
3. Choose Single Request
4. Choose 'Workflow Background Process'
5. Enter the following parameters:
Item Type: "PO Approval"
Process Deferred: Yes
6. Submit the request

Note: In order to check if the workflow background has been run, and which parameters were
used to run it, the following query can be used:

SELECT fcr.request_id id
, fl.meaning
, fcpv.concurrent_program_name
, fcpv.user_concurrent_program_name rpname
, to_char(fcr.actual_start_date, 'DD-MON-RR HH24:MI:SS') sd
, fcrf.argument_text
FROM fnd_concurrent_requests fcr
, fnd_concurrent_programs_vl fcpv
, fnd_conc_requests_form_v fcrf
, fnd_lookups fl
WHERE fl.lookup_type = 'CP_STATUS_CODE'
AND fl.lookup_code = fcr.status_code
AND fcr.concurrent_program_id = fcpv.concurrent_program_id
AND fcr.program_application_id = fcpv.application_id
AND fcr.request_id = fcrf.request_id
AND fcr.actual_start_date > sysdate - 5
AND fcpv.concurrent_program_name = 'FNDWFBG'
ORDER BY fcr.actual_start_date, fcr.request_id;

In case these issues are encountered frequently the best solution we can offer is to schedule
the workflow background process to run periodically to pick up the deferred workflow
activities. Using the Scheduling feature schedule the Workflow Background Process to run at
the desired periodic intervals (with next request submission done at COMPLETION of
previous).

RECOMMENDED PATCHES TO PREVENT UNNECESSARY DEFERRING

This chapter provides a list of recommended patches to prevent purchase orders or requisition
approval to become unnecessary deferred.
Release 11.5.10
1. Patch 4457756: ORA-20002: 2018: UNABLE TO GENERATE NOTIFICATION XML BLANKET RELEASES
Problems fixed by this patch: The response to the notification is unable to set the context
which is causing the workflow process to move to the deferred mode.
The problem was seen with POXWPA7B.pls version 115.38.11510.5.
Files fixed and version:
- POXWPA7B.pls 115.38.11510.7 or higher
The file version can be checked as followed:
select text
from dba_source
where line = 2
and name = 'PO_WF_PO_NOTIFICATION';

Procurement Rollup patch: Included in PRC 11.5.10.2 Rollup Patch 3 Patch 6505228 or
higher
2. Patch 5389914: ORA-20002: 2018: UNABLE TO GENERATE NOTIFICATION XML BLANKET RELEASES
Problems fixed by this patch: This patch fixes a context based validation error, which
causes requisitions that are approved from within iProcurement to go to deferred status.
Files fixed and version:
- POXWPA1B.pls 115.206.11510.40
- POXWPA4B.pls 115.50.11510.8
- POXWPA5B.pls 115.7.11510.7
- POXWPA6B.pls 115.68.11510.9

- POXWPA7B.pls 115.38.11510.13
- poxwfpoa.wft 115.127.11510.16
- poxwfrqa.wft 115.80.11510.4
The package versions can be checked as followed:
select text
from dba_source
where line = 2
and name in ('PO_REQAPPROVAL_INIT1','PO_REQAPPROVAL_ACTION'
, 'PO_REQAPPROVAL_LAUNCH','PO_WF_REQ_NOTIFICATION'
, 'PO_WF_PO_NOTIFICATION');

Use these commands to confirm the workflow version:

strings -a $PO_TOP/patch/115/import/US/poxwfpoa.wft |grep Head
strings -a $PO_TOP/patch/115/import/US/poxwfrqa.wft |grep Head

Procurement Rollup patch: Included in PRC 11.5.10.2 Rollup Patch 3 Patch 6505228 or
higher
Release 12
1. Patch 6133861 REL12:APPROVALS GOING INTO DEFERRED MODE
Problems fixed by this patch: This patch fixes the issue that for requisition and purchase
order approval the End activity is deferred when the approver responds to the Approval
Notification.
Files fixed and version:
- wfengb.pls 120.15.12000000.8
The file version can be checked as followed:
select text
from dba_source
where line = 2
and name = 'WF_ENGINE';

Patchset: Included in R12.ATG_PF.A.DELTA.4 (12.0.4) Patch 6272680 or higher

DEFERRED ACTIVITIES NOT BEING PICKED UP WHEN RUNNING WORKFLOW

BACKGROUND PROCESS AFTER RDBMS UPGRADE TO 10G

Next to the recommended patches it is also observed that after an RDBMS upgrade to 10G
the workflow background process has stopped processing the Deferred Activities. The
requisitions are getting stuck in the approval workflow with an 'In Process' status and end up
with a "Wait for Background Process" activity that has a status of "deferred".
If this is the case as a workaround you can switch the profile option PO:Workflow Processing
Mode from "Background" to "Online".
Switching the Purchase Order Workflow process to run in online mode as opposed to
Background mode is a workaround. Further, once in Online mode currently stuck
Requisitions can be rewound at which point they will process properly.
In order to resolve this issue, check if the value for AQ_TM_PROCESSES is inadvertently
set to zero after the database upgrade. This can be done by running the following statement:
SELECT name, value
FROM v$parameter
WHERE name = 'aq_tm_processes';
If this is indeed the case, please perform the following steps:
1. Set the AQ_TM_PROCESSES to 1
2. Then bounce the database
If AQ_TM_PROCESSES is not set to zero the workaround is to stop and restart the Queue
Monitor processes via the following commands:
connect / as sysdba
alter system set aq_tm_processes=0 scope=memory;
wait until the q00* and qmnc* processes are no longer running, checking via
ps -ef | grep q00
and
ps -ef | grep qmn
Then run the following command:
alter system set aq_tm_processes=1 scope=memory;