TROUBLESHOOTING
The following section provides some details on diagnosing some common issues in the Purchasing approval processing
1) Document Approval Logic:
Issue 1
Document remains in Incomplete status after Approval
Cause 1A
The creator of the document is not part of a valid approval hierarchy, and does not have the limits to make the approval. The user needs to be associated to a valid Approval Hierarchy that address the approval limits for the specific document type. If employee / supervisor relation is being used for the document approval routing, then the needed assignments and association for each approval level will need to be done through the Enter Person form for each sequential employee/supervisor. For details on assigning employees, refer to Oracle Purchasing User’s Guide Release 11i (Part No. A82913–06) in 11.5.10 or Oracle Purchasing User's Guide Release 12 (Part No. B28669-01)
Cause 1B
The creator is part of a valid hierarchy, but there is not a level within the hierarchy that covers the elements on the document. The main culprit for this is the Change Account. Verify that for each of the limits under each level, that the number of digits for each segment in the account ranges matches that of the Charge Account. If the segment count appears to be correct, perform a quick test, and move the top of the account for the last level to be ‘Z’ for each digit. (Ex: ZZ.ZZZ.ZZ.ZZZZ.ZZZZ) If the resubmit of the approval now moves through without issue, then it is known that the cause was the Account Range, and new limits just need to be set for the each level.
Issue 2
Document rolls-up to the next approval level, when it should be approved by the owner.
Cause 2A
The assigned approval limits for the owner/creator are not broad or high enough to allow for document approval at the owner level. Review the approval limits and conditions assigned to the owner, and match each against a document that rolled-up to the next level.
Cause 2B
Even though the owner/creator has the correct approval limits for the document approval, the “Owner Can Approve” option under the document type setup has not been set to “Y”. For an owner/creator to be able to approve their own documents, this setting must be defined as “Y”.
Issue 3
Unable to open Requisitions or Purchase Orders from the document summary, for approval.
Cause 3A
The document is in either In Process or Pre-Approved status. A majority of the time, there is an open notification against either the Requisition or Purchase Order. The following query set can be used to determine the current user the notification action is waiting for:
Requisition:
select reqh.segment1 req, wfn.status notify_status, wias.notification_id notify_id,
wfn.to_user name, reqh.org_id org from wf_item_activity_statuses wias, wf_notifications wfn, po_requisition_headers_all reqh
where wias.notification_id is not null and wias.notification_id = wfn.group_id
and wfn.status = 'OPEN' and wias.item_type = 'REQAPPRV'
and wias.item_key = reqh.wf_item_key and reqh.authorization_status = ‘&Req_Number’ order by 5,1,3;
Purchase Order:
select poh.segment1 po, wfn.status notify_status, wias.notification_id notify_id,
wfn.to_user name, poh.org_id org from wf_item_activity_statuses wias,
wf_notifications wfn, po_headers_all poh where wias.notification_id is not null
and wias.notification_id = wfn.group_id and wfn.status = 'OPEN'
and wias.item_type = 'POAPPRV' and wias.item_key = poh.wf_item_key and poh.segment1 = ‘&PO_Number’ order by 4,5,1,3;
Cause 3B
The Purchase Order is in In Process or Pre-Approved status, but does not have any Workflow data. The most common cause for this is that there is an Open Change request against the Purchase Order/Requisition combination. Because the Purge Obsolete Workflow Process may have been run against the document between the last time the Approval took place and the Change Request was raised, the WF data would be missing. The correct action in this case is to have the Buyer, which the Change Request is waiting on, reply to the notification to either except or reject the change. The following query can be used to review the ties between the Purchase Order, Requisition and Change Request.
Purchase Order:
select ref_po_num PO_Num, ref_po_rel_num Rel_Num, document_num Req_Num,
change_request_id CR_Id, change_request_group_id CR_Grp_ID,
last_update_date, document_line_number Doc_Line_Num, action_type,
request_reason, request_status status from po_change_requests where ref_po_header_id =
(select po_header_id from po_headers_all where segment1 = '&PO_NUMBER' and org_id = '&ORG_ID')
and document_type = 'REQ' order by last_update_date
Requisition:
select ref_po_num PO_Num, ref_po_rel_num Rel_Num, document_num Req_Num,
change_request_id CR_Id, change_request_group_id CR_Grp_ID,
last_update_date, document_line_number Doc_Line_Num, action_type,
request_reason, request_status status from po_change_requests where document_header_id =
(select requisition_header_id from po_requisition_headers_all where segment1 = '&Req_NUMBER'
and org_id = '&ORG_ID') and document_type = 'REQ' order by last_update_date
