To view the properties of the PO Approval Top Process, select the process in the navigator tree, then choose Properties from the Edit menu. The PO Approval Top Process has a result type of None, indicating that when the process completes, it doesn't end with a particular result, such as Approved or Rejected. Instead, its subprocesses end with specific results.
This process activity is 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 Details property page of the process activity indicates that the PO Approval Top 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 you attempt to initiate the PO Approval Top Process with a purchase order that is created by someone who is not listed in the employee approval hierarchy, the Workflow Engine would raise an error when it tries to execute the Find Approver activity. This error would initiate DEFAULT_ERROR, which 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.
The PO Approval workflow begins when you submit a purchase order for approval in Purchasing, or respond to a reminder notification to submit a purchase order for approval.
The workflow begins at node 1.
Node 2 removes previous purchase order notifications for this document if previous versions of the document sent to the workflow were incomplete or rejected.
Node 3 sets startup values, node 5 sets the purchase order status to In Process, node 6 determines whether the process is set up to run in Online or Background performance modes according to the profile option PO: Workflow Processing Mode, and node 8 retrieves purchase order attributes (purchase order information and internal workflow attributes). For more detail on these startup activities, see the next section.
Node 9 checks if the document requires reapproval because the supplier made a change (for example, to the Promised or Need-By Date) through Oracle iSupplier Portal. If the supplier's change was approved through iSupplier Portal, the document is approved directly rather than submitted for change order or full reapproval.
Note: Node 9 enables you to approve any change made through iSupplier Portal. If you were to delete node 9, any change a supplier makes through iSupplier Portal would be treated like any other document change in the change order workflow. See: Workflow Processes for Approving Change Orders.
Node 10 checks if the document is new. If it is, the workflow moves from node 10 to the Main PO Approval Process at node 14 to approve the document. If the document is not new, the change order workflow begins if your Purchasing setup (in the Document Types window) archives documents on approval (the Change Order workflow cannot work without this setup). The change order workflow gathers all document changes at node 12; determines at node 13 if those changes require manual reapproval or can simply be approved automatically; attempts at node 16 to reserve funds for the document if encumbrance accounting is used; approves the changes at node 18; sends a notification at node 20 that the document was approved; and, if Print was selected in the Approve Document window, prints the document at node 21. If a facsimile number was entered in the Approve Document window, node 22 sends a facsimile of the purchase order.