Whenever you submit a purchase order or release for approval or take an action in the Notifications Summary window, Purchasing uses Oracle Workflow technology in the background to handle the approval process. Workflow uses the approval controls and hierarchies you define according to the setup steps in the section Setting Up Document Approval and Security to route documents for approval. You can use the Workflow Builder interface to modify your approval process.

The purchase order approval workflow consists of processes, which are viewable in the Workflow Builder as a diagram, some of whose objects and properties you can modify. Each workflow process, in turn, consists of individual function activities.

The PO Approval workflow is initiated at the following points in Purchasing:

• When you choose Submit for Approval (and then choose OK) in the Approve Document window. See: Submitting a Document for Approval.

• When you respond to a reminder in the Notifications Summary window reminding you to submit a document for approval that has not yet been submitted.

For information on the requisition approval workflow, see: Requisition Approval Workflow.

Use the Oracle Workflow Builder to customize workflows. When you customize a workflow, only those documents that are submitted for approval after you have customized it are affected by the customized workflow.

You can also use the Workflow Builder to create unique approval workflows for each document type in your organization. You associate particular workflows with certain document types in the Document Types window. See: Defining Document Types.

You can use the Workflow Monitor to follow where certain documents are in a workflow process. See: Overview of Workflow Monitoring.

To display the workflow in the Oracle Workflow Builder:

1. Choose Open from the File menu, and connect to the database.

   See: Opening and Saving Item Types.

   The Display name of the PO Approval workflow is PO Approval. The name of its Workflow definition file is poxwfpoa.wft.

2. Expand the data source, then the PO Approval item type branch within that data source.

3. Expand the Processes branch within the PO Approval branch, then double-click a process activity to display its diagram.

Creating a New Custom Process

You can either modify the default PO Approval workflow that Purchasing provides, or copy it and create a whole new workflow. Use the Document Types window to select a custom PO Approval Workflow Startup Process for specific document types or operating units.

If you create different workflows for different documents or operating units, the recommended practice is not to copy and rename the item type (such as PO Approval 1), but to copy and rename the Workflow Startup Process, which you will modify to call your own custom subprocesses. All of your operating units will point to the same item type, and will use the default item attributes and other activities that the item type requires, but one operating unit will also use your custom startup process.

Required Modifications

There are no required modifications you need to make to the PO Approval workflow. However, this documentation assumes that you have already set up Purchasing and performed the Workflow setup steps described in Workflow Setup Options.

Supported and Unsupported Customizations

The following is a discussion of what you can and definitely cannot modify in the PO Approval workflow. For those things you can modify, the discussion includes important guidelines that you need to be careful of when making customizations.

For important information on how to customize workflows, see the Oracle Workflow Developer's Guide.

To further help you with your customizations, refer to the sections later in this document, starting with The PO Approval Item Type. These sections describe the components of the main processes in the PO Approval workflow. If you haven't already, see also: Customization Guidelines.

Attributes

You can modify the following attributes only, by changing their Default Value:

• Change Order Header Blanket Total Tolerance

• Change Order Header Amount Limit Tolerance

• Change Order Header Purchase Order Total Tolerance

• Change Order Line Quantity Tolerance

• Change Order Line Unit Price Tolerance

• Change Order Line Quantity Committed Tolerance

• Change Order Line Agreed Amount Tolerance

• Change Order Line Price Limit Tolerance

• Change Order Shipment Price Override Tolerance

• Change Order Shipment Quantity Tolerance

• Change Order Distribution Quantity Ordered Tolerance

For information about how to modify these attributes, see: Workflow Processes for Approving Change Orders.

Processes

If you modify a process, it is essential that the basic flow remain intact to maintain data integrity in the database. For example, you should not remove or bypass the function activity Is Document Complete? in the Verify PO subprocess because this may allow incomplete data to be inserted into the database tables. However, you could add additional checks (processes or function activities) before allowing data to be inserted into the tables.

If you modify any process, either by replacing a portion of its flow or by adding additional function activities, remember the following:

• Attributes that are set by default function activities in the default processes must also be set if you replace default function activities with ones of your own. That is, if a function activity in that process uses a SetItemAttr statement, then that function activity is setting an attribute to be used by another function activity later. Therefore, your new function activity must do the same. You should also preserve SetItemUserKey and SetItemOwner statements, if any. (Depending on your customizations, you may also want to preserve GetItemAttr statements.)

• Any database state maintained by the default processes must also be maintained by processes you customize. That is, if a function activity in that process uses an Update or Insert Into statement, then that function activity is updating or inserting rows in the database. Therefore, your new function activity must maintain the same database state.

  To get a list of the workflow function activities that use SetItemAttr, GetItemAttr, SetItemUserKey, SetItemOwner, Insert Into, or Update statements, run the PL/SQL script powfcust. For instructions on running this script, see: Customization Guidelines.

The processes listed below may be modified as your business processes require; however, remember that after your customizations, the attributes that were set and the database states that were maintained by the default process must also be set or maintained by your customized process:

• Do Document Changes Require Reapproval?

• Find Approver

• Get All Blanket PO Changes

• Get All Contract PO Changes

• Get All Planned PO Changes

• Get All Release Changes

• Get All Standard PO Changes

• Notify Approver

• Print Document Process

• Print Document Process (Change Order)

• Fax Document Process

• Fax Document Process (Change Order)

You may add your own additional function activities to the processes listed below, but do not remove any default function activities from them:

• Approve and Forward PO

• Approve PO

• Approve PO (Change Order)

• Change Order Reserve Before Approve

• Forward PO

• Get All Document Changes

• PO Approval Process

• PO Approval Top Process

• Reject PO

• Reserve Before Approve

• Return PO to Submitter

• Verify Approval Authority

• Verify PO

Notifications

All of the notifications can be modified to meet your individual business needs. However, if the notification has a reply code, make sure that the Result Type of your customized notification matches the transitions in the workflow diagram. See: To Create a Notification Activity. See also: Message Result and To Create a Message.

Function Activities

You cannot modify any function activities in the PO Approval workflow.

However, you can replace some function activities with function activities of your own. When you replace a function activity, you are modifying the process in which it is contained. See the guidelines for customizing the PO Approval processes in the section Processes above.

If you substitute default function activities in a process with function activities that you create, you must remember the following:

• The result type of your new function activity must match the result type of the default activity. That is, the Result Type of function activity in the Workflow Builder-for example, a Result Type of Yes/No-needs to match the result type that you specify in that function activity's corresponding PL/SQL procedure. It also means that if you have, for example, two results (such as Yes and No) in your function activity and corresponding PL/SQL procedure, you need to make sure that there are two corresponding transitions in the workflow diagram (one for Yes and one for No). If you alter the result types and transitions in a process, be careful that you aren't deleting or bypassing any special transitions or checks.

• Just as in the section Processes above, any attributes that were set by the default function activity must also be set by your customized function activity.

• Just as in the section Processes above, any database state maintained by the default function activity must also be maintained by the customized function activity.

Messages

All of the messages can be modified to meet your individual business needs.

Lookup Types

All of the lookup types can be modified to meet your individual business needs.

The purchase order approval process is associated with an item type called PO Approval. This item type identifies all purchase order and release approval workflow processes available. The following workflow processes are associated with PO Approval:

• PO Approval Top Process

• PO AME Approval Top Process Activities

• PO Approval Process

• Approve And Forward PO

• Approve PO

• Approve PO (Change Order) *

• Change Order Reserve Before Approve *

• Do Document Changes Require Reapproval? *

• Find Approver

• Forward PO

• Get All Blanket PO Changes *

• Get All Contract PO Changes *

• Get All Document Changes *

• Get All Planned PO Changes *

• Get All Release Changes *

• Get All Standard PO Changes *

• Notify Approver

• Print Document Process

• Fax Document Process

• Print Document Process (Change Order) *

• Fax Document Process (Change Order) *

• Reject PO

• Reserve Before Approve

• Return PO to Submitter

• Verify Approval Authority

• Verify PO

* These are Change Order workflow process, described in a separate section. See: Workflow Processes for Approving Change Orders.

The PO Approval item type also has many attributes associated with it. These attributes reference information in the Purchasing application tables. The attributes are used and maintained by function activities as well as notification activities throughout the process.

PO Approval Workflow Item Type Attributes

The following is a description of each activity in the PO Approval Top Process listed by the activity's display name. You can create all the components for an activity in the graphical Workflow Builder except for the PL/SQL stored procedures that the function activities call. All function activities execute PL/SQL stored procedures which you must create and store in the Oracle RDBMS. The naming convention for the PL/SQL stored procedures is:

<PACKAGE>.<PROCEDURE> 

<PACKAGE> is the name of the package that groups all of the procedures. <PROCEDURE> represents the name of the procedure.

To view the package and procedure names used by the PO Approval processes, view the Properties page for each function activity. For example, the function activity Remove All Notifications For This Document uses the <PACKAGE>.<PROCEDURE> name PO_REQAPPROVAL_INIT1.REMOVE_REMINDER.

You can use the Item Type Definitions Web page to view <PACKAGE>.<PROCEDURE> names. See: Item Type Definitions Web Page.

Start (Node 1)

This is a Standard function activity that simply marks the start of the process.

Remove All Notifications For This Document (Node 2)

This function activity removes previous notifications for a purchase order previously submitted to the workflow that was not completed because of an error or because of an action such as rejection.

Set Workflow Startup Values (Node 3)

This function activity sets all initial values necessary to identify a unique purchase order, such as the preparer's user name and a forward-to user name.

Update PO Header with Workflow Key (Node 4)

This function activity updates the document header with the item type and item key, which indicate that the purchase order has been submitted to the workflow.

Set PO Status to "In Process" (Node 5)

When you submit a purchase order for approval, its status changes to In Process.

Get Workflow Approval Mode (Node 6)

This function activity retrieves the value from the profile option PO: Workflow Processing Mode, which lets you choose whether you want the approval process to run in Online or Background modes. For definitions of Background and Online modes, see: Profile Options in Purchasing.

Wait for Background Process (Node 7)

If the profile option PO: Workflow Processing Mode is set to Background, this function activity waits for the Workflow Background Engine to pick up this document for processing by the workflow. This activity enables you to proceed to your next Purchasing activity while the approval process for this document completes in the background.

Get PO Attributes (Node 8)

This function activity retrieves key values from the purchase order header and lines, and assigns them to Workflow attributes.

Is Change Initiated from Web Suppliers? (Node 9)

This is a Standard Workflow comparison activity that provides a standard way to compare two numbers, dates, or text strings. Here, this activity is used to check the item attribute Document Submitted by Web Supplier. If the document change was approved through Oracle iSupplier Portal (the item attribute is Y for Yes), the document is approved directly rather than submitted for change order or full reapproval.

See: Comparison Activities. See: Oracle iSupplier Portal Implementation Manual.

Is This a New Document? (Node 10)

This function activity checks whether the purchase order is new or a change to an existing purchase order. (If there is no APPROVED_DATE, it considers the document new.) If it's new, the purchase order goes through the PO Approval Process. If it's a change to an existing purchase order, it goes through the change order approval process if the document type is set to Archive on Approval.

Is Archive on Approval Flag Set to Yes? (Node 11)

This function activity checks if the document type is set to Archive on Approval or Archive on Print in the Document Types window. See: Defining Document Types. If it's set to Archive on Approval and the previously approved document has been modified, then the workflow processes for approving changed purchase orders or releases begins. If it's set to Archive on Print, then the document goes through the full approval process.

PO Approval Process (Node 14)

See: PO Approval Process.

Get All Document Changes (Node 12)

See: Get All Document Changes.

Do Document Changes Require Reapproval? (Node 13)

See: Do Document Changes Require Reapproval?.

Change Order Reserve Before Approve (Node 16)

See: Change Order Reserve Before Approve.

Approve PO (Change Order) (Node 18)

See: Approve PO (Change Order).

PO Approved (Node 20)

This function activity sends a notification to the appropriate individual that the purchase order has been approved.

This notification's message uses Document type item attributes to call two PL/SQL functions, one that retrieves all of the lines in the document and displays them in the notification, and another that retrieves the action history of the document and displays that in the notification.

Print Document Process (Change Order) (Node 21)

See: Print, Fax, and Email Document Processes.

Fax or Email Document Process (Change Order) (Node 22)

See: Print, Fax, and Email Document Processes.

Raise Send PO Event (Change Order) (Node 23)

This function activity will check the document to see if XML is the choosen supplier transmission method. If true, it will raise an event that will cause the document to be sent by way of XML.

Processing following this node takes two paths and workflow executes both of them in parallel. One path is to an end node to wait and the other links to a sub-process to automatically create sourcing rules and approved supplier lists (ASL).

Does User Want SR and ASLs Created (Node 24)

This function activity checks the profile PO: Allow Auto-generate Sourcing Rules and ASL. If the profile is set to Yes and automatic sourcing rule generation was selected, either from Purchasing Document Import or by the user in the Approval window, this activity will return true and the Create SR and ASL sub-process will be invoked.

Create SR and ASL (Node 25)

This sub-process will generate the requested sourcing rules and ASL for all eligible lines in the blanket purchase agreement that is being approved. Exceptions created by this process can be viewed in the Purchasing Interface Errors report.

PL/SQL Error Occurs

This notification activity does not appear in any process diagram, but is used by the workflow in case an internal, PL/SQL error occurs when a function activity performs. If such an error occurs, this notification activity sends a notification to the document owner or approver that a Workflow error has occurred.

The PO AME Approval Top Process is available in the PO Approval workflow item type. The AME feature for PO review, approval, and multiple e-signatures uses this workflow process. Purchasing administrator must select this workflow for a document style in the Document Controls region. See: Using AME for Purchase Order Review, Approval, and Multiple E-Signatures

The following is a description of each activity in the PO AME Approval Top Process listed by the activity's display name. You can create all the components for an activity in the graphical Workflow Builder except for the PL/SQL stored procedures that the function activities call. All function activities execute PL/SQL stored procedures which you must create and store in the Oracle RDBMS. The naming convention for the PL/SQL stored procedures is:

<PACKAGE>.<PROCEDURE> 

<PACKAGE> is the name of the package that groups all of the procedures. <PROCEDURE> represents the name of the procedure.

To view the package and procedure names used by the PO Approval processes, view the Properties page for each function activity. For example, the function activity Remove All Notifications For This Document uses the <PACKAGE>.<PROCEDURE> name PO_REQAPPROVAL_INIT1.REMOVE_REMINDER.

You can use the Item Type Definitions Web page to view <PACKAGE>.<PROCEDURE> names. See: Item Type Definitions Web Page.

Start

This is a Standard function activity that simply marks the start of the process.

Pre-Process

This function performs the following activities:

• removes previous notifications for a purchase order previously submitted to the workflow that was not completed because of an error or because of an action such as rejection.

• Sets all initial values necessary to identify a unique purchase order, such as the preparer's user name and a forward-to user name.

• Updates the document header with the item type and item key, which indicate that the purchase order has been submitted to the workflow.

  When you submit a purchase order for approval, its status changes to In Process.

• Retrieves the value from the profile option PO: Workflow Processing Mode, which lets you choose whether you want the approval process to run in Online or Background modes.

• If the profile option PO: Workflow Processing Mode is set to Background, this function activity waits for the Workflow Background Engine to pick up this document for processing by the workflow. This activity enables you to proceed to your next Purchasing activity while the approval process for this document completes in the background.

• Retrieves key values from the purchase order header and lines, and assigns them to Workflow attributes.

Required Reapproval Pre Process

This function determines whether approval is required again or not by checking if the document is a new document. The function verifies the ByPass Approval Hierarchy Flag and ReApproval Rules attributes. If the Requires Reapproval attribute value is Yes, the function calls the Verify PO process followed by the AME Approval Routing process. If the Requires Reapproval attribute value is No, then the function calls the Open Document Checks process followed by Reserve and then Approve.

Verify PO

This function performs the following activities:

• Checks if the document is open (for example, not finally closed).

• Checks if the document status is compatible with the approval action. Examples of document statuses that allow an approval action are Incomplete, In Process, and Pre-Approved.

• Verifies that the purchase order is complete-for example, verifying that all the quantities match, and at least one line and one distribution exist.

• Sends a notification to the document owner that the document failed the state check.

• Sets the document back to its status before it entered this process activity, if the document has failed state or correctness checks.

• Inserts a Submit Action row into the PO_ACTION_HISTORY table to record that the document has been submitted for approval. It also inserts an additional row with a null ACTION_CODE to simulate a forward-to action, since the document status is In Process. The document manager looks for this row.

AME Approval Routing

This function performs the following activities:

• Retrieves the list of approvers based on the AME rules. If there are no approvers, then verfies whether the document approval is complete or not. If the e-signature functionality is used, then the function ensures that the multiple e-signatures are done only after the entire approval process is complete. If the supplier signature is available, then the process routes the document for multiple e-signatures only after the supplier signature.

• Launches the parallel approval process. The parallel approval process determines the Approver category using the APPROVER_CATEGORY attribute which is set while launching the parallel approval workflow. When the approver approves the document, the approver receives the approval notification. The function checks whether the approver forwards the document or not. If the forward is valid, then the Verify PO process runs or if the forward is invalid, the approver receives a message notification. It routes the document to reviewers. Based on the response of approvers and reviewers, the status of the document is set to the following actions: Reviewe Accepted, Review Rejected, Signed, Signer Rejected, and Approved and Forward. The function updates the AME process with the approval response.

• Sends a reminder notification, in case of Timeout. The current no of reminder is tracked through workflow attribute NO_REMINDER which is initially set to 0. It is incremented in Reminder Process and notification is sent again. The maximum no of reminders is 3. Purchasing records the following reminder actions in the Action History: First Reminder, Second Reminder, Timed Out.

• Generates PDF document for buyer and supplier, if print requests exist.

  The document is printed for supplier only if the authorization status is Approved.

• Sends notifications to FYI approver, if FYI approver is selected in the document Approval Options page.

Return Document

This function handles the AME Exception case and sends Approval Error encountered notification.

Open Document State Subprocess (Change Order)

This function activity checks if the document is open (for example, not finally closed). This activity also inserts a Submit Action row into the PO_ACTION_HISTORY table to record that the document has been submitted for approval. It also inserts an additional row with a null ACTION_CODE to simulate a forward-to action, since the document status is In Process. The document manager looks for this row.

Reserve Sub Process

This function performs the following activities:

• Checks whether encumbrance accounting is used.

• Tries to reserve funds for the document.

• Routes the reserved document for approval, if approvals are in place.

• Sends notifications to preparer if Purchasing is unable to reserve the document

• Routes the document to the Rejection process if the document is sent back to preparer.

Rejection Process

This function performs the following activities:

• Sends rejection notification to the preparer of the document.

• Updates the status of the document to Rejected and records the rejection in the Action History window. It also reverses encumbrance if the document has been encumbered.

• Deletes PDF attachments associated with the document.

Approve PO

This function performs the following activities:

• Verifies the order documents by launching the Verify PO sub process

  See:Verify PO

• Deletes PDF attachments associated with the document.

• Raises change event to check the document to see if XML is the chosen supplier transmission method. If true, it will raise an event that will cause the document to be sent by way of XML. Processing following this node takes two paths and workflow executes both of them in parallel. One path is to an end node to wait and the other links to a sub-process to automatically create sourcing rules and approved supplier lists (ASL).

Post Approval Process

This function performs the following activities:

• Verifies whether the purchase order requires signature.

• Manages the communication for purchase documents. If Print was selected in the Approve Document window when the purchase order was first submitted for approval. If Print was selected, prints the document. checks if Email was selected in the Approve Document window. If Email was selected, automatically sends an Email of the document if an Email Address was also entered in the Approve Document window. If Fax was selected, automatically sends a facsimile of the document if a Fax Number was also entered in the Approve Document window.

• Checks the profile PO: Allow Auto-generate Sourcing Rules and ASL. If the profile is set to Yes and automatic sourcing rule generation was selected, either from Purchasing Document Import or by the user in the Approval window, this activity will return true and the Create SR and ASL sub-process will be invoked.

Signer Post Approval Process

This function updates the document authorization status after e-signature. After the multiple e-sginature process is completed based on the AME routing rules, the function sets the document status to Approved and sends notification to the preparer of the document.

The following is a description of each activity in the PO Approval Process, listed by the node number from the above graphic.

Start (Node 1)

This is a Standard function activity that simply marks the start of the process.

Verify PO (Node 2)

See: Verify PO.

Can Owner Approve? (Node 4)

This function activity checks if Owner Can Approve is enabled for the specific document type in the Document Types window. See: Defining Document Types. If the owner can approve, the subprocess Verify Approval Authority verifies the owner's approval authority. If not, the subprocess Find Approver begins.

Verify Approval Authority (Node 5)

See: Verify Approval Authority.

Is Forward-To Provided? (Node 6)

This function activity checks if a forward-to person was provided in the Approve Document or Notifications Summary windows.

Approve and Forward PO (Node 7)

See: Approve And Forward PO.

Notify Approver (Node 8)

See: Notify Approver.

Reserve Before Approve (Node 9)

See: Reserve Before Approve.

Is PO Pre-Approved? (Node 12)

This function activity checks if the purchase order has been pre-approved. A Pre-Approved document is one that has already been approved by the appropriate individual, who also chose to forward it to yet another person for approval. Or, it is a document that has been authorized for approval but for which funds have not yet been reserved. In the PO Approval workflow, a document is still considered pre-approved until the subprocess Reserve Before Approve or the subprocess Approve PO sets its status to Approved.

Find Approver (Node 13)

See: Find Approver.

Return PO to Submitter (Node 14)

See: Return PO to Submitter.

Is Forward-To User Name Valid? (Node 16)

This function activity checks if the user name of the approver found by the Find Approver activity is valid.

Forward PO (Node 17)

See: Forward PO.

Reject PO (Node 19)

See: Reject PO.

PO Rejected (Node 21)

After the approver's rejection is recorded and the purchase order sent back to the buyer, this activity sends a notification to the buyer that the purchase order has been rejected.

Approve PO (Node 23)

See: Approve PO.

PO Approved (Node 25)

This function activity sends a notification to the appropriate individual that the purchase order has been approved.

This notification's message uses Document type item attributes to call two PL/SQL functions, one that retrieves all of the lines in the document and displays them in the notification, and another that retrieves the action history of the document and displays that in the notification.

Raise Send PO Event (Node 26)

This function activity will check the document to see if XML is the choosen supplier transmission method. If true, it will raise an event that will cause the document to be sent by way of XML.

Processing following this node takes two paths and workflow executes both of them in parallel. One path is to an end node to wait and the other links to a sub-process to automatically create sourcing rules and approved supplier lists (ASL).

Does User Want SR and ASLs Created

If automatic sourcing rule generation was selected, either from Purchasing Document Import or by the user in the Approval window, this activity will return true and the Create SR and ASL sub-process will be invoked.

Create SR and ASL (Node 27)

This sub-process will generate the requested sourcing rules and ASL for all eligible lines in the blanket purchase agreement that is being approved.

Print Document Process (Node 28)

See: Print, Fax, and Email Document Processes.

Fax Document Process (Node 29)

See: Print, Fax, and Email Document Processes.

This notification's message uses Document type item attributes to call two PL/SQL functions, one that retrieves all of the lines in the document and displays them in the notification, and another that retrieves the action history of the document and displays that in the notification.

Email Document Process (Node 30)

See: Print, Fax, and Email Document Processes.

End (Nodes 3, 10, 11, 15, 18, 20, 22, 24)

This function activity marks the end of the process. Although the activity itself does not have a result type, each node of this activity in the process must have a process result assigned to it. The process result is assigned in the property page of the activity node. Since the Main Requisition Approval process activity has a result type of PO Main Requisition Approval Process Result, each End activity node must have a process result matching one of the lookup codes in the PO Main Requisition Approval Process Result lookup type.

The following is a description of each activity in the Verify PO subprocess, listed by the activity's display name.

Start (Node 1)

This is a Standard function activity that simply marks the start of the subprocess.

Open Document State (Node 2)

This function activity checks if the document is open (for example, not finally closed).

Does Document State Allow Approval Action? (Node 3)

This function activity checks if the document status is compatible with the approval action. Examples of document statuses that allow an approval action are Incomplete, In Process, and Pre-Approved.

Is Document Complete? (Node 4)

This function activity verifies that the purchase order is complete-for example, verifying that all the quantities match, and at least one line and one distribution exist.

Record 'Submit' In Action History (Node 12)

This function activity inserts a Submit Action row into the PO_ACTION_HISTORY table to record that the document has been submitted for approval. It also inserts an additional row with a null ACTION_CODE to simulate a forward-to action, since the document status is In Process. The document manager looks for this row.

Document Manager Failed (Nodes 5, 6, and 7)

If the Document Approval Manager fails, the document owner receives this notification that it failed. Once a system administrator successfully restarts the Document Approval Manager, the owner must respond to the notification by choosing Retry, so that the workflow can continue.

Document Failed State Check (Node 8)

This function activity sends a notification to the document owner that the document failed the state check. See: Document Status Checks.

Document Failed Correctness Check (Node 9)

This function activity sends a notification to the document owner that the document failed the correctness check. See: Document Submission Checks.

Set PO Status to Original Status (Node 10)

This function activity sets the document back to its status before it entered this process activity, if the document has failed state or correctness checks.

End (Nodes 11 and 13)

This function activity marks the end of the process. Although the activity itself does not have a result type, each node of this activity in the process must have a process result assigned to it. The process result is assigned in the property page of the activity node. Since the Verify PO subprocess activity has a result type of PO Document Verification, each End activity node must have a process result matching one of the lookup codes in the PO Document Verification lookup type.

The following is a description of each activity in the Reserve Before Approve subprocess, listed by the activity's display name.

Start (Node 1)

This is a Standard function activity that simply marks the start of the subprocess.

Is Encumbrance On and Is Document Not Reserved? (Node 2)

This function activity checks whether you are using encumbrance accounting, and whether the document is already reserved.

Reserve Document (Node 4)

This function activity tries to reserve funds for the document.

Document Manager Failed (Nodes 5 and 11)

If the Document Approval Manager fails, the approver receives this notification that it failed. Once a system administrator successfully restarts the Document Approval Manager, the approver must respond to the notification by choosing Retry, so that the workflow can continue.

Unable To Reserve Document (Node 6)

This activity notifies the approver that Purchasing failed to reserve funds for the document, and provides instructions for resolving the failure. The approver must use the Approve Document window to try to reserve the document again if, for example, more funds have been allocated, and then respond to the notification with Retry; reject the document; or forward the document to somebody else with authority to reserve the funds.

Is Forward-To Valid? (Node 7)

This function activity checks that the Forward-To name entered in the Forward-To field, in response to an approval notification, is a valid user name.

Set Forward-To/From For Forward Action (Node 8)

If the approver responded to the notification Unable to Reserve Document by forwarding the document, this function activity resets the Forward-To and Forward-From attributes appropriately.

Reject the PO (Node 10)

This function activity updates the status of the document to Rejected and records the rejection in the Action History window. It also reverses encumbrance if the document has been encumbered.

Unable to Reject Document (Node 13)

This activity sends a notification to the approver that Purchasing was unable to reject the document-for example, because its status is closed, frozen, or on hold.

End (Nodes 3, 9, 12, and 14)

This function activity marks the end of the process. Although the activity itself does not have a result type, each node of this activity in the process must have a process result assigned to it. The process result is assigned in the property page of the activity node. Since the Reserve Before Approve subprocess activity has a result type of PO Reserve Before Approve, each End activity node must have a process result matching one of the lookup codes in the PO Reserve Before Approve lookup type.

The following is a description of each activity in the Verify Approval Authority subprocess, listed by the activity's display name.

Start (Node 1)

This is a Standard function activity that simply marks the start of the subprocess.

Does Approver Have Authority? (Node 2)

This function activity verifies the approver's authority based on the authority limits defined in the Approval Groups and Assign Approval Groups windows. See: Defining Approval Groups. See: Assigning Approval Groups.

Document Manager Failed (Node 4)

If the Document Approval Manager fails, the approver receives this notification that it failed. Once a system administrator successfully restarts the Document Approval Manager, the approver must respond to the notification by choosing Retry, so that the workflow can continue.

End (Nodes 3 and 5)

This function activity marks the end of the process. Although the activity itself does not have a result type, each node of this activity in the process must have a process result assigned to it. The process result is assigned in the property page of the activity node. Since the Verify Approval Authority subprocess activity has a result type of Yes/No, each End activity node must have a process result matching one of the lookup codes in the Yes/No lookup type.

The following is a description of each activity in the Approve PO subprocess, listed by the activity's display name.

Start (Node 1)

This is a Standard function activity that simply marks the start of the subprocess.

Is Document Approved? (Node 2)

If you are using encumbrance and the document was Pre-Approved at the time that funds were reserved for it, then its status already changed to Approved.

Does Document State Allow Approval? (Node 4)

Examples of document statuses that allow an approval action are Incomplete, In Process, and Pre-Approved.

Is Document Complete? (Node 8)

This function activity verifies that the document is complete-for example, verifying that all the quantities match, and at least one line and one distribution exist.

Approve the PO (Node 17)

This function activity sets the status of the purchase order to Approved.

Get PO Attributes (Node 19)

This function activity retrieves key values from the purchase order header and lines, in case these have changed, and assigns them to Workflow attributes.

Document Manager Failed (Nodes 9, 11, 12, and 18)

If the Document Approval Manager fails, the approver receives this notification that it failed. Once a system administrator successfully restarts the Document Approval Manager, the approver must respond to the notification by choosing Retry, so that the workflow can continue.

Document Failed State Check (Node 5)

This activity sends a notification to the approver that the document failed the state check. See: Document Status Checks.

Set PO Status to Original Status (Node 6)

This function activity sets the purchase order back to its status before it entered this process activity, if the document has failed the state check.

Unable To Approve (Node 10)

This activity sends a notification to the approver that Purchasing was unable to approve the document.

Reject the PO (Node 13)

This function activity updates the status of the document to Rejected and records the rejection in the Action History window. It also reverses encumbrance if the document has been encumbered.

Unable to Reject Document (Node 14)

This activity sends a notification to the approver that Purchasing was unable to reject the document-for example, because its status is closed, frozen, or on hold.

End (Nodes 3, 7, 15, and 16)

This function activity marks the end of the process. Although the activity itself does not have a result type, each node of this activity in the process must have a process result assigned to it. The process result is assigned in the property page of the activity node. Since the Approve PO subprocess activity has a result type of PO Approval Action and Doc Verification, each End activity node must have a process result matching one of the lookup codes in the PO Approval Action and Doc Verification lookup type.

The following is a description of each activity in the Print Document, Fax Document, and Email Document subprocesses, listed by the activity's display name.

Start (Node 1)

This is a Standard function activity that simply marks the start of the subprocess.

Does User Want Document Printed? (Node 2)

This function activity checks if Print was selected in the Approve Document window when the purchase order was first submitted.

In the Fax Document Process, the function activity Does User Want Document Faxed? checks if Fax was selected in the Approve Document window. CommercePath, or any facsimile software that uses the CommercePath Fax Command Language (FCL), must be installed to use the facsimile functionality.

Print Document (Node 4)

If Print was selected in the Approve Document window when the purchase order was first submitted, this activity prints the document.

In the Fax Document Process, the function activity Fax Document automatically sends a facsimile of the document if a Fax Number was entered in the Approve Document window. CommercePath, or any facsimile software that uses the CommercePath Fax Command Language (FCL), must be installed to use the facsimile functionality.

End (Nodes 3 and 5)

This function activity marks the end of the process. Although the activity itself does not have a result type, each node of this activity in the process must have a process result assigned to it. The process result is assigned in the property page of the activity node. Since the Print Document subprocess activity has a result type of PO Activity Performed, each End activity node must have a process result matching one of the lookup codes in the PO Activity Performed lookup type.

The following is a description of each activity in the Approve and Forward PO subprocess, listed by the activity's display name.

Start (Node 1)

This is a Standard function activity that simply marks the start of the subprocess.

Does Document State Allow Approval? (Node 2)

Examples of document statuses that allow an approval action are Incomplete, In Process, and Pre-Approved.

Is Document Complete? (Node 6)

This function activity verifies that the document is complete-for example, verifying that all the quantities match, and at least one line and one distribution exist.

Approve And Forward The PO (Node 13)

This function activity approves the purchase order and forwards it to the next approver.

Get PO Attributes (Node 14)

This function activity retrieves key values from the purchase order header and lines, in case these have changed, and assigns them to Workflow attributes.

Document Manager Failed (Nodes 9, 16, 17, and 18)

If the Document Approval Manager fails, the approver receives this notification that it failed. Once a system administrator successfully restarts the Document Approval Manager, the approver must respond to the notification by choosing Retry, so that the workflow can continue.

Document Failed State Check (Node 3)

This function activity sends a notification to the approver that the document failed the state check. See: Document Status Checks.

Set PO Status to Original Status (Node 4)

This function activity sets the purchase order back to its status before it entered this process activity, if the document has failed the state check.

Unable To Approve Document (Node 7)

This activity sends a notification to the approver that Purchasing was unable to approve the document because the document was incomplete.

Reject the PO (Node 8)

This function activity updates the status of the document to Rejected and records the rejection in the Action History window. It also reverses encumbrance if the document has been encumbered.

Unable To Reject Document (Node 11)

This activity sends a notification to the approver that Purchasing was unable to reject the document-for example, because its status is closed, frozen, or on hold.

End (Nodes 5, 10, 12 and 15)

This function activity marks the end of the process. Although the activity itself does not have a result type, each node of this activity in the process must have a process result assigned to it. The process result is assigned in the property page of the activity node. Since the Approve and Forward PO subprocess activity has a result type of PO Approval Action and Doc Verification, each End activity node must have a process result matching one of the lookup codes in the PO Approval Action and Doc Verification lookup type.

The following is a description of each activity in the Notify Approver subprocess, listed by the activity's display name.

Start (Node 1)

This is a Standard function activity that simply marks the start of the subprocess.

Approve PO Notification (Node 2)

This activity sends a notification to the approver requesting approval.

This notification's message uses Document type item attributes to call two PL/SQL functions, one that retrieves all of the lines in the document and displays them in the notification, and another that retrieves the action history of the document and displays that in the notification.

PO Approval Reminder 1 (Node 12)

If no approval response is received after a period of time, this activity sends a first reminder if you designate a timeout period in the activity's Properties window.

This notification's message uses Document type item attributes to call two PL/SQL functions, one that retrieves all of the lines in the document and displays them in the notification, and another that retrieves the action history of the document and displays that in the notification.

PO Approval Reminder 2 (Node 22)

If still no approval response is received, this activity sends a second reminder if you've entered a timeout period in the activity's Properties window.

This notification's message uses Document type item attributes to call two PL/SQL functions, one that retrieves all of the lines in the document and displays them in the notification, and another that retrieves the action history of the document and displays that in the notification.

Set Forward-To/From For Approve Action (Nodes 9, 19, and 29)

This function activity resets the Forward-To and Forward-From attributes after an Approve action.

Is Forward-To Valid? (Node 3, 6, 13, 16, 23, and 26)

This function activity checks that the Forward-To name entered in the Forward-To field, in response to an approval notification, is a valid user name.

Set Forward-To/From App. & Fwd. Action (Nodes 4, 14, and 24)

This function activity resets the Forward-To and Forward-From attributes after an Approve and Forward action.

Set Forward-To/From For Forward Action (Nodes 7, 17, and 27 )

This function activity resets the Forward-To and Forward-From attributes after a Forward action.

Set Forward-To/From For Timeout (Node 32)

This function activity resets the Forward-To and Forward-From attributes after the previous activity times out (if a Timeout is associated with it).

End (Nodes 5, 8, 10, 11, 15, 18, 20, 21, 25, 28, 30, 31, and 33)

This function activity marks the end of the process. Although the activity itself does not have a result type, each node of this activity in the process must have a process result assigned to it. The process result is assigned in the property page of the activity node. Since the Notify Approver subprocess activity has a result type of PO Document Approval Action Process, each End activity node must have a process result matching one of the lookup codes in the PO Document Approval Action Process lookup type.

The following is a description of each activity in the Find Approver subprocess, listed by the activity's display name.

Start (Node 1)

This is a Standard function activity that simply marks the start of the subprocess.

Is Forward-To Provided? (Node 2 )

This function activity checks whether the buyer or the approver provided a forward-to user name.

Get Approval Path (Node 4)

This function activity retrieves the approval hierarchy-either a specific approval hierarchy that the buyer provides in the Approve Document window, or the default approval hierarchy in Purchasing.

Get Forwarding Mode (Node 5)

This function activity retrieves the forwarding mode: Hierarchy or Direct. In a Direct mode, the purchase order goes to the first person with enough approval authority. In a Hierarchy mode, each person in the hierarchy must take action until a person with enough approval authority is reached.

Are You Using PO Approval Hierarchies? (Nodes 6 and 13)

This function activity checks whether position hierarchies are being used in approvals. See: Setting Up Document Approval and Security.

Get Next Manager in H.R. (Nodes 10 and 19)

This activity retrieves the buyer's manager if employee/supervisor relationship hierarchies are being used. It gets the buyer's first manager using the HR_EMPLOYEES and HR_ASSIGNMENTS tables.

Get First Manager in Approval Hierarchy (Nodes 7 and 14)

This function activity gets the first manager of the buyer using the PO_EMPLOYEE_HIERARCHIES and HR_EMPLOYEES tables, if position hierarchies are being used.

Does Approver Have Authority? (Nodes 16 and 21)

This function activity verifies the approver's approval authority based on the authority limits defined in the Approval Groups and Assign Approval Groups windows.

Document Manager Failed (Nodes 17 and 22)

If the Document Approval Manager fails, the approver receives this notification that it failed. Once a system administrator successfully restarts the Document Approval Manager, the approver must respond to the notification by choosing Retry, so that the workflow can continue.

End (Nodes 3, 8, 9, 11, 12, 15,18, 20, and 23)

This function activity marks the end of the process. Although the activity itself does not have a result type, each node of this activity in the process must have a process result assigned to it. The process result is assigned in the property page of the activity node. Since the Find Approver subprocess activity has a result type of Yes/No, each End activity node must have a process result matching one of the lookup codes in the Yes/No lookup type.

The following is a description of each activity in the Forward PO subprocess, listed by the activity's display name.

Start (Node 1)

This is a Standard function activity that simply marks the start of the subprocess.

Is PO Pre-Approved? (Node 2)

This function activity checks if the purchase order has been pre-approved. A Pre-Approved document is one that has already been approved by the appropriate individual, who also chose to forward it to yet another person for approval. Or, it is a document that has been authorized for approval but for which funds have not yet been reserved. The PO Approval workflow still considers a document pre-approved until the subprocess Reserve Before Approve or the subprocess Approve PO sets its status to Approved.

Forward PO with Status "In-Process" (Node 4)

If the purchase order status is Incomplete, this activity sets the status to In Process, forwards the purchase order to the approver, and updates the document's action history with the forward action.

Forward PO with Status "Pre-Approved" (Node 8)

If the purchase order status is Pre-Approved, this activity forwards the purchase order to the next approver without changing its status.

Get PO Attributes (Nodes 6 and 10)

This function activity retrieves key values from the purchase order header and lines, in case these have changed, and assigns them to Workflow attributes.

Document Manager Failed (Nodes 5 and 9)

If the Document Approval Manager fails, the person who forwarded the document receives this notification that it failed. Once a system administrator successfully restarts the Document Approval Manager, the approver must respond to the notification by choosing Retry, so that the workflow can continue.

End (Nodes 3, 7, and 11)

This function activity marks the end of the process. Although the activity itself does not have a result type, each node of this activity in the process must have a process result assigned to it. The process result is assigned in the property page of the activity node. Since the Forward PO subprocess activity has a result type of PO Approval Action and Doc Verification, each End activity node must have a process result matching one of the lookup codes in the PO Approval Action and Doc Verification lookup type.

The following is a description of each activity in the Return PO to Submitter subprocess, listed by the activity's display name.

Start (Node 1)

This is a Standard function activity that simply marks the start of the subprocess.

Set PO Status to Original Status (Node 2)

This activity sets the purchase order back to its status before it entered this process activity, if no approver was found.

Notify Preparer Of No Approver Found (Node 3)

This activity sends a notification to the buyer when no approver is found.

This notification's message uses Document type item attributes to call two PL/SQL functions, one that retrieves all of the lines in the document and displays them in the notification, and another that retrieves the action history of the document and displays that in the notification.

Is Submitter Last Approver? (Node 4)

This function activity checks if the buyer is also the sole or last approver. If so, the subprocess skips node 5 so as not to send the buyer two notifications.

Notify Last Approver Of No Approver Found (Node 5)

This activity sends a notification to the last approver that the next approver was not found.

This notification's message uses Document type item attributes to call two PL/SQL functions, one that retrieves all of the lines in the document and displays them in the notification, and another that retrieves the action history of the document and displays that in the notification.

End (Node 6)

This function activity marks the end of the process. Although the activity itself does not have a result type, each node of this activity in the process must have a process result assigned to it. The process result is assigned in the property page of the activity node. Since the Return Requisition to Submitter subprocess activity has a result type of PO Activity Performed, each End activity node must have a process result matching one of the lookup codes in the PO Activity Performed lookup type.

The following is a description of each activity in the Reject PO subprocess, listed by the activity's display name.

Start (Node 1)

This is a Standard function activity that simply marks the start of the subprocess.

Reject The PO (Node 2)

This function activity updates the status of the document to Rejected and records the rejection in the Action History window. It also reverses encumbrance if the document has been encumbered.

Unable To Reject Document (Node 5)

This activity sends a notification to the approver that Purchasing was unable to reject the document-for example, because its status is closed, frozen, or on hold.

Document Manager Failed (Node 4)

If the Document Approval Manager fails, the approver receives this notification that it failed. Once a system administrator successfully restarts the Document Approval Manager, the approver must respond to the notification by choosing Retry, so that the workflow can continue.

End (Nodes 3 and 6)

This function activity marks the end of the process. Although the activity itself does not have a result type, each node of this activity in the process must have a process result assigned to it. The process result is assigned in the property page of the activity node. Since the Reject PO subprocess activity has a result type of PO Approval Action and Doc Verification, each End activity node must have a process result matching one of the lookup codes in the PO Approval Action and Doc Verification lookup type.