Summary of the Main Requisition Approval Process

To view the properties of the Main Requisition Approval process, select the process in the navigator tree, then choose Properties from the Edit menu. The Main Requisition Approval process has a result type of PO Main Requisition Approval Process Result, indicating that when the process completes, it has a result of Approved, Invalid Action, No Approver Available, or Rejected. These results correspond to the lookup codes in the PO Main Requisition Approval Process Result lookup type in the PO Standard item type.

This process activity is also runnable, indicating that it can be initiated as a top-level process to run by making calls to the Workflow Engine CreateProcess and StartProcess APIs.

The Main Requisition Approval workflow begins when you submit a requisition in Purchasing or iProcurement. This workflow handles both kinds of requisitions-those created in iProcurement and those created in Purchasing.

The first part of the process diagram, through node 16, is shown below:

The rest of the process diagram, starting with node 16, is shown below:

Node 2 sets all startup values, sets the requisition status to In Process, obtains the approval mode used, and retrieves requisition attributes.

If the requisition passes verification at node 3, node 5 attempts to reserve funds at the start of the approval process, for iProcurement requisitions, if you use encumbrance.

Node 6 checks if the requester in iProcurement created or modified an approval list. If not-or if the requisition was created in Purchasing-node 7 builds a default approval list based on the approval hierarchy setup in Purchasing.

If node 7 cannot build a default approval list (for example, because of a system failure or a problem in the approval hierarchy), the requisition is returned to the requester at node 8.

Node 10 checks if Owner Can Approve is enabled for the document type, and node 15 verifies the owner's approval authority. If the owner cannot approve the document, node 11 routes the requisition according to the approval list.

If an approver responds with Reject, node 12 rejects the requisition, and node 13 sends a notification of the rejection to the requester. If there is a problem with the requisition, it is returned at node 8.

If an approver responds with Approved, the workflow begins to approve the document, starting at node 18. At node 18, the workflow reserves funds for the document if encumbrance accounting is being used and if funds for the document aren't already reserved, before approving the document at node 20.

If the requisition is forwarded, node 19 rebuilds the approval list to include that forward-to person. Then node 11 forwards the requisition to that approver.

If node 10 and 15 confirm that the requester can approve the document, the requisition status is set to Pre-Approved at node 16. Then, if no more approvers are indicated by node 17, the workflow approves the document: node 18 makes sure funds are reserved if encumbrance is used, and node 20 approves the document and sets its status to Approved.

Finally: