Whenever you submit a requisition 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 to modify your approval process.

The requisition 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 Requisition 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 in Purchasing or submit a requisition for approval in Oracle iProcurement.

• 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.

• When you run Requisition Import. If the requisitions are incomplete or preapproved, Requisition Import launches the PO Requisition Approval workflow to approve the requisitions, unless you specify not to.

For information on the purchase order approval workflow, see: Purchase Order 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 customize 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: Monitoring Workflow Processes.

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 Requisition Approval workflow is PO Requisition Approval. The name of its Workflow definition file is poxwfrqa.wft.

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

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

Creating a New Custom Process

You can either modify the default PO Requisition Approval workflow that Purchasing provides, or copy it and create a whole new workflow. You can use the Document Types window to select a custom PO Requisition 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 Requisition 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 Requisition 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 Requisition 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 Requisition Approval Item Type. These sections describe the components of the main processes in the PO Requisition Approval workflow. If you haven't already, see also: Customization Guidelines.

Attributes

You can modify the following attribute only, by changing its Default Value:

• Send PO Autocreate to Background

Its Default Value is Y for Yes, to send automatic document creation to Background mode, but you can change it to N for No, to operate in Online mode. See: Choosing Workflow Options.

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 Requisition 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 process 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.

• Print Document Process

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

• Approve Requisition

• Reject Requisition

• Reserve at the Start

• Reserve Before Approve

• Return Requisition to Submitter

• Verify Approval Authority

• Verify Approval Authority for Approve Action

• Verify Approval Authority for Approve and Forward Action

• Verify Requisition

• Approval List Routing

• Main Requisition Approval

• Notify Approver

• Response with Approve Action

• Response with Approve and Forward Action

• Response with Forward Action

• Response with Reject Action

• Reserve Before Approve

• Start of Approve Requisition Process

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 functions in the PO Requisition 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 Requisition 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 the function activity in the Workflow Builder needs to match the result type specified by that function activity's corresponding PL/SQL procedure-for example, a Result Type of Yes/No. 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 with Processes above, any attributes that were set by the default function activity must also be set by your customized function activity.

• Just as with 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 Requisition Approval process is associated with an item type called PO Requisition Approval. This item type identifies all requisition approval workflow processes available. The following workflow processes are associated with PO Requisition Approval:

• Main Requisition Approval

• Start of Approve Requisition Process

• Verify Requisition

• Reserve At The Start

• Verify Approval Authority

• Approval List Routing

• Reject Requisition

• Return Requisition to Submitter

• Notify Approver

• Response with Approve Action

• Response with Approve and Forward Action

• Response with Forward Action

• Response with Reject Action

• Reserve Before Approve

• Approve Requisition

• Print Document Process

• Verify Approval Authority for Approve Action

• Verify Approval Authority for Approve and Forward Action

The PO Requisition 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 Requisition Approval Workflow Item Type Attributes

The following is a description of each activity in the Main Requisition Approval process.

Start of Approve Requisition Process (Node 2)

See: Start of Approve Requisition Process.

Verify Requisition (Node 3)

See: Verify Requisition.

Reserve At The Start (Node 5)

See: Reserve At The Start.

Does Approval List Exist? (Node 6)

This activity checks if a requester in iProcurement created or modified an approval list.

Build Default Approval List (Node 7)

If a requester in iProcurement did not create or modify the approval list, or if the requisition was submitted in Purchasing, this activity builds an approval list based on the approval hierarchy setup in Purchasing.

Can Owner Approve? (Node 10)

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 Approval List Routing begins.

Verify Approval Authority (Node 15)

See: Verify Approval Authority.

Set Req Status to Pre-Approved (Node 16)

If the requester has the approval authority to approve the document, this function activity sets the requisition's status to Pre-Approved. The status is set to Pre-Approved until the subprocess Approve Requisition or the subprocess Reserve Before Approve explicitly sets the status to Approved.

This activity updates the document status only, not the action history. Later another activity, Update Action History, updates the Action History window.

Is Approval List Empty? (Node 17)

This activity makes sure there are no more approvers. If there are not, the workflow begins approving the requisition. If there are, the workflow routes the document for their approval.

Approval List Routing (Node 11)

See: Approval List Routing.

Reject Requisition (Node 12)

See: Reject Requisition.

Requisition Rejected (Node 13)

This activity sends a notification to the requester that the requisition has been rejected.

Return Requisition to Submitter (Node 8)

See: Return Requisition to Submitter .

Rebuild Approval List After Forward Action (Node 19)

If the requisition is forwarded, this activity rebuilds the approval list to include that forward-to person.

Oracle iProcurement Example:

• Approver A

• Approver B

• Approver C

A requester in iProcurement adds Approvers X and Y:

• Approver A

• Approver B

• Approver C

• Approver X

• Approver Y

Approver C, however, forwards the document to Approver D, who is part of another branch in the hierarchy:

• Approver D

• Approver E

• Approver F

The approval routing will then be as follows, assuming Approver D does not have final approval authority:

• Approver A

• Approver B

• Approver C

• Approver X

• Approver Y

• Approver D

• Approver E

• Approver F

Reserve Before Approve (Node 18)

See: Reserve Before Approve.

Approve Requisition (Node 20)

See: Approve Requisition.

Is Requisition Created Through the Web? (Node 22)

This activity checks if the requisition was created through iProcurement.

Create Information Template Attachment (Node 23)

This activity turns iProcurement information templates, if used, into attachments. The Define Information Template window in Purchasing lets you define these templates for iProcurement. For example, you can create a template for ordering business cards in iProcurement. The template used to gather the business card information is converted into an attachment in Purchasing by this activity.

Requisition Approved (Node 24)

This function activity sends a notification to the appropriate individual that the requisition 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 (Node 25)

See: Print Document Process.

Get AutoCreate PO Mode (Node 26)

While the function activity Get Workflow Approval Mode sets the processing mode for the entire approval workflow in Purchasing, based on how the profile option PO: Workflow Processing Mode is set, this function activity looks to the item attribute Send PO Autocreation to Background, which enables you to change the processing mode specifically for automatic purchase order creation. Background mode enables you to proceed to your next Purchasing activity while the approval process for this document completes in the background.

Wait for Background Process (Node 27)

If the item attribute Send PO Autocreation to Background is set to Yes, 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.

Launch Create PO Workflow (Node 28)

After a requisition is approved, the Main Requisition Approval process launches a workflow for the automatic creation of purchase orders if you've allowed automatic approval for approved requisition lines. Automatic approval is allowed for approved requisition lines when the item attribute Is Automatic Creation Allowed? is set to Y for Yes. (By default, this item attribute is set to Y.)

The following is a description of each activity in the Start of Approve Requisition Process, listed by the activity's display name.

Remove All Notifications For This Document (Node 2)

This function activity removes previous notifications for a requisition previously submitted to 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 requisition.

Set Req Status to In-Process and Update with Item Type & Key (Node 4)

This function activity sets the document status to In Process and updates the document header with the item type and item key, which indicate that this requisition has been submitted to Workflow.

Find Approval List (Node 5)

This activity looks for an approval list created in iProcurement.

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. See: To Schedule Background Engines.

Get Requisition Attributes (Node 8)

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

The following is a description of each activity in the Verify Requisition 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 Action? (Node 2)

This 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 activity verifies that the requisition 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 6)

This 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 3 and 5)

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

Document Failed State Check (Node 8)

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

Document Failed Correctness Check (Node 9)

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

Set Req 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 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 Verify Requisition 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 At The Start 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 Requisition Created Through the Web? (Node 2)

This activity determines if the requisition was created through iProcurement.

Is Interface Source Req Import? (Node 3)

This activity checks if the requisition sent through Requisition Import was created in Web Requisitions Release 11.

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

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

Reserve Document (Node 7)

This activity tries to reserve funds for the document.

Document Manager Failed (Node 10)

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

End (Nodes 4, 6, 8, and 9)

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 at the Start 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 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 3)

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 4 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 Approval List Routing subprocess, listed by the activity's display name.

Get Next Approver (Node 2)

This activity finds the first (or next) approver in the approval list.

Rebuild Approval List for Invalid Approver (Node 3)

If an approver is invalid (for example, the approver left the company shortly after the requisition was submitted), this activity rebuilds the approval list without that approver.

Notify Approver (Node 5)

See: Notify Approver.

Response with Reject Action (Node 6)

See: Response with Reject Action.

Response with Approve Action (Node 9)

See: Response with Approve Action.

Response with Approve and Forward Action (Node 10)

See: Response with Approve and Forward Action.

Is Approval List Empty? (Node 11)

This activity makes sure there are no more approvers. If there are not, the workflow begins approving the requisition. If there are, the workflow routes the document for their approval.

Is Requisition 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. A document is still considered pre-approved until the subprocess Reserve Before Approve or the subprocess Approve Requisition sets its status to Approved.

The following is a description of each activity in the Reject Requisition 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 Requisition (Node 2)

This activity sets a requisition to a Rejected status. 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 Requisition 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 Requisition 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 Req Status to Original Status (Node 2)

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

Notify Requestor of No Approver Available (Node 3)

This activity sends a notification to the requestor 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 requester is also the sole or last approver. If so, the subprocess skips node 5 so as not to send the requester 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 Notify Approver subprocess, listed by the activity's display name.

Update Action History (Expect Response) (Node 2)

This activity records in the action history that the document awaits a response from the approver. This activity works in conjunction with the other Update Action History activities, used in other subprocesses, to update the Action History window.

Approve Requisition Notification (Node 3)

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.

Requisition Approval Reminder1 (Node 10)

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.

Requisition Approval Reminder 2 (Node 17)

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.

Is Forward-To Valid (Nodes 4, 8, 11, 15, 18, and 22)

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.

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

Update Approval List Response (Node 2)

This activity updates the Oracle internal approval list tables PO_APPROVAL_LIST_HEADERS and PO_APPROVAL_LIST_LINES with the approver's approval.

Update Action History (Approve) (Node 3)

This activity records an Approve action action in the Action History window.

Set Req Status to Pre-Approved (Node 8)

A requisition's status is set to Pre-Approved if any of the following has occurred:

• It has already been approved by the appropriate individual, who also chose to forward it to yet another person for approval.

• It has been authorized for approval but funds have not yet been reserved for it.

• The document has been approved but the subprocess Approve Requisition or the subprocess Reserve Before Approve has not yet set its status to Approved.

This activity updates the document status only, not the action history.

Is Requisition Pre-Approved? (Node 4)

This function activity checks if the purchase order has been pre-approved.

Verify Approval Authority for Approve Action (Node 6)

See: Verify Approval Authority for Approve Action.

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

Update Action History (Approve/Forward) (Node 2)

This activity records an Approve and Forward action in the Action History window.

Verify Approval Authority for Approve and Forward Action (Node 4)

See: Verify Approval Authority for Approve and Approve/Forward Action.

Set Req Status to Pre-Approved (Node 5)

A requisition's status is set to Pre-Approved if any of the following has occurred:

• It has already been approved by the appropriate individual, who also chose to forward it to yet another person for approval.

• It has been authorized for approval but funds have not yet been reserved for it.

• The document has been approved but the subprocess Approve Requisition or Reserve Before Approve has not yet set its status to Approved.

This activity updates the document status only, not the action history.

Is Requisition Pre-Approved? (Node 3)

This function activity checks if the requisition has been pre-approved.

Update Approval List Response (Node 6)

This activity updates the Oracle internal approval list tables PO_APPROVAL_LIST_HEADERS and PO_APPROVAL_LIST_LINES with the approver's approval and forward action.

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

Update Approval List Response (Node 2)

This activity updates the Oracle internal approval list tables PO_APPROVAL_LIST_HEADERS and PO_APPROVAL_LIST_LINES with the approver's forward action.

Update Action History (Forward) (Node 3)

This activity records a Forward action in the Action History window.

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

Update Approval List Response (Node 2)

This activity updates the Oracle internal approval list tables PO_APPROVAL_LIST_HEADERS and PO_APPROVAL_LIST_LINES with the approver's rejection.

Update Action History (Reject) (Node 3)

This activity records a Reject action in the Action History window.

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

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 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 requester that Purchasing failed to reserve funds for the requisition, and provides instructions for resolving the failure. The approver must then use the Approve Document window to try to reserve the document again if, for example, more funds have been allocated, and then respond with Retry in the notification; reject the document; or forward the document to somebody else with authority to reserve the funds.

Is Forward-To Valid (Node 7)

This 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 Forward (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.

Reject the Requisition (Node 10)

This activity sets a requisition to a Rejected status 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 properly reject the requisition-for example, because its status is closed, frozen, or on hold.

The following is a description of each activity in the Approve Requisition 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 Action? (Node 4)

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

Is Document Complete? (Node 6)

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

Approve the Requisition (Node 8)

This activity sets the status of the requisition to Approved.

Get Requisition Attributes (Node 14)

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

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

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 10)

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

Document Failed Correctness Check (Node 11)

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

Set Req Status to Original Status (Node 12)

This function activity sets the requisition back to its original status, if the document has failed state or correctness checks.

End (Nodes 3 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 Approve Requisition 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 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 User Want Document Printed? (Node 2)

This activity checks if Print was selected when the requisition was first submitted.

Print Document (Node 4)

If Print was selected when the requisition was first submitted, this activity prints the document.

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 Verify Approval Authority for Approve Action subprocess and the Verify Approval Authority for Approve and Forward Action subprocess, listed by the activity's display name.

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 3)

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.