To view the properties of the Confirm Receipt process, select the process in the navigator tree, then choose Properties from the Edit menu. The Confirm Receipt process has a result type of None, indicating that when the process completes, it does not have specific results of, for example, End (Invalid) or End (Valid), which are found in the Lookup Types branch in the Workflow Builder. Instead, this process's subprocesses have specific result types associated with them.

The Details property page of the process activity indicates that the Confirm Receipt process has an error process called DEFAULT_ERROR associated with it, which gets initiated only when an error is encountered in the process. For example, if the workflow sends a notification to the requester's manager but cannot find the manager's unique identifier (Manager ID), the Workflow Engine would raise an error when it tries to execute the notification activity. This error would initiate DEFAULT_ERROR, which is the Default Error Process. The Default Error Process is associated with the System:Error item type. Currently the process simply executes the standard Default Error Notification activity to provide information associated with the error. You can customize the process further to suit your needs. See: Default Error Process.

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 Confirm Receipt process begins when you submit the Confirm Receipts Workflow Select Orders process through the Requests window.

The workflow begins at node 1.

Node 1 retrieves information from the purchase order and requisition that will be used in the message that is sent to the buyer or requester.

Node 2 retrieves a URL that enables you to access the iProcurement Receive Orders Web page from the notification if you wish to process receipt confirmation through Oracle iProcurement, if iProcurement is installed.

At node 3, the subprocess sends a notification to the requester to confirm the receipt of expense items that are past due.

If the requester responds with Not Received, node 4 notifies the buyer that the items have not been received. If the requester responds with Partially/Over Received, node 5 notifies the buyer of such. If the requester responds with Fully Received, node 6 processes the receipt. If the receipt cannot be processed, node 7 sends a notification of the failure to the requester, and node 9 sends a notification of the failure to the buyer.

At node 3, if the requester does not respond before the number of days indicated by the notification activities in the node 3 subprocess, the workflow times out, retrieves the requester's manager from your hierarchy setup (node 10), and notifies the requester's manager (node 11).