Procurement Workflows

Overview of Procurement Workflows

Purchasing uses Oracle Workflow technology to handle requisition and purchase order approvals, automatic creation of purchase orders and releases, purchase order changes (specifically, any additional approvals those changes require), notifications, and receipt confirmation. Workflow is an underlying technology that automates these procurement activities. Workflow comes with a graphical user interface that enables you to modify these procurement workflow processes to suit your business needs.

Purchasing comes with the following workflows:

Related Topics

Customization Guidelines

Customization Guidelines

Following are some of the important guidelines you should follow when customizing any workflow in Purchasing.

Access Levels

In the Workflow Builder, some of activities in the procurement workflows are locked, or protected against customization, and some are unlocked, or available for modification to suit your business needs. You should not change your access level to modify locked activities.

For more, important information on access levels, see Overview of Workflow Access Protection, Oracle Workflow Developer's Guide and Allowing Access to an Object, Oracle Workflow Administrator's Guide.

Backups and Testing

Always make a backup and test your customized workflow on a test database before uploading it to your actual database. The sections in this documentation describing each workflow in Purchasing let you know if you should modify the default workflow that Purchasing provides or if you can create a new one. For more, important information on saving, backing up, and uploading customized workflows, see the Oracle Workflow Developer's Guide.

Upgrade Support

Future upgrades of Purchasing can include upgrades to the Purchasing workflows. As you customize workflows, think about whether to protect your customizations against future upgrades. For complete information, see the Oracle Workflow Developer's Guide.

Workflow Monitor

You can use the Workflow Monitor to monitor a workflow's progress. See: Overview of Workflow Monitoring, Oracle Workflow User's Guide.

Guidelines

It is important to use these guidelines in conjunction with information in the Oracle Workflow documentation. In addition, refer to the documentation for each workflow in Oracle Purchasing for a list of activities you can and cannot customize, and other recommendations particular to the workflow. You can also use the Item Type Definitions Web page to extract detailed information about each activity in a workflow. See: Item Type Definitions, Oracle Workflow Developer's Guide.

See also: Oracle Workflow Support Policy, Oracle Workflow Developer's Guide.

Attributes

You can modify only the attributes listed as customizable in the documentation for each Purchasing workflow.

Processes

If you modify a customizable 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 Document subprocess in the approval workflows 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 a customizable process, either by replacing a portion of its flow or by adding additional function activities, keep in mind:

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

Important: This script gives you an idea of the impact of removing a function activity; however, before you customize a process, always conduct your own analysis of the impact.

To run powfcust.sql:

  1. Change to the directory where the PL/SQL-stored procedures are kept:

     cd $PO_TOP/sql

  2. At the SQL prompt, start the following script:

     @powfcust.sql

  3. When prompted, enter the internal name for the workflow item type for which you want to run the script, or enter ALL to run the script for all of the Purchasing workflows.

    The internal workflow names for Purchasing are as follows:

    Workflow Internal Name
    PO Account Generator POWFPOAG
    PO Requisition Account Generator POWFRQAG
    PO Approval POAPPRV
    PO Requisition Approval REQAPPRV
    PO Create Documents CREATEPO
    PO Confirm Receipts PORCPT
    PO Send Notifications for Purchasing Documents APVRMDER
    PO Catalog Price Tolerance Exceeded Notifications POPRICAT

    The script displays every function activity in the workflow that uses a SetItemAttr, GetItemAttr, SetItemUserKey, SetItemOwner, Insert Into, or Update statement.

    Recall that this script gives you an idea of the impact of removing a function activity. Before you customize a process, always conduct your own analysis of the impact.

Notifications

If a 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, Oracle Workflow Developer's Guide. See also: Message Result, Oracle Workflow Developer's Guide and To Create a Message, Oracle Workflow Developer's Guide.

Function Activities

Usually, you cannot modify a function activity, but can replace it with one of your own, unless the documentation for the workflow advises against removing default function activities.

When you replace a function activity, you are effectively modifying the process in which it is contained. If you substitute default function activities in a process with function activities that you create, you must remember the following:

Lookup Types

If you change a customizable lookup type, be sure that all activities that use the lookup type allow for the change. For example, if you change a lookup type from Yes/No to something else, the activities that use that lookup type should also change their Result Type from Yes/No to whatever new lookup type you created. See: Lookup Types, Oracle Workflow Developer's Guide.

Related Topics

Using the Account Generator in Oracle Purchasing

Purchase Order Approval Workflow

Requisition Approval Workflow

Workflow Processes for Approving Change Orders

Workflow for Creating Purchase Orders and Releases

Confirm Receipts Workflow

Send Notifications Workflow

Price/Sales Catalog Notification Workflow

Using the Workflow Monitor for the Account Generator

Using the Workflow Monitor for the PO Create Documents Workflow

Process Navigator Workflows

Using the Account Generator in Oracle Purchasing

This essay describes how to use and customize the default Account Generator process in Oracle Purchasing.

The Account Generator in Oracle Purchasing utilizes Oracle Workflow. You can view and customize Account Generator processes through the Oracle Workflow Builder. You can also monitor account generation through the Oracle Workflow Monitor. See: Oracle Workflow User's Guide.

All purchase orders, requisitions, and releases require accounting distributions. Oracle Purchasing automatically builds a charge, budget (if using budgetary control), accrual, and variance account for each document distribution.

Oracle Purchasing provides you with the features you need to:

See also: Overview of Account Generator, Oracle Applications Flexfields Guide.

Decide How to Use the Account Generator

Use the following sections to help you evaluate whether the default Account Generator process meets your accounting requirements.

This decision determines which setup steps your implementation team needs to perform.

Decide How to Use the Account Generator

In Release 10, several Oracle Applications products used FlexBuilder to derive account code combinations for certain account transactions. In Release 11, FlexBuilder is replaced by the Account Generator to provide implementation teams with even greater flexibility and a better user interface with Oracle Workflow.

If you customized FlexBuilder in a previous release to generate account combinations, you can use the Generate Accounts Using FlexBuilder Rules process to replicate your FlexBuilder setup automatically, without changing any of your predefined FlexBuilder Rules, and without customizing the Account Generator. To build accounts, the Generate Accounts Using FlexBuilder Rules process calls the appropriate functions that were generated during your upgrade

Note: If you used FlexBuilder in Release 10 but did not customize the default configuration, you can use the default Account Generator process in Release 11, which gives you the same result as the default assignments in FlexBuilder.

If you are implementing Oracle Purchasing for the first time, you need to review how Purchasing uses the Account Generator to build Accounting Flexfield code combinations. See: What the Account Generator Does in Oracle Purchasing, below. Consider whether the default Account Generator process is appropriate for each ledger that uses a unique Accounting Flexfield structure. For each structure and ledger, you can choose one of the following:

No setup steps are required to use the default. The default processes can also be updated later as your needs change.

Prerequisites to Using the Account Generator

Before using the Account Generator on a production database in Oracle Purchasing to build accounts for purchase order, release, and requisition distributions, you must complete the following steps:

Important: These steps need to be performed for each operating unit.

  1. Define your Accounting Flexfield structure for each ledger.

  2. Define flexfield segment values and validation rules.

  3. Set up Oracle Workflow.

  4. Choose whether you want to use the default Account Generator processes, or if you need to customize them to meet your accounting needs.

  5. Then do one of the following for each ledger:

    • Choose to use the default Account Generator processes.

    • Customize the default Account Generator processes, test your customizations, and choose the processes for a flexfield structure, if necessary.

Related Topics

The Default Account Generator Processes for Oracle Purchasing

Customizing the Account Generator for Oracle Purchasing

What the Account Generator Does in Oracle Purchasing

The default Account Generator processes in Oracle Purchasing build a charge, budget, accrual, and variance account for each purchase order, release, and requisition distribution based on the distribution's Expense, Inventory, or Shop Floor destination type. Oracle Purchasing always builds these accounts using the Account Generator; you cannot disable this feature.

If you utilize the centralized procurement functionality, the Account Generator will also create two new accounts to record accounting transactions between the procuring organization and the destination organization: the destination charge account and the destination variance account. These accounts will be created and used only when the destination organization is in a different operating unit than the Procuring organization, and there is a transaction flow defined between the two organizations. (Note that if the two operating units are in different sets of books, there must be a transaction flow defined.) For example: In the centralized procurement scenario a user may create a purchase order in one operating unit, but require shipment to a different operating unit. In this case, there will be an accounting transaction (created at the time of receipt of goods) to record the transfer of ownership between the two organizations (operating units). If these accounts are not required they will be not be built.

For Inventory charge account construction, the Account Generator further distinguishes between asset and expense purchases based on the item and subinventory that you provide for the distribution. If you select an expense item, the Account Generator disregards the subinventory and builds an expense charge account. If you select an asset item, the Account Generator evaluates the subinventory to decide whether to build an expense or asset charge account.

Additional Information: You classify a subinventory as expense or asset by selecting the Asset Subinventory check box in the Oracle Inventory Subinventories window. You classify an item as expense or asset by selecting the Inventory Asset Value check box in the Costing section of the Master Item window. (This window is accessible through Inventory or Purchasing.)

When the Account Generator locates a source account based on the distribution destination type, it copies complete code combinations (full Accounting Flexfields) from designated fields to destination Accounting Flexfields. The default Oracle Purchasing processes do not build individual flexfield segments.

For example, to populate the Accrual account for distributions with an Expense destination type, the Account Generator locates the Expense AP Accrual Account that you specify in the Purchasing Options window as part of your application setup, and copies it into the Accrual Account Flexfield in your document.

An exception is when the account generator is unable to derive a charge account in the first two steps. Then an account is retrieved from the HR employee record and individual segments are replaced based on the item category. This is a typical scenario when using one-time items in Oracle Purchasing.

the picture is described in the document text

The following matrix describes the source fields that the Account Generator references to build the charge, budget, accrual, and variance account based on the distribution destination type.

The horizontal axis lists the windows you use to specify the source accounts that the Account Generator references in Oracle Purchasing. The vertical axis lists the possible destination types for each account type the Account Generator constructs. In addition, the Additional Conditions are applied as part of the vertical access. The body of the matrix lists the fields you use to enter the reference accounts.

When more than one option is indicated for a particular account/destination type combination, the Account Generator attempts to locate the primary source account identified in the matrix (Seq) with a 1 as long as any Additional Conditions listed are met. This means that there may be several source accounts with a 1, since there may be multiple Additional Conditions. The first additional condition met will be the source attempted. If this reference account is unavailable or not appropriate for the distribution information you provide, the Account Generator tries the source indicated as 2 and so on until it either successfully locates a reference account, or fails. When an account has been located, or the Account Generator has failed to find an account, the matrix may indicate that an Override condition may apply. These entries are indicated by an O instead of a numeric value. In the case of an Override, a built account may be superceeded.

Default Charge Account Sources
Destination Types Additional Consider- ations Seq WIP Accounting Classes Sub- inventories Organizat- ion Parameters Items (INV or PO) Purchasing Options Other
All Destination Types Cross OU case and One-Time Item or a Shop Floor enabled Item 1     Cost of Sales Account for Transaction Flow default org      
All Destination Types Cross OU case and Expense item 1       Expense    
All Destination Types Cross OU case and Expense item 2     Expense      
All Destination Types Cross OU case and Asset item 1     Material      
All Destination Types PO auto-created from requisition 1           Copied from requisition
Expense Not a PO autocreated from req and not prevented by PA override profile 1           Preferences
Expense Project related 2           Customized Project rules
Expense Project Related and not prevented by PA override profile O           User entered
Expense Not a PO autocreated from a req. Not Project. 1           Preferences
Expense Non-Project 2       Expense    
Expense Non-Project 3           Employee Profile for Assignment in Purchasing OU's SOB
Expense Non-Project Account not built before HR Employee Profile step 3O           Item Category Segment substitutions
Expense Non-Project O           User entered
Inventory Expense item 1   Expense        
Inventory Expense item 2       Expense    
Inventory Expense item 3     Expense      
Inventory Asset item 1   Material        
Inventory Asset item 2     Material      
Shop Floor   1           Enterprise Asset Mgmt (EAM) rules
Shop Floor   2a Material          
Shop Floor   2b Mat. Overhead          
Shop Floor   2c Resource          
Shop Floor   2d Outside Processing          
Shop Floor   2e Overhead          
Default Accrual Account Sources
Destination Types Additional Consider- ations Seq WIP Accounting Classes Sub- inventories Organiz- ation Parameters Items (INV or PO) Purchasing Options Other
All Destination Types Cross OU case (No additional sources are used) 1         Expense AP Accrual Account for PO OU  
All Destination Types OPM is installed. Not Project related. 1           OPM API
Expense Project related 1           Customized Project rules
Expense OPM is not installed. Not Project related. 1         Expense AP Accrual Account  
Inventory, Shop Floor OPM is not installed. One-time item. 1         Expense AP Accrual Account for PO OU  
Inventory, Shop Floor OPM is not installed. Not one-time item. 1     Inventory AP Accrual for Ship-to org      
Default Budget Account Sources
Destination Types Additional Consider- ations Seq WIP Accounting Classes Sub- inventories Organiz- ation Parameters Items (INV or PO) Purchasing Options Other
Expense or Inventory PO auto-created from requisition 1           Copied from requisition
Expense   1           Charge Account
Expense   O           User entered
Inventory   1   Encumbrance        
Inventory   2       Encumbrance    
Inventory   3     Encumbrance for ship-to org      
Shop Floor No encumbrance is done for Shop Floor 1 n/a n/a n/a n/a n/a n/a
Default Variance Account Sources
Destination Types Additional Consider- ations Seq WIP Accounting Classes Sub- inventories Organization Parameters Items (INV or PO) Purchasing Options Other
All Destination Types Cross OU case (No additional sources are used) 1           Charge Account
All Destination Types PO auto-created from requisition 1           Copied from requisition
Expense Project-related 1           Customized Project rules
Expense Project-related 2           Customized Project rules
Expense Non-Project 1           Charge Account
Inventory   1     Inventory Price Variance for Ship-to org      
Shop Floor One-time Item 1           Charge Account
Shop Floor   1     Inventory Price Variance for Ship-to org      
Default Destination Charge Account Sources
Destination Types Additional Consider- ations Seq WIP Accounting Classes Sub- inventories Organizat- ion Parameters Items (INV or PO) Purchasing Options Other
All Destination Types PO auto-created from requisition 1           Copied from requisition charge account
Expense Project related 2           Customized Project rules
Expense Project Related and not prevented by PA override profile O           User entered
Expense Not a PO autocreated from a req. Not Project. 1           Preferences
Expense Non-Project 2       Expense    
Expense Non-Project 3           Employee profile for deliver-to-person's HR assignment in destination OU SOB
Expense Non-Project Account not built before HR Employee Profile step 3O           Item Category Segment substitutions
Expense Non-Project O           User entered
Inventory Expense item 2   Expense        
Inventory Expense item 3       Expense    
Inventory Expense item 4     Expense      
Inventory Asset item 2   Material        
Inventory Asset item 3     Material      
Shop Floor   2           Enterprise Asset Mgmt (EAM) rules
Shop Floor   3a Material          
Shop Floor   3b Mat. Overhead          
Shop Floor   3c Resource          
Shop Floor   3d Outside Processing          
Shop Floor   3e Overhead          
Default Destination Variance Account Sources
Destination Types Additional Consider- ations Seq WIP Accounting Classes Sub- inventories Organization Parameters Items (INV or PO) Purchasing Options Other
Expense PO auto-created from requisition 1           Copied from requisition Variance Account
Expense Project related 1           Customized Project rules
Expense Project related 2           Destination Charge Account
Expense Non-Project 1           Destination Charge Account
Inventory   1     Inventory Price Variance for Ship-to org      
Shop Floor One-time Item 1           Destination Charge Account
Shop Floor   1     Inventory Price Variance for Ship-to org      

Tip: Minimize your setup by specifying source accounts at the appropriate level of detail for your business. For example, you can specify the charge account source for Inventory (expense) destination types at the subinventory, item, or organization level. If an organization level account is sufficient for your business needs, it is not necessary to specify item or subinventory accounts.

For Shop Floor destination types, if no WIP accounting class (WAC) encumbrance account is found, then the Costing API searches from Item and if at the Item level the account is not defined, Costing API selects the encumbrance account defined in Organization parameters. For such distributions, the Account Generator calls the Costing API, which gets encumbrance account from WIP accounting class encumbrance field. The Account Generator does construct a budget account for Shop Floor distributions if linked work order is an EAM job. Oracle Purchasing does encumber outside processing purchases for EAM work orders.

Important: If the Account Generator is unable to build a charge account you can either manually specify a charge account in your document or you can design a custom Account Generator function to build Expense destination charge accounts based on your own business rules.

While you cannot edit the accrual, budget, or variance accounts that the Account Generator constructs, you can override or specify the charge account for uncommitted Expense distributions. In this case, you can either edit the charge account that the Account Generator constructs for you, or you can specify a default charge account in the Defaults region of your document. When you specify a default charge account, it always overrides any expense charge account that the Account Generator tries to provide.

Account Build Timing and Logistics

For Expense and Inventory destinations in the Requisitions, Purchase Orders, and Releases windows, the Account Generator constructs the account when you navigate into the distribution Charge Account field, or when an explicit or implicit commit anywhere in the window provides enough information for Oracle Purchasing to create a distribution. For Shop Floor destinations, the code is constructed when you enter all required data in the Outside Processing region and either return to the document distributions region or commit.

For all windows, the build sequence is:

  1. Charge

  2. Budget

  3. Accrual

  4. Variance

  5. Destination Charge

  6. Destination Variance

Each account is provided as a possible source value to the subsequent builds. For example, the budget rules accept the charge account as a possible value, and for Expense destination types the charge account value is copied into the Budget Account field. The accrual account rules accept both the charge and budget account values. Finally, the variance account rules accept the charge, budget, and accrual account values as possible sources.

If the Account Generator is unable to construct accrual, variance, or budget accounts you cannot enter these fields to manually provide the missing values. You must identify and resolve the problem that is causing the Account Generator to fail. If the Account Generator is unable to construct a charge or budget account, you can manually specify the missing values if the destination type is Expense. Since budget and variance account rules take the charge account value for Expense destination types, the Account Generator tries to construct these accounts as soon as you manually provide a charge account if it was unable to find one during the initial build attempt.

The Account Generator Does Not Rebuild After You Update a Document

Consistent with prior release's functionality, once the Account Generator successfully builds accounts for a document, it does not attempt to rebuild when you update the document. For example, if you build a custom process to generate the requisition charge account for Expense purchases based on requestor, and change the requestor after the Account Generator constructs the charge account, it will not attempt to rebuild.

Requisition Import does not use the Account Generator to construct charge, budget, accrual, or variance accounts. Any custom process that you create cannot be used by this utility.

Related Topics

Customizing the Account Generator for Oracle Purchasing

The Default Account Generator Processes for Oracle Purchasing

Using the Workflow Monitor with the Account Generator

Customizing the Account Generator for Oracle Purchasing

Oracle Purchasing provides default Account Generator processes for you to use. If the defaults do not satisfy your accounting requirements, you can use the Oracle Workflow Builder to customize the default processes.

Before you use or modify any of the workflows in Purchasing, read the setup information at the beginning of this document.

For more information on the generic features and functions of the Account Generator, see the Customizing the Account Generator section of the Oracle E-Business Suite Flexfields Guide.

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

You can use the Workflow Monitor to follow where certain documents are in a workflow process. If you encounter problems while the Account Generator builds accounts, set the profile option Account Generator: Run in Debug Mode to Yes to help you locate the problem. (Always set it back to No after you are finished, to maintain performance.) See: Using the Workflow Monitor with the Account Generator.

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, Oracle Workflow Developer's Guide.

    The Display name of the Account Generator workflow for purchase orders is PO Account Generator. The name of its Workflow definition file is poxwfpag.wft.

    The Display name of the Account Generator workflow for requisitions is PO Requisition Account Generator. The name of its Workflow definition file is poxwfrag.wft.

    the picture is described in the document text

  2. Expand the data source, then the Account Generator item type branch within that data source.

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

Creating a New Custom Process

If you want to customize the PO Account Generator or the PO Requisition Account Generator workflows, you must customize the default (original) workflows that Purchasing provides. Unlike the PO Approval, PO Requisition Approval, and PO Create Documents workflows in Purchasing, only one Account Generator workflow can be called from the application itself, through the Account Generator Processes window. You can't select a separate customization, like you can with the other workflows in the Document Types window. Therefore, you need to make your customizations to the default Account Generator workflows. Have your backup to revert to, if you need, while you are testing your customizations.

Required Modifications

There are no required modifications you need to make to the PO Account Generator or the PO Requisition Account Generator workflows, unless you need to customize them to suit your business requirements. See: Decide How to Use the Account Generator.

Supported and Unsupported Customizations

Following is a discussion of what you can and definitely cannot modify in both the PO Account Generator and PO Requisition Account Generator workflows. 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 Default Account Generator Processes for Oracle Purchasing. These sections describe the components of the main processes in the PO Account Generator and the PO Requisition Account Generator workflows. If you haven't already, see also: Customization Guidelines.

Important: If a particular Workflow object does not appear in the following sections on the lists of things you can customize, do not modify it, regardless of its access level.

Attributes

You cannot modify any attributes in the PO Account Generator or the PO Requisition Account Generator.

Processes

If you modify a process, it is essential that the basic flow be maintained. For example, the Get Expense Account ID function activity in the Build Expense Charge Account subprocess sets the item attribute Temp Account ID with the code combination identification number (CCID) of the account being built. This attribute is used by the function activity Copy Values from Account ID to fetch the concatenated segments. Therefore, if you replace the function activity Get Expense Account ID with one of your own, your new function activity must also set the item attribute Temp Account ID.

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

You can modify the following processes in both the PO Account Generator and the PO Requisition Account Generator, as your business needs require:

You cannot modify the following processes in the PO Account Generator or the PO Requisition Account Generator:

Function Activities

You cannot modify any function activities in the PO Account Generator or PO Requisition Account Generator. However, you can modify the Set Encoded Error Message function activity by changing its attributes in the Workflow Builder. See: To use the Set Encoded Error Message function activity, below.

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 Account Generator processes in the section Processes.

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

This function activity is not used by any process in the workflow, but is provided if you need to create a customized error message. To use this function activity to send a customized error message, do the following:

To use the Set Encoded Error Message function activity:

  1. Create the message in the Oracle Applications Message Dictionary.

    You must first define the error message in the Oracle Applications Message Dictionary before it can be used by this function activity. For instructions, see the online help for the Messages window in the Application Developer responsibility, or see the Oracle E-Business Suite Developer's Guide.

  2. Drag and drop the Set Encoded Error Message function activity into the process diagram of the process you want to modify.

  3. Select the activity in the process diagram and choose Properties from the Edit menu.

  4. In the Node Attributes region, enter the Message Name of the message you defined in the Message Dictionary and optionally enter one or more tokens to provide dynamic text for the error message.

    The Application Code defaults to PO (Purchasing), but you can change it if you are displaying the error message in another application.

Lookup Types

The PO Account Generator and PO Requisition Account Generator use the following two Lookup Types provided by the PO Standard workflow; you cannot modify these Lookup Types:

For information on the default lookup types provided by the Standard Flexfield Workflow, see the Account Generator section/chapter of the Oracle E-Business Suite Flexfields Guide.

Implementing a Customized Account Generator Process

Use the Account Generator Processes window to choose either the Generate Default Accounts process or the Generate Accounts Using FlexBuilder Rules process and associate the process with the appropriate Accounting Flexfield structure and item type.

If you customize any of the customizable processes belonging to the Generate Default Accounts process, and you make sure the Generate Default Accounts process is associated with the appropriate Accounting Flexfield structure and item type in the Account Generator Processes window, your customizations will take effect.

Choosing the Process for a Flexfield Structure

  1. Navigate to the Account Generator Processes window by switching to the System Administrator responsibility and choosing Application > Flexfield > Key > Accounts.

  2. With your cursor in the Application field, choose View > Find and select the combination of Application, Flexfield Title, and Structure that you need.

    Or, perform a Query > Run and locate the PO Account Generator and PO Requisition Account Generator item types in the Item Type column.

  3. In the Process field, specify the process-Generate Default Accounts or Generate Accounts Using FlexBuilder Rules-that you want to use to generate these accounts.

    The default process, Generate Default Accounts, will default in.

Related Topics

Using the Account Generator in Oracle Purchasing

The Default Account Generator Processes for Oracle Purchasing

Using the Workflow Monitor with the Account Generator

The Default Account Generator Processes for Oracle Purchasing

Oracle Purchasing comes with the following Account Generator workflow item types-the first for purchase orders and releases, and the second for requisitions:

Each Account Generator workflow contains the following top-level processes:

Generate Default Accounts consists of four main subprocesses:

Other subprocesses are as follows:

Each Account Generator contains a number of item attributes. These attributes correspond to all the raw parameters and some derived parameters that were used in FlexBuilder. Each account ID is provided as a possible source value, in the form of an item attribute, to the subsequent account being built.

The item type attributes in both account generator item types are listed below.

Account Generator Workflow Item Type Attributes

Display Name Description Type Length/Format/ Lookup Type
Accrual Account ID Unique identifier for the accrual account Number  
Blanket PO Header ID Unique identifier for the suggested source blanket agreement or catalog quotation header Number  
BOM Cost Element ID Unique identifier for the Bill of Materials cost element Number  
BOM Resource ID Unique identifier for the Bills of Material resource Number  
Budget Account ID Unique identifier for the budget account Number  
Category ID Unique identifier for the item category Number  
Charge Account ID Unique identifier for the charge account Number  
Chart of Accounts ID Unique identifier for the chart of accounts Number  
Deliver to Location ID Unique identifier for the deliver-to location Number  
Destination Organization ID Unique identifier for the final destination organization Number  
Destination Subinventory Subinventory for inventory purchases Text  
Destination Type Code Final destination of the purchased items Text  
Distribution att1-15 Descriptive flexfield segment Text  
Document Type Code Document type Text  
Error Message Oracle Applications message name Text  
Expenditure Category Expenditure category Text 30
Expenditure Item Date Project accounting expenditure item date Date  
Expenditure Organization ID Unique identifier for the project accounting expenditure organization Number  
Expenditure Organization Name Name of the expenditure organization Text 60
Expenditure Type Project accounting expenditure type Text  
Header att1-15 Descriptive flexfield segment Text 150
Item ID Unique identifier for the item Number  
Line att1-15 Descriptive flexfield segment Text 150
Line Type ID Unique identifier for the line type Number  
PA Billable Flag Indicator of whether an item charged to a task can accrue revenue Text  
PO Encumbrance Flag Indicator of whether the distribution is encumbered Text 4
Preparer ID Unique identifier for the document preparer Number  
Project Class Code Class code for the project Text 30
Project ID Unique identifier for the project to which the item is charged Number  
Project Number Project number to which the item is charged Text 25
Project Organization ID Unique identifier for the organization responsible for the project work Number  
Project Organization Name Organization responsible for the project work Text 60
Project Type Project type that classifies the project Text 20
Public Sector Flag Indicator of whether the project is in the public or private sector Text 1
Revenue Category Classifier of the expenditure type into a revenue group Text 30
Shipment att1-15 Descriptive flexfield segment Text 150
Source Document Header ID Unique identifier for the source document header Number  
Source Document Line ID Unique identifier for the source document line Number  
Source Document Type Code Source document type Text  
Source Organization ID Unique identifier for the inventory source organization Number  
Source Subinventory Inventory source subinventory name Text  
Suggested Vendor ID Unique identifier for the suggested supplier Number  
Source Type Code Source type of the item Text  
Supplier Employee Number Number used by Oracle Projects to identify the person associated with a supplier    
Supplier Person ID Unique identifier used by Oracle Projects to identify the person associated with a supplier    
Supplier Type Supplier type, such as Employee or Supplier Text 25
Task ID Unique identifier for the task Number  
Task Number Task number Text 25
Task Organization ID Unique identifier of the organization responsible for the task work Number  
Task Organization Name Organization responsible for the task work Text 60
Task Service Type Type of work performed for the task Text 30
Temp Account ID Unique identifier for the code combination of the account being built Number  
To Person ID Unique identifier for the deliver-to person Number  
Top Task ID Unique identifier for the top task to which a task rolls up Number  
Top Task Number Number of the top task to which a task rolls up Text 25
Type Lookup Code Type of the document Text  
Vendor ID Unique identifier for the supplier Number  
WIP Entity ID Unique identifier for the Work in Process job or repetitive assembly Number  
WIP Entity Type Work in Process entity type code Text  
WIP Line ID Unique identifier for the Work in Process line Number  
WIP Operation Seq Num Work in Process operation sequence number within a routing Number  
WIP Repetitive Schedule ID Unique identifier for the Work in Process repetitive schedule Number  
WIP Resource Seq Num Work in Process resource sequence number Number  

Summary of the Generate Default Accounts Process

To view the properties of the Generate Default Accounts process, select the process in the navigator tree, then choose Properties from the Edit menu. The Generate Default Accounts process has a result type of Flexfield Result, indicating that when the process completes, it has a result of Failure or Success. These results correspond to the lookup codes in the Flexfield Result lookup type in the Standard Flexfield Workflow item type.

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

The Details property page of the process activity indicates that the Generate Default Accounts process has an error process called DEFAULT_ERROR associated with it, which gets initiated only when an error is encountered in the process. This error would initiate DEFAULT_ERROR, which is associated with the System:Error item type. Currently the process simply executes the standard Default Error Notification activity to provide information associated with the error. You can customize the process further to suit your needs. See: Oracle Workflow GuideDefault Error Process, Oracle Workflow Developer's Guide.

For more information on when the Account Generator process is initiated, see the subsection Account Build Timing and Logistics in: What the Account Generator Does in Oracle Purchasing.

the picture is described in the document text

Generate Default Accounts is the default workflow process in Purchasing that builds the accounts.

Node 2 checks if a charge account has already been manually entered on the document. (For example, you can override or specify the charge account for uncommitted Expense distributions.) If a charge account already exists, this process skips the charge account generation process at node 3 and proceeds to node 7, which determines whether a budget account is needed.

the picture is described in the document text

Nodes 3, 8, 11, and 13 build the charge, budget (if node 7 finds that budgetary control is used), accrual, and variance accounts. These nodes end in failure at nodes 4, 9, or 14, if the account could not be created-for example because not all account segments were provided, or a disabled segment was used. (In these cases, you receive an error in the document window.)

Nodes 5 and 12 suspend execution of the workflow until the previous account has completed generating the account segment values. Node 5 allows a failure option in case the charge account fails to generate a code combination identifier (CCID). In this case only, the workflow ends at node 6.

Generate Default Accounts Process Activities

The following is a description of each activity used in all of the processes and subprocesses in the PO Account Generator and the PO Requisition Account Generator, 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.

You can use the Item Type Definitions Web page to view <PACKAGE>.<PROCEDURE> names. See: Item Type Definitions Web Page, Oracle Workflow Developer's Guide.

Some function activities are not listed here, such as Start and End function activities. These are standard function activities provided in the Standard Flexfield Workflow item type. These also include the function activities Copy Values from Code Combination and Validate Code Combination. For information on how to use these function activities, see: Standard Flexfield Workflow, Oracle Applications Flexfields Guide.

Most of the function activities described here perform the same functions as described in the table in the section Using the Account Generator in Oracle Purchasing.

Accrual Account For Expense Item

This function activity gets the accrual account for the expense item.

Accrual Account From Organization

This function activity gets the accrual account for inventory and shop floor items from the organization.

Build Inventory Charge Account

This function activity gets the appropriate charge account for inventory items based on whether the item is an expense or asset item.

Expense Account

This function activity gets the charge expense account for expense items.

Get Budget Account From Item/Sub

This function activity gets the budget account for inventory items from the subinventory.

Get Charge Account

This function activity gets the charge account.

Get Item Level Budget Account

This function activity gets the budget account for inventory items from the item.

Get Org Level Budget Account

This function activity gets the budget account for inventory items from the organization.

Is Charge Account CCID Null?

This is a standard Workflow comparison activity. Here, it is used to check if the Charge Account field on the document is null. See: Comparison Activities, Oracle Workflow Developer's Guide.

Item Under Budgetary Control?

This function activity checks if encumbrance accounting is being used.

Job WIP Account

For an outside processing job, this function activity gets the charge account based on the resource cost element associated with the job.

PO Accrual Acc Flexbuilder Upgrade

In the PO Account Generator, this function activity replicates your accrual account FlexBuilder rules in the Account Generator. It calls the appropriate functions that were generated during your upgrade from Release 10.7.

PO Budget Acc Flexbuilder Upgrade

In the PO Account Generator, this function activity replicates your budget account FlexBuilder rules in the Account Generator. It calls the appropriate functions that were generated during your upgrade from Release 10.7.

PO Charge Acc Flexbuilder Upgrade

In the PO Account Generator, this function activity replicates your charge account FlexBuilder rules in the Account Generator. It calls the appropriate functions that were generated during your upgrade from Release 10.7.

PO Requisition Accrual Acc Flexbuilder Upgrade

In the PO Requisition Account Generator, this function activity replicates your accrual account FlexBuilder rules in the Account Generator. It calls the appropriate functions that were generated during your upgrade from Release 10.7.

PO Requisition Budget Acc Flexbuilder Upgrade

In the PO Requisition Account Generator, this function activity replicates your budget account FlexBuilder rules in the Account Generator. It calls the appropriate functions that were generated during your upgrade from Release 10.7.

PO Requisition Charge Acc Flexbuilder Upgrade

In the PO Requisition Account Generator, this function activity replicates your charge account FlexBuilder rules in the Account Generator. It calls the appropriate functions that were generated during your upgrade from Release 10.7.

PO Requisition Variance Acc Flexbuilder Upgrade

In the PO Requisition Account Generator, this function activity replicates your variance account FlexBuilder rules in the Account Generator. It calls the appropriate functions that were generated during your upgrade from Release 10.7.

PO Project-Related?

In the PO Account Generator, this function activity checks if the purchase order item is for a project in Oracle Projects.

Requisition Project-Related?

In the PO Requisition Account Generator, this function activity checks if the requisition item is for a project in Oracle Projects.

PO Variance Flexbuilder Upgrade

In the PO Account Generator, this function activity replicates your variance account FlexBuilder rules in the Account Generator. It calls the appropriate functions that were generated during your upgrade from Release 10.7.

Schedule Account

For an outside processing schedule, this function activity gets the charge account based on the resource cost element associated with the schedule.

Type of WIP

For shop floor items, this function activity checks if the outside processing type is Job or Schedule.

Variance Account From Organization

This function activity gets the variance account for inventory and shop floor items from the organization.

Work Item Destination Type

This function activity checks if the destination type of the item is Inventory, Shop Floor, or Expense.

Set Encoded Error Message

This function activity is not used by any process in the workflow, but is provided to aid in customizing the workflow. It can be used to create a customized error message. You must first define the message in the Oracle Applications Message Dictionary before it can be used by this function activity.

For instructions, see To use the Set Encoded Error Message function activity in the section Customizing the Account Generator for Oracle Purchasing.

Summary of the Generate Default Accrual Account Subprocess

To view the properties of this process, select the process in the navigator tree, then choose Properties from the Edit menu. This process has a result type of Flexfield Result, indicating that when the process completes, it has a result of Failure or Success. These results correspond to the lookup codes in the Flexfield Result lookup type in the Standard Flexfield Workflow item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

Node 2 checks if the destination type for the item is Inventory, Shop Floor, or Expense.

For expense items, node 8 first checks if the item is project-related. If it is, the subprocess at node 11 builds a project-related account, if you have customized that subprocess to do so.

If the item is not project-related, node 9 gets the accrual account. For inventory and shop floor items, node 3 gets the accrual account from the organization. See the table in the section Using the Account Generator in Oracle Purchasing.

Nodes 5 and 6 are standard flexfield workflow activities. See: Standard Flexfield Workflow, Oracle Applications Flexfields Guide.

Summary of the Generate Default Budget Account Subprocess

To view the properties of this process, select the process in the navigator tree, then choose Properties from the Edit menu. This process has a result type of Flexfield Result, indicating that when the process completes, it has a result of Failure or Success. These results correspond to the lookup codes in the Flexfield Result lookup type in the Standard Flexfield Workflow item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

Node 2 checks if the item is project-related. If it is, the subprocess at node 3 builds a project-related account, if you have customized that subprocess to do so.

Node 6 checks if the destination type for the item is Inventory, Expense, or Shop Floor.

For shop floor items, the subprocess checks whether the job is EAM job and builds a shop floor related account only if the job is EAM job. The workflow will stop the budget account generation if the job is not a EAM job.

For expense items, node 10 gets the budget account from the charge account.

For inventory items, the subprocess at node 8 builds the inventory budget account. See: Summary of the Build Inventory Budget Account Subprocess.

Nodes 12 and 13 are standard flexfield workflow activities. See: Standard Flexfield Workflow, Oracle Applications Flexfields Guide.

Summary of the Generate Default Charge Account Subprocess

To view the properties of this process, select the process in the navigator tree, then choose Properties from the Edit menu. This process has a result type of Flexfield Result, indicating that when the process completes, it has a result of Failure or Success. These results correspond to the lookup codes in the Flexfield Result lookup type in the Standard Flexfield Workflow item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

Node 2 checks if the destination type for the item is Shop Floor, Inventory, or Expense.

For shop floor items, node 3 builds the shop floor charge account. See: Summary of the Build Shop Floor Charge Account Subprocess. For inventory items, node 5 builds the inventory charge account. See: Summary of the Build Inventory Charge Account Subprocess. For expense items, node 9 builds the expense charge account. See: Summary of the Build Expense Charge Account Subprocess.

If node 9 successfully builds the charge account for expense items, the workflow does not validate the code combination right away. Instead, since you can enter your own charge account on the document for expense items, node 10 first checks if all segments were provided:

Nodes 6, 10, 11, and 12 are standard flexfield workflow activities. See: Standard Flexfield Workflow, Oracle Applications Flexfields Guide.

Summary of the Generate Default Variance Account Subprocess

To view the properties of this process, select the process in the navigator tree, then choose Properties from the Edit menu. This process has a result type of Flexfield Result, indicating that when the process completes, it has a result of Failure or Success. These results correspond to the lookup codes in the Flexfield Result lookup type in the Standard Flexfield Workflow item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

Node 2 checks if the destination type is Shop Floor, Inventory, or Expense.

For shop floor or inventory items, node 5 gets the variance account from the organization. For expense items, node 3 gets the charge account. See the table in the section Using the Account Generator in Oracle Purchasing.

Node 7 is a standard flexfield workflow activity. See: Standard Flexfield Workflow, Oracle Applications Flexfields Guide.

Summary of the Build Expense Charge Account Subprocess

To view the properties of this process, select the process in the navigator tree, then choose Properties from the Edit menu. This process has a result type of Flexfield Result, indicating that when the process completes, it has a result of Failure or Success. These results correspond to the lookup codes in the Flexfield Result lookup type in the Standard Flexfield Workflow item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

For expense items, this subprocess first checks at node 2 if the item is project-related. If is is, the subprocess at node 3 builds a project-related account, if you have customized that subprocess to do so.

If the expense item is not project-related, node 5 gets the charge expense account. See the table in the section Using the Account Generator in Oracle Purchasing.

Node 6 is a standard flexfield workflow activity. See: Standard Flexfield Workflow, Oracle Applications Flexfields Guide.

Summary of the Build Inventory Charge Account Subprocess

To view the properties of this process, select the process in the navigator tree, then choose Properties from the Edit menu. This process has a result type of Flexfield Result, indicating that when the process completes, it has a result of Failure or Success. These results correspond to the lookup codes in the Flexfield Result lookup type in the Standard Flexfield Workflow item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

For an inventory items, this subprocess, at node 2, gets the appropriate charge account based on whether the item is an expense or asset item. See the table in the section Using the Account Generator in Oracle Purchasing.

Node 4 is a standard flexfield workflow activity. See: Standard Flexfield Workflow, Oracle Applications Flexfields Guide.

Summary of the Build Shop Floor Charge Account Subprocess

To view the properties of this process, select the process in the navigator tree, then choose Properties from the Edit menu. This process has a result type of Flexfield Result, indicating that when the process completes, it has a result of Failure or Success. These results correspond to the lookup codes in the Flexfield Result lookup type in the Standard Flexfield Workflow item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

For shop floor items, this subprocess, at node 2, checks if the item is for an outside processing job or schedule. For a job, node 3 gets the charge account based on the resource cost element associated with the job. For a schedule, node 7 gets the charge account based on the resource cost element associated with the schedule. See the table in the section Using the Account Generator in Oracle Purchasing.

Node 5 is a standard flexfield workflow activity. See: Standard Flexfield Workflow, Oracle Applications Flexfields Guide.

Summary of the Build Inventory Budget Account Subprocess

To view the properties of this process, select the process in the navigator tree, then choose Properties from the Edit menu. This process has a result type of Flexfield Result, indicating that when the process completes, it has a result of Failure or Success. These results correspond to the lookup codes in the Flexfield Result lookup type in the Standard Flexfield Workflow item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

For inventory items, this subprocess, at node 2, gets a budget account first from the subinventory. If no account is specified there, node 4 looks for the budget account for the item. If no account is specified there, node 5 looks for the budget account for the organization. If no account is specified there, node 6 gets the charge account for the budget account. See the table in the section Using the Account Generator in Oracle Purchasing.

Summary of the Build Project Account Subprocesses

To view the properties of the Build Project Account subprocesses, select the process in the navigator tree, then choose Properties from the Edit menu. The Build Project Account subprocesses each have a result type of Flexfield Result, indicating that when the process completes, it has a result of Failure or Success. These results correspond to the lookup codes in the Flexfield Result lookup type in the Standard Flexfield Workflow item type.

These subprocess activities are not runnable, indicating that they cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

There are four Build Project Account subprocesses, one for each account being built:

The Build Project Account subprocesses are dummy processes, available for you to customize an account-building process if Oracle Projects is installed. To use this process, you provide your own rules to the process, in the form of workflow process definitions, to build the account.

Shown below, the function activity Requisition Project-Related? by default always returns a value of False. This is what is meant by the Build Project Related Account process's being a dummy process. It isn't used until you replace the function activity Requisition Project-Related? with one of your own that checks a document for a Project ID.

You can use the Standard workflow function activity Compare Number in place of PO Project-Related. You can use Compare Number to compare the Project ID on a document with a value that you define, or to check if a Project ID exists. If there is no Project ID, then Compare Number transitions to the Expense Account activity and builds the default expense account. If there is a Project ID, then Compare Number transitions to the Build Project Related Account process to build the account. See: Comparison Activities, Oracle Workflow Developer's Guide.

If you want to bill items to a project account, you must do the following:

For more information about using the Account Generator when you integrate Oracle Purchasing with Oracle Projects, read the following essay: "Using the Account Generator in Oracle Projects" in the Oracle Projects User's Guide.

Summary of the Get Charge Account for Variance Account Subprocess

To view the properties of this process, select the process in the navigator tree, then choose Properties from the Edit menu. This process has a result type of Flexfield Result, indicating that when the process completes, it has a result of Failure or Success. These results correspond to the lookup codes in the Flexfield Result lookup type in the Standard Flexfield Workflow item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

For expense items, this subprocess first checks at node 2 if the item is project-related. If it is, the subprocess at node 3 builds a project-related account, if you have customized that subprocess to do so.

If the item is not project-related, node 5 gets the charge account for building the variance account.

Node 7 is a standard flexfield workflow activity. See: Standard Flexfield Workflow, Oracle Applications Flexfields Guide.

Summary of the Get Variance Account from Organization Subprocess

To view the properties of this process, select the process in the navigator tree, then choose Properties from the Edit menu. This process has a result type of Flexfield Result, indicating that when the process completes, it has a result of Failure or Success. These results correspond to the lookup codes in the Flexfield Result lookup type in the Standard Flexfield Workflow item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

For inventory and shop floor items, node 2 gets the variance account from the organization. See the table in the section Using the Account Generator in Oracle Purchasing.

Node 3 is a standard flexfield workflow activity. See: Standard Flexfield Workflow, Oracle Applications Flexfields Guide.

Summary of the Generate Accounts Using FlexBuilder Rules Process

To view the properties of this process, select the process in the navigator tree, then choose Properties from the Edit menu. This process has a result type of Flexfield Result, indicating that when the process completes, it has a result of Failure or Success. These results correspond to the lookup codes in the Flexfield Result lookup type in the Standard Flexfield Workflow item type.

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

If you customized FlexBuilder in a previous release to generate account combinations, you can use the Generate Accounts Using FlexBuilder Rules process to replicate your FlexBuilder setup automatically, without changing any of your predefined FlexBuilder Rules, and without customizing the Account Generator. This top-level process consists of the following processes:

To build accounts, Generate Accounts Using FlexBuilder Rules process calls the appropriate functions that were generated during your upgrade from Release 10.7.

If you are upgrading from Release 10, follow the guidelines in the FlexBuilder chapter of the Oracle E-Business Suite Upgrade Preparation Manual.

Using the Workflow Monitor with the Account Generator

If you are using the Workflow Monitor to view account generation results during testing or diagnosing a problem, set the profile option Account Generator: Run in Debug Mode to Yes. This ensures that runtime data is saved. After you finish testing, always set this profile option to No, to maintain performance. Use the Purge Obsolete Workflow Runtime Data process, accessible through the System Administrator responsibility, to periodically purge the runtime data.

To monitor a document as it proceeds through a workflow, you need to provide the Workflow Monitor with an item key, which is specific both to the document you are monitoring and the process in which you're monitoring it.

For information on how to use the Workflow Monitor, see Monitoring Workflow Processes, Oracle Workflow User's Guide.

To determine the item key for the Account Generator workflows:

  1. In Purchasing, open the document you want to monitor and choose Tools > Examine from the Help menu.

    Tools > Examine is sometimes controlled by a password. If you don't have access to it, see your system administrator.

  2. Select the down-arrow box to the right of the Block field.

  3. In the list of values that appears, choose PARAMETER and choose OK.

  4. In the Field field, enter charge_acc_wf_itemkey.

    The item key appears in the Value field. Use this item key when you are prompted by the Workflow Monitor to enter the item key.

Requisition Approval Workflow

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:

For information on the purchase order approval workflow, see: Purchase Order Approval Workflow.

Customizing the PO 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 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, Oracle Workflow User's Guide.

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, Oracle Workflow Developer's Guide.

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

    the picture is described in the document text

  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.

Important: Creating a new workflow process with a new Internal Name affects the implementation of future upgrades. See: Upgrade Support.

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.

Important: If a particular Workflow object does not appear in the following sections on the lists of things you can customize, do not modify it, regardless of its access level.

Attributes

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

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:

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.

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

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, Oracle Workflow Developer's Guide. See also: Message Result, Oracle Workflow Developer's Guide and To Create a Message, Oracle Workflow Developer's Guide.

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:

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.

Note: If you change a lookup type, be sure that all activities that use the lookup type allow for the change. For example, if you change the lookup type from Yes/No to something else, the activities that use that lookup type should also change their Result Type from Yes/No to whatever new lookup type you created. See: Lookup Types.

The PO Requisition Approval Workflow Item Type

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:

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

Display Name Description Type Length/ Format/ Lookup Type
Action history of the document Action history of the document as displayed in the approval notification Document  
Application ID Unique identifier for the application (such as Purchasing) Number  
Approval List ID Unique identifier for the list of approvers that the requester sees or modifies in iProcurement Number  
Approval Path ID Unique identifier for the approval hierarchy Number  
Approver Employee ID Unique identifier for the approver Number  
Approver Display Name Approver's name as displayed in Purchasing Text  
Approver User Name User name of the approver Text  
Approve Requisition Message Message header that indicates the specific document requiring approval Document  
Authorization Status Status of the document, such as Approved or Incomplete Text 25
Authorization Status Display Document status as displayed in Purchasing Text 25
Closed Code Indicator that the document is closed Text 25
Closed Code Display Closed status as displayed in Purchasing Text 25
Concurrent Request ID Request ID for the Document Approval Manager Number  
Context ORG_ID Unique identifier for the organization Number  
Document ID Unique identifier for the document Number  
Document Manager Error Number Error number for the Document Manager Failed notification Number  
Document Subtype Document subtype, such as Purchase or Internal Text 25
Document Subtype Display Document subtype as displayed in Purchasing Text 25
Document Type Document type, such as Requisition Text 25
Document Type Display Document type as displayed in Purchasing Text 25
Emergency PO Number Purchase order number reserved in advance for a requisition created in iProcurement Text 20
Forward From Display Name Name of the forward-from person as displayed in Purchasing Text 60
Forward From ID Unique identifier for the forward-from person Number  
Forward From User Name User name for the forward-from person Text 60
Forward To Display Name Name of the forward-to person as displayed in Purchasing Text 60
Forward To ID Unique identifier for the forward-to person Number  
Forward-To ID Old Value Item attribute for internal use that keeps track of the previous forward-to person Number  
Forward To User Name User name for the forward-to person Text 60
Functional Currency Functional currency Text  
Interface Source Source of the requisition, such as ICX or POR Text 25
"Invalid Forward To" Translated Message Message used when approving the document if the forward-to user name is invalid Text  
No Approver Found Message Message header that indicates the specific document for which the approver was not found Document  
Note Note to the approver Text 240
Online Report ID For Doc Complete Check Unique identifier for the error message displayed after saving a document that is in error Number  
Online Report Text For Doc Complete Check Text of the error message displayed after saving a document that is in error Text 2000
Open From Command Command that Purchasing sends to open the document from the notification Form  
Original Authorization Status Status of the document before it was submitted for approval Text 25
PL/SQL Error Document The document that was being approved when a PL/SQL error occurred Text 2000
PL/SQL Error Location Where an internal, PL/SQL error occurred Text 2000
PL/SQL Error Message Text for the notification sent when a PL/SQL error occurs Text 2000
Preparer Display Name Name of the person who created the document, as displayed in Purchasing Text 80
Preparer ID Unique identifier for the person who created the document Number  
Preparer User Name User name for the person who created the document Text 60
Print Document Indicator of whether Print Document was selected when submitting the requisition for approval Text  
"Requires Approval" Translated Message Message text used to indicate the document requires approval Text  
Requisition Amount Display Total amount, without tax, as displayed in Purchasing Text  
Requisition Approved Message Message header that indicates the specific document requiring approval Document  
Requisition Detail Used in iProcurement to enable you to view requisition details URL  
Requisition Description Header description Text 240
Requisition line details Requisition line details displayed in the approval notification Document  
Requisition Number Requisition number Text 20
Requisition Rejected Message Message header that indicates the specific document that was rejected Document  
Responder Display Name Name of the approver as displayed in Purchasing Text  
Responder ID Unique identifier for an approver's response to a notification Number  
Responder User Name User name of the approver Text  
Response Forward-To Forward-to name as entered by the person forwarding the document Text 100
Responsibility ID Unique identifier for the requester's user responsibility Number  
Resubmit Requisition Used in iProcurement to enable you to resubmit a requisition URL  
Send PO Autocreation to Background Indicator of whether to send automatic documentation creation to online or background modes Text 1
System Administrator Error Message Document Approval Manager failed message Text 2000
Tax Amount Display Tax amount displayed in the approval notification Text 30
Total Amount Display Total document amount, with tax, displayed in the approval notification Text 30
Update Requisition Used in iProcurement to enable you to update a requisition URL  
User ID Unique identifier for the requester Number  

Summary of the Main Requisition Approval Process

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

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

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

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

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

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

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

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

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

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

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

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

Finally:

Main Requisition Approval Process Activities

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:

A requester in iProcurement adds Approvers X and Y:

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

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

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.

Note: Information templates in iProcurement are not the same as requisition templates in Purchasing. See the Oracle iProcurement Implementation Manual.

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

Summary of the Start of Approve Requisition Process

To view the properties of the Start of Approve Requisition Process, select the process in the navigator tree, then choose Properties from the Edit menu. This subprocess has a result type of PO Activity Performed, indicating that when the subprocess completes, it has a result of Activity Performed. This result corresponds to the lookup code in the PO Activity Performed lookup type in the PO Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but can be run only when called by another higher-level process.

This subprocess begins at node 1.

Node 2 removes previous notifications for this document if previous versions of the document that were sent to the workflow were incomplete or rejected. Node 3 sets startup values. Node 4 sets the requisition status to In Process.

Node 5 looks for an approval list created in iProcurement. (Here, node 5 finds the approval list and updates the Purchasing approval list tables. The activity Does Approval List Exist? in the Main Requisition Approval Process simply checks again for the approval list to determine how to branch in the Main process.)

Node 6 determines whether the requisition approval process is set up to run in Online or Background performance modes according to the profile option PO: Workflow Processing Mode, and if it is, node 7 waits for the background engine to begin. Node 8 retrieves requisition attributes (requisition information and internal Workflow attributes).

Start of Approve Requisition Process Activities

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, Oracle Workflow Developer's Guide.

Get Requisition Attributes (Node 8)

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

Summary of the Verify Requisition Subprocess

To view the properties of the Verify Requisition subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Verify Requisition subprocess has a result type of PO Document Verification, indicating that when the subprocess completes, it has a result of Failed Verification or Passed Verification. These results correspond to the lookup codes in the PO Document Verification lookup type, in the PO Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can only be run when called by another higher level process as a subprocess.

This subprocess activity makes sure the requisition is complete and the information is valid.

The subprocess begins at node 1.

Node 2 checks that the document status is compatible with an approval action (for example, its status is not closed, frozen, or on hold). Node 4 verifies that the document is complete, such as ensuring that it contains at least one line and one distribution.

If the document state does not allow an approval action at node 2 or the document is incomplete at node 4, a notification of such at node 8 or 9 respectively is sent to the requester. Then, at node 10, the requisition status is set back to what it was before it entered this subprocess, and the workflow ends at node 11. If you modify and resubmit the requisition or create a new one, the PO Requisition Approval workflow starts over again when you submit the requisition for approval.

If the document passes validation at nodes 2 and 4, node 6 records in the Action History window that the document has been submitted for approval.

If the Document Approval Manager fails at node 2 or 4, the notification activity at node 3 or 5 sends a notification of the failure to the requester. Once the Document Approval Manager is restarted successfully, the workflow continues if the requester or system administrator responds to the notification with Retry.

See: Document Status Checks. See: Document Submission Checks.

Verify Requisition Subprocess Activities

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.

Summary of the Reserve At The Start Subprocess

To view the properties of the Reserve At The Start subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Reserve At The Start subprocess has a result type of PO Activity Performed, indicating that when the subprocess completes, it has a result of Activity Performed. This result corresponds to the lookup code in the PO Activity Performed lookup type, in the PO Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can only be run when called by another higher level process as a subprocess.

The subprocess begins at node 1.

This subprocess, at node 7, tries to reserve funds at the start of the approval process for those requisitions created in iProcurement, if encumbrance is used.

First, node 2 checks if the requisition was created specifically in iProcurement. If it was, there is no need to check for an interface source of Requisition Import because iProcurement requisitions don't use Requisition Import but are saved directly to the Oracle internal tables.

Node 3 checks specifically for requisitions created in Web Requisitions releases prior to iProcurement (if you still have some Web Requisitions requisitions in your system). These requisitions still pass through Requisition Import. See: Requisition Import.

If the Document Approval Manager fails at node 7, node 10 sends a notification of the failure to the requester. Once the Document Approval Manager is restarted successfully, the workflow continues if the requester or system administrator responds to the notification with Retry.

Reserve At The Start Subprocess Activities

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.

Summary of the Verify Approval Authority Subprocess

To view the properties of the Verify Approval Authority subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Verify Approval Authority subprocess has a result type of Yes/No, indicating that when the subprocess completes, it has a result of Yes or No. This result corresponds to the lookup codes in the Yes/No lookup type, in the Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can only be run when called by another higher level process as a subprocess.

The subprocess begins at node 1.

Node 2 checks the approver's approval authority limits defined in the Approval Groups and Assign Approval Groups windows. (See: Defining Approval Groups. See: Assigning Approval Groups.)

If the person has enough authority to approve the document, the function activity Is Forward-To Provided? (which is outside this subprocess, in the overall workflow) begins. If not, then the process activity Find Approver (outside this subprocess) begins.

If the Document Approval Manager fails at node 2, node 3 sends a notification of the failure to the approver. Once the Document Approval Manager is restarted successfully, the workflow continues if the approver or system administrator responds to the notification with Retry.

Verify Approval Authority Subprocess Activities

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.

Summary of the Approval List Routing Subprocess

To view the properties of the Approval List Routing subprocess, select the process in the navigator tree, then choose Properties from the Edit menu. The Approval List Routing subprocess has a result type of PO Approval List Routing Result, indicating that when the process completes, it has a result of Document Approved, Reject, or Return. These results correspond to the lookup codes in the PO Approval List Routing Result lookup type in the PO Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only when called by another higher-level process.

This subprocess begins at node 1.

This subprocess starts when a requisition requires additional approval. Node 2 finds the first (or next) approver in the approval list. If that approver is invalid (for example, the approver left the company shortly after the requisition was submitted), node 3 rebuilds the approval list without that approver. If node 3 cannot rebuild the approval list (for example, because of a system failure or a problem with the approval hierarchy), this subprocess ends at node 4, and the workflow returns the requisition to the requester.

At node 5, this subprocess branches differently depending on the approver's response: a rejection branches to node 6, a Forward action branches to node 8, an approval branches to node 9, and an Approve And Forward action branches to node 10. Each of these nodes records the approver's response in the PO_APPROVAL_LIST_HEADERS and PO_APPROVAL_LIST_LINES tables and updates the action history accordingly.

Node 11 checks if the approval list is empty before attempting to finish the approval routing. Node 12 checks if the requisition is Pre-Approved. (If the requisition has been approved, its status is set to Pre-Approved until the Approve Requisition subprocess or Reserve Before Approve subprocess later sets its status to Approved.)

Approval List Routing Subprocess Activities

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.

Note: If the approver does not have a logon user name, this activity does not rebuild the approval list in that instance.

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.

Summary of the Reject Requisition Subprocess

To view the properties of the Reject Requisition subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Reject Requisition subprocess has a result type of PO Approval Action and Doc Verification, indicating that when the subprocess completes, it has a result of Invalid Action or Valid Action. These results correspond to the lookup codes in the PO Approval Action and Doc Verification lookup type, in the PO Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can only be run when called by another higher level process as a subprocess.

The subprocess begins at node 1.

Node 2 changes the status of the document to Rejected. If the subprocess cannot reject the document (for example, the document status has changed to closed, frozen, or on hold,) node 5 sends a notification to the approver that the document could not be rejected. (If the document is rejected, a notification outside this subprocess in the Main Requisition Approval Process, sends the rejection notification.)

If the Document Approval Manager fails at node 2, node 4 sends a notification of the failure to the approver. Once the Document Approval Manager is restarted successfully, the workflow continues if the approver or system administrator responds to the notification with Retry.

Reject Requisition Subprocess Activities

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.

Summary of the Return Requisition to Submitter Subprocess

To view the properties of the Return Requisition to Submitter subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Return Requisition to Submitter subprocess has a result type of PO Activity Performed, indicating that when the subprocess completes, it has a result of Activity Performed. This result corresponds to the lookup code in the PO Activity Performed lookup type, in the PO Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can only be run when called by another higher level process as a subprocess.

If the Approval List Routing subprocess activity (outside this subprocess activity, in the Main Requisition Approval process) doesn't find an approver, the Return Requisition to Submitter subprocess returns the requisition to the submitter

The subprocess begins at node 1. Node 2 sets the document back to its status before it entered this subprocess. Node 3 sends the requester a notification that no approver was found. Node 5 sends the last approver a notification that no approver was found; however, if node 4 finds that the requester is also the sole or last approver, the subprocess skips node 5 and ends at node 6 so that the requester does not receive two notifications.

Return Requisition to Submitter Subprocess Activities

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.

Summary of the Notify Approver Subprocess

To view the properties of the Notify Approver subprocess, select the process in the navigator tree, then choose Properties from the Edit menu. The Notify Approver subprocess has a result type of PO Document Approval Action, indicating that when the process completes, it has a result of Approve, Approve and Forward, Forward, or Reject. These results correspond to the lookup codes in the PO Document Approval Action lookup type in the PO Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only when called by another higher-level process.

The subprocess begins at node 1.

Node 2 updates the action history. The action history records that the document awaits a response from the approver. (Other Update Action History function activities, used in other subprocesses, work together with this one to update the Action History window.)

Node 3 sends a notification to the approver that the document requires approval. If you have entered a Timeout in the Properties window for node 3, node 10 sends a reminder notification to the approver. The Timeout indicates how long the workflow waits before sending the reminder, if the approver does not respond. If you have entered a Timeout number for node 10, node 17 sends another reminder.

If the approver performs an Approve And Forward or a Forward action, nodes 4, 8, 11, 15, 18, and 22 make sure the forward-to is a valid user name.

The Approval List Routing subprocess, in which this subprocess is contained, behaves differently depending on how the approver responds here-with Approve And Forward, Approve, Reject, or Forward.

Notify Approver Subprocess Activities

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.

Summary of the Response with Approve Action Subprocess

To view the properties of the Response with Approve Action subprocess, select the process in the navigator tree, then choose Properties from the Edit menu. The Response with Approve Action subprocess has a result type of None, indicating that when the process completes, it doesn't end with a particular result, such as Approved or Rejected.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can only be run when called by another higher level process as a subprocess.

The subprocess begins at node 1.

Node 2 updates the Oracle internal approval list tables PO_APPROVAL_LIST_HEADERS and PO_APPROVAL_LIST_LINES with the approver's approval. Node 3 updates the action history with an Approve action. Node 6 verifies that the approver has approval authority if the requisition has not yet been preapproved at node 4. Then, node 8 sets the requisition's status to Pre-Approved. (Until the requisition is actually approved by the Approve Requisition subprocess or the Reserve Before Approve subprocess, the requisition is still considered Pre-Approved during this subprocess.)

Response with Approve Action Subprocess Activities

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:

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.

Summary of the Response with Approve and Forward Action Subprocess

To view the properties of the Response with Approve and Forward Action subprocess, select the process in the navigator tree, then choose Properties from the Edit menu. The Response with Approve and Forward Action subprocess has a result type of None, indicating that when the process completes, it doesn't end with a particular result, such as Approved or Rejected.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can only be run when called by another higher level process as a subprocess.

This subprocess begins at node 1.

Node 2 updates the Action History with an Approve and Forward action. If node 3 finds that the requisition has already been approved (considered Pre-Approved here), then this approver's authority does not need to be verified at node 4. Node 6 updates the Oracle internal approval list tables PO_APPROVAL_LIST_HEADERS and PO_APPROVAL_LIST_LINES with the approver's approval and forward action.

If node 3 finds that this requisition has not already been Pre-Approved, the approver's approval authority is verified at node 4. If the approver does not have sufficient authority, node 6 updates the approval list tables, and the workflow (outside this subprocess) looks for the next approver with authority.

If the approver does have authority, node 5 sets the requisition status to Pre-Approved. (Until the requisition is actually approved by the subprocess Approve Requisition or the subprocess Reserve Before Approve, the requisition is still considered Pre-Approved during this subprocess.)

Note: The sequence of events in this subprocess is important. Node 6 depends on the information provided by nodes 2 and 5.

Response with Approve and Forward Action Subprocess Activities

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:

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.

Summary of the Response with Forward Action Subprocess

To view the properties of the Response with Forward Action subprocess, select the process in the navigator tree, then choose Properties from the Edit menu. The Response with Forward Action subprocess has a result type of None, indicating that when the process completes, it doesn't end with a particular result, such as Approved or Rejected.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can only be run when called by another higher level process as a subprocess.

This subprocess begins at node 1.

Node 2 updates the Oracle internal approval list tables PO_APPROVAL_LIST_HEADERS and PO_APPROVAL_LIST_LINES with the approver's forward action. Node 3 updates the Action History window with the Forward action.

Response with Forward Action Subprocess Activities

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.

Summary of the Response with Reject Action Subprocess

To view the properties of the Response with Reject Action subprocess, select the process in the navigator tree, then choose Properties from the Edit menu. The Response with Reject Action subprocess has a result type of None, indicating that when the process completes, it doesn't end with a particular result, such as Approved or Rejected.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can only be run when called by another higher level process as a subprocess.

Node 2 updates the Oracle internal approval list tables PO_APPROVAL_LIST_HEADERS and PO_APPROVAL_LIST_LINES with the approver's rejection. Node 3 updates the Action History window with a Reject action.

Response with Reject Action Subprocess Activities

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.

Summary of the Reserve Before Approve Subprocess

To view the properties of the Reserve Before Approve subprocess, select the process in the navigator tree, then choose Properties from the Edit menu. The Reserve Before Approve subprocess has a result type of PO Reserve Before Approve, indicating that when the subprocess completes, it has a result of Forward, No, or Yes. These results correspond to the lookup codes in the PO Reserve Before Approve lookup type, in the PO Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but can be run only when called by another higher-level process.

If node 2 finds that encumbrance is on and funds for the document are not yet reserved, node 4 attempts to reserve funds for the document.

If funds cannot be reserved, node 6 sends the notification Unable To Reserve Document to the approver. 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.

If the approver forwards the document, node 7 checks if the forward-to approver has a valid user name. If so, node 8 sets the Forward-To/From information for the new approver.

If the approver rejects the document, node 10 rejects the requisition. If it cannot reject the requisition (because the document failed the state check-for example, its status has changed to closed, frozen, or on hold), node 13 sends a notification to the approver that the document could not be rejected.

If the Document Approval Manager fails at node 4 or 10, the notification activity at node 5 or 11 sends a notification of the failure to the approver. Once the Document Approval Manager is restarted successfully, the workflow continues if the approver or system administrator responds to the notification with Retry.

Reserve Before Approve Subprocess Activities

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.

Summary of the Approve Requisition Subprocess

To view the properties of the Approve Requisition subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Approve Requisition subprocess has a result type of PO Approval Action and Doc Verification, indicating that when the subprocess completes, it has a result of Invalid Action or Valid Action. These results correspond to the lookup codes in the PO Approval Action and Doc Verification lookup type, in the PO Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can only be run when called by another higher level process as a subprocess.

The subprocess begins at node 1.

Node 2 checks if the document was already approved (for example, in the Reserve Before Approve subprocess). If so, this subprocess ends at node 3 and the workflow (in the Main Requisition Approval process), sends a notification to the requester that the document has been approved.

Otherwise, node 4 verifies that the document status is compatible with an approval action (for example, is not closed, frozen, or on hold), and node 6 verifies that the document is complete, such as ensuring that it contains at least one line and one distribution.

If the document does not allow an approval action at node 4 or is incomplete at node 6, the subprocess sends the appropriate notification at node 10 or 11 respectively. Then node 12 reverts the document status back to what it was before it entered this subprocess, and the workflow ends at node 13.

If the document passes the checks at nodes 4 and 6, node 8 approves the requisition, and node 14 retrieves requisition information and other internal workflow attributes, in case these have changed.

If the Document Approval Manager fails at node 4, 6, or 8, the notification activity at node 5, 7, or 9 sends a notification of the failure to the approver. Once the Document Approval Manager is restarted successfully, the workflow continues if the approver or system administrator responds to the notification with Retry.

See: Document Status Checks. See: Document Submission Checks.

Approve Requisition Subprocess Activities

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.

Summary of the Print Document Subprocess

To view the properties of the Print Document subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Print Document subprocess has a result type of PO Activity Performed, indicating that when the subprocess completes, it has a result of Activity Performed. This result corresponds to the lookup code in the PO Activity Performed lookup type, in the PO Standard item type.

The subprocess begins at node 1.

Node 2 checks if Print was selected in the Approve Document window when the requisition was first submitted for approval. If Print was selected, node 4 prints the document.

Print Document Subprocess Activities

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.

Summary of the Verify Approval Authority for Approve and Approve/Forward Action Subprocesses

To view the properties of the Verify Approval Authority for Approve Action subprocess or the Verify Approval Authority for Approve and Forward Action subprocess, select the process in the navigator tree, then choose Properties from the Edit menu. This subprocess has a result type of Yes/No, indicating that when the subprocess completes, it has a result of Yes or No. This result corresponds to the lookup code in the Yes/No lookup type in the Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but can be run only when called by another higher-level process.

The Verify Approval Authority for Approve Action subprocess is called by the Response with Approve Action subprocess to verify an approver's approval authority. The Verify Approval Authority for Approve and Forward Action subprocess is called by the Response with Approve and Forward Action subprocess to verify an approver's approval authority.

The subprocess begins at node 1.

At node 2, the subprocess checks the approver's approval authority limits defined in the Approval Groups and Assign Approval Groups windows. (See: Defining Approval Groups. See: Assigning Approval Groups.)

If the Document Approval Manager fails at node 2, node 3 sends a notification of the failure to the approver. Once the Document Approval Manager is restarted successfully, the workflow continues if the approver or system administrator responds to the notification with Retry.

Except for their names, the subprocess Verify Approval Authority for Approve Action and the subprocess Verify Approval Authority for Approve and Forward Action are identical. They are named differently because they are used by two different subprocesses.

Verify Approval Authority Subprocess Activities

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.

Purchase Order Approval Workflow

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:

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

Customizing the PO 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, Oracle Workflow User's Guide.

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, Oracle Workflow Developer's Guide.

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

    the picture is described in the document text

  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.

Important: Creating a new workflow process with a new Internal Name affects the implementation of future upgrades. See: Upgrade Support.

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.

Important: If a particular Workflow object does not appear in the following sections on the lists of things you can customize, do not modify it, regardless of its access level.

Attributes

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

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:

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:

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

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, Oracle Workflow Developer's Guide. See also: Message Result, Oracle Workflow Developer's Guide and To Create a Message, Oracle Workflow Developer's Guide.

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:

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.

Note: If you change a lookup type, you must be sure that all activities that use the lookup type allow for the change. For example, if you change the lookup type from Yes/No to something else, the activities that use that lookup type should also change their Result Type from Yes/No to whatever new lookup type you created. See: Lookup Types, Oracle Workflow Developer's Guide.

The PO Approval Item Type

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:

* 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

Important: All of the Change Order item attributes are described in the Change Order Workflow section. See: Workflow Processes for Approving Change Orders.

Display Name Description Type Length/Format/ Lookup Type
Action History of the Document Action history of the document as displayed in the approval notification Document  
Application ID Unique identifier for the application (such as Purchasing) Number  
Approval Path ID Unique identifier for the approval hierarchy Number  
Approver Employee ID Unique identifier for the approver Number  
Approver Display Name Approver's name as displayed in Purchasing Text  
Approver User Name User name of the approver Text  
Authorization Status Status of the document, such as Approved or Incomplete Text 25
Authorization Status Display Document status as displayed in Purchasing Text 25
Closed Code Indicator that the document is closed Text 25
Closed Code Display Closed status as displayed in Purchasing Text 25
Concurrent Request ID Request ID for the Document Approval Manager Number  
Context ORG_ID Unique identifier for the organization Number  
Document ID Unique identifier for the document Number  
Document Manager Error Number Error number for the Document Manager Failed notification Number  
Document Submitted by Web Supplier Indicator of whether the change to the document was made through Oracle Supply Management Portal Text  
Document Subtype Document subtype, such as Blanket Text 25
Document Subtype Display Document subtype as displayed in Purchasing Text 25
Document Type Document type, such as Purchase Order Text 25
Document Type Display Document type as displayed in Purchasing Text 25
Fax Document Indicator of whether Fax was selected when submitting the document for approval Text  
Fax Number Facsimile number entered when submitting the document for approval Text  
Forward From Display Name Name of the forward-from person as displayed in Purchasing Text 60
Forward From ID Unique identifier for the forward-from person Number  
Forward From User Name User name for the forward-from person Text 60
Forward To Display Name Name of the forward-to person as displayed in Purchasing Text 60
Forward To ID Unique identifier for the forward-to person Number  
Forward-To ID Old Value Item attribute for internal use that keeps track of the previous forward-to person Number  
Forward To User Name User name for the forward-to person Text 60
Functional Currency Functional currency Text  
Interface Source Source of the document, such as ICX or POR Text 25
Interface Source Line ID (Not currently used) Number  
"Invalid Forward To" Translated Message Message used when approving the document if the forward-to user name is invalid Text  
Line Number Translated Translation for "Line Number" Text  
Note Note to the approver Text 240
Online Report ID For Doc Complete Check Unique identifier for the error message displayed after saving a document that is in error Number  
Online Report Text For Doc Complete Check Text of the error message displayed after saving a document that is in error Text 2000
Open Document Command that Purchasing sends to open the document from the notification Form  
Original Authorization Status Status of the document before it was submitted for approval Text 25
PL/SQL Error Document The document that was being approved when a PL/SQL error occurred Text 2000
PL/SQL Error Location Where an internal, PL/SQL error occurred Text 2000
PL/SQL Error Message Text for the notification sent when a PL/SQL error occurs Text 2000
PO Amount (Not currently used) Text 30
PO Amount Display Total amount, without tax, as displayed in Purchasing Text 30
PO Approval Headers Message Message header that indicates the specific document requiring approval Document  
PO Description Header description Text 240
PO Lines Details Purchase order line details displayed in the approval notification Document  
PO Number Purchase order number Text 20
PO Type (Not currently used) Text  
Preparer Display Name Name of the person who created the document, as displayed in Purchasing Text 80
Preparer ID Unique identifier for the person who created the document Number  
Preparer User Name User name for the person who created the document Text 60
Print Document Indicator of whether Print Document was selected when submitting the document for approval Text  
Release Num Release number Number  
Release Num Dash Separator Separator symbol, such as a dash, used in the release number Text  
Release Type Release type such as Blanket or Scheduled Text 25
"Requires Approval" Translated Message Message text used to indicate the document requires approval Text  
Response Forward-To Forward-to name as entered by the person forwarding the document Text 100
Responsibility ID Unique identifier for the document preparer's user responsibility Number  
System Administrator Error Message Document Approval Manager failed message Text 2000
Tax Amount Display Tax amount displayed in the approval notification Text 30
Total Amount Display Total document amount, with tax, displayed in the approval notification Text 30
User ID Unique identifier for the document preparer Number  

Summary of the PO Approval Top Process

To view the properties of the PO Approval Top Process, select the process in the navigator tree, then choose Properties from the Edit menu. The PO Approval Top Process has a result type of None, indicating that when the process completes, it doesn't end with a particular result, such as Approved or Rejected. Instead, its subprocesses end with specific results.

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

The Details property page of the process activity indicates that the PO Approval Top Process has an error process called DEFAULT_ERROR associated with it, which gets initiated only when an error is encountered in the process. For example, if you attempt to initiate the PO Approval Top Process with a purchase order that is created by someone who is not listed in the employee approval hierarchy, the Workflow Engine would raise an error when it tries to execute the Find Approver activity. This error would initiate DEFAULT_ERROR, which is associated with the System:Error item type. Currently the process simply executes the standard Default Error Notification activity to provide information associated with the error. You can customize the process further to suit your needs. See: Default Error Process, Oracle Workflow Developer's Guide.

The PO Approval workflow begins when you submit a purchase order for approval in Purchasing, or respond to a reminder notification to submit a purchase order for approval.

The workflow begins at node 1.

Node 2 removes previous purchase order notifications for this document if previous versions of the document sent to the workflow were incomplete or rejected.

Node 3 sets startup values, node 5 sets the purchase order status to In Process, node 6 determines whether the process is set up to run in Online or Background performance modes according to the profile option PO: Workflow Processing Mode, and node 8 retrieves purchase order attributes (purchase order information and internal workflow attributes). For more detail on these startup activities, see the next section.

Node 9 checks if the document requires reapproval because the supplier made a change (for example, to the Promised or Need-By Date) through Oracle iSupplier Portal. If the supplier's change was approved through iSupplier Portal, the document is approved directly rather than submitted for change order or full reapproval.

Note: Node 9 enables you to approve any change made through iSupplier Portal. If you were to delete node 9, any change a supplier makes through iSupplier Portal would be treated like any other document change in the change order workflow. See: Workflow Processes for Approving Change Orders.

Node 10 checks if the document is new. If it is, the workflow moves from node 10 to the Main PO Approval Process at node 14 to approve the document. If the document is not new, the change order workflow begins if your Purchasing setup (in the Document Types window) archives documents on approval (the Change Order workflow cannot work without this setup). The change order workflow gathers all document changes at node 12; determines at node 13 if those changes require manual reapproval or can simply be approved automatically; attempts at node 16 to reserve funds for the document if encumbrance accounting is used; approves the changes at node 18; sends a notification at node 20 that the document was approved; and, if Print was selected in the Approve Document window, prints the document at node 21. If a facsimile number was entered in the Approve Document window, node 22 sends a facsimile of the purchase order.

PO Approval Top Process Activities

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, Oracle Workflow Developer's Guide.

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, Oracle Workflow Developer's Guide. 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.

PO AME Approval Top Process Activities

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, Oracle Workflow Developer's Guide.

Start

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

Pre-Process

This function performs the following activities:

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:

AME Approval Routing

This function performs the following activities:

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:

Rejection Process

This function performs the following activities:

Approve PO

This function performs the following activities:

Post Approval Process

This function performs the following activities:

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.

Summary of the PO Approval Process

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

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The PO Approval Process is initiated when a new purchase order is submitted for approval or when changes to a purchase order require going through the full approval process.

The workflow begins at node 1.

If the purchase order passes verification at node 2, node 4 checks if Owner Can Approve in the Document Types window is enabled for the document type. If node 5 finds that the owner has approval authority, node 6 checks if the owner has provided an additional forward-to approver. If so, node 7 approves and forwards the purchase order, and node 8 notifies the approver. Otherwise, the workflow begins to approve the document at node 9.

If the approver approves, or approves and forwards the document, node 12 checks if the resulting document status is Pre-Approved. A pre-approved document is one that has been approved by the final approver, but also forwarded to an additional approver, or one that has been authorized for approval but for which funds have not yet been reserved, if you use encumbrance accounting. In this process, even after the document is approved, it is still considered pre-approved until the subprocess at node 9 or 23 sets its status to Approved. If the document is not pre-approved, the workflow verifies the approver's current approval authority at node 5.

The Find Approver subprocess at node 13 begins if the approver forwards the document for additional approval or does not respond, or if the activities at nodes 4 or 5 find that the document owner does not have approval authority. If an approver is found at node 13, node 16 checks if the user name of the approver is valid. If so, node 17 forwards the purchase order to the approver. If the Find Approver activity is not successful, or if the approver user name is invalid, the purchase order is returned to the submitter at node 14.

Once an approver is found, the workflow branches differently depending on how the approver responds in the subprocess at node 8-with Forward, Timeout (no response), Approve, Approve And Forward, or Reject. If the approver rejects the document, a notification as such is sent to the buyer (document owner) at node 21.

Once all approvers have approved the document, node 9 attempts to reserve funds for the document before approval if encumbrance accounting is being used and funds for the document are not already reserved. Then, node 23 approves the purchase order, sends a document-approved notification to the document owner at node 25, and prints the document at node 26 if Print was selected in the Approve Document window when the purchase order was first submitted. If a facsimile number was entered in the Approve Document window, node 27 sends a facsimile of the purchase order.

PO Approval Process Activities

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.

Summary of the Verify PO Subprocess

To view the properties of the Verify PO subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Verify PO subprocess has a result type of PO Document Verification, indicating that when the subprocess completes, it has a result of Failed Verification or Passed Verification. These results correspond to the lookup codes in the PO Document Verification lookup type, in the PO Standard item type.

This subprocess activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

This subprocess activity makes sure the purchase order is complete and the information is valid.

The subprocess begins at node 1.

Node 2 checks if the document is open (for example, not finally closed).

Node 3 checks that the document status is compatible with an approval action (for example, its status is not closed, frozen, or on hold). Node 4 verifies that the document is complete, such as ensuring that it contains at least one line and one distribution.

If the document state does not allow an approval action at node 3 or the document is incomplete at node 4, a notification of such at node 8 or 9, respectively, is sent to the document owner. Then, at node 10, the purchase order status is set back to what it was before it entered this subprocess, and the workflow ends at node 11. If you modify and resubmit the purchase order or create a new one, the PO Approval workflow starts over when you submit the purchase order for approval.

If the document passes validation at nodes 3 and 4, node 12 records in the Action History window that the document has been submitted for approval. Then the activity Can Owner Approve? (outside this subprocess, in the PO Approval Top Process) begins.

If the Document Approval Manager fails at node 2, 3, or 4, the notification activity at node 5, 6, or 7 sends a notification of the failure to the document owner. Once the Document Approval Manager is restarted successfully, the workflow continues if the document owner or system administrator responds to the notification with Retry.

See: Document Status Checks. See: Document Submission Checks.

Verify PO Subprocess Activities

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.

Summary of the Reserve Before Approve Subprocess

To view the properties of the Reserve Before Approve subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Reserve Before Approve subprocess has a result type of PO Reserve Before Approve, indicating that when the subprocess completes, it has a result of Forward, No, or Yes. These results correspond to the lookup codes in the PO Reserve Before Approve lookup type, in the PO Standard item type.

This subprocess activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

If node 2 finds that encumbrance is on and funds are not yet reserved, node 4 attempts to reserve funds for the document.

If funds cannot be reserved, node 6 sends an Unable to Reserve Document notification to the approver. 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 to the notification with Retry; reject the document; or forward the document to somebody else with authority to reserve the funds.

If the approver forwards the document, node 7 checks if the forward-to approver has a valid user name. If so, node 8 sets the Forward-To/From information for the new approver.

If the approver rejects the document, node 10 rejects the purchase order. If it cannot reject the purchase order (because the document failed the state check-for example, its status has changed to closed, frozen, or on hold), node 13 sends a notification to the approver that the document could not be rejected.

If the Document Approval Manager fails at node 4 or 10, the notification activity at node 5 or 11 sends a notification of the failure to the approver. Once the Document Approval Manager is restarted successfully, the workflow continues if the approver or system administrator responds to the notification with Retry.

Reserve Before Approve Subprocess Activities

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.

Summary of the Verify Approval Authority Subprocess

To view the properties of the Verify Approval Authority subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Verify Approval Authority subprocess has a result type of Yes/No, indicating that when the subprocess completes, it has a result of Yes or No. This result corresponds to the lookup codes in the Yes/No lookup type, in the Standard item type.

This subprocess activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

At node 2, the subprocess checks the approver's approval authority limits defined in the Approval Groups and Assign Approval Groups windows. (See: Defining Approval Groups. See: Assigning Approval Groups.)

If the person has enough authority to approve the document, the function activity Is Forward-To Provided? (which is outside this subprocess, in the overall workflow) begins. If not, then the process activity Find Approver (outside this subprocess) begins.

If the Document Approval Manager fails at node 2, node 4 sends a notification of the failure to the approver. Once the Document Approval Manager is restarted successfully, the workflow continues if the approver or system administrator responds to the notification with Retry.

Verify Approval Authority Subprocess Activities

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.

Summary of the Approve PO Subprocess

To view the properties of the Approve PO subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Approve PO subprocess has a result type of PO Approval Action and Doc Verification, indicating that when the subprocess completes, it has a result of Invalid Action or Valid Action. These results correspond to the lookup codes in the PO Approval Action and Doc Verification lookup type, in the PO Standard item type.

This subprocess activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

Node 2 checks if the document was already approved (for example, in the Reserve Before Approve subprocess). If so, this subprocess ends at node 3 and the workflow (in the PO Approval Process), sends a notification to the buyer that the document has been approved.

Otherwise, node 4 verifies that the document is ready for approval. If not, node 5 sends a notification to the approver that the document failed the state check (for example, the document's status has changed to closed, frozen, or on hold). Then, node 6 reverts the purchase order to its status before it entered this subprocess, and the workflow ends at node 7. If you modify and resubmit the purchase order or create a new one, the PO Approval workflow starts over when you submit the purchase order for approval.

If the document passes the state check, node 8 verifies that the document is complete, such as ensuring that it contains at least one line and one distribution.

If the document is not complete, node 10 sends a notification of such to the approver. The approver can respond to the notification by choosing Retry (if there is a system-level issue), or reject the document. If node 13 cannot reject the document (for example, the document's status has changed to closed, frozen, or on hold), node 14 sends the Unable to Reject Document notification to the document owner.

If the document passes the state check and is complete, node 17 approves the document, and node 19 retrieves purchase order information and other internal workflow attributes, in case these have changed.

If the Document Approval Manager fails at node 4, 8, 13, or 17, the notification activity at node 9, 11, 12, or 18 sends a notification of the failure to the approver. Once the Document Approval Manager is restarted successfully, the workflow continues if the approver or system administrator responds to the notification with Retry.

See: Document Status Checks. See: Document Submission Checks.

Approve PO Subprocess Activities

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.

Summary of the Print, Fax, and Email Document Subprocesses

To view the properties of the Print Document Process or the Fax Document Process, select its process activity in the navigator tree, then choose Properties from the Edit menu. This subprocess has a result type of PO Activity Performed, indicating that when the subprocess completes, it has a result of Activity Performed. This result corresponds to the lookup code in the PO Activity Performed lookup type, in the PO Standard item type.

Print Document Process

The subprocess begins at node 1.

Node 2 checks if Print was selected in the Approve Document window when the purchase order was first submitted for approval. If Print was selected, node 4 prints the document.

Fax Document Process

The Fax Document Process looks and behaves like the Print Document Process except that node 2 checks if Fax was selected in the Approve Document window. If Fax was selected, node 4 automatically sends a facsimile of the document if a Fax Number was also entered in the Approve Document window. (If a Fax Number was not specified, the document is sent to your facsimile server once it is approved. Depending on your CommercePath setup, you can choose where or when to send the documents that are stored on your facsimile server.)

CommercePath, or any facsimile software that uses the CommercePath Fax Command Language (FCL), must be installed to use the facsimile functionality.

Email Document Process

The Email Document Process looks and behaves like the Print Document Process except that node 2 checks if Email was selected in the Approve Document window. If Email was selected, node 4 automatically sends an Email of the document if an Email Address was also entered in the Approve Document window.

Print, Fax, and Email Document Subprocess Activities

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.

Summary of the Approve and Forward PO Subprocess

To view the properties of the Approve and Forward PO subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Approve and Forward PO subprocess has a result type of PO Approval Action and Doc Verification, indicating that when the subprocess completes, it has a result of Invalid Action or Valid Action. These results correspond to the lookup code in the PO Approval Action and Doc Verification lookup type, in the PO Standard item type.

This subprocess activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

Node 2 checks that the document status is compatible with an approval action (for example, its status is not closed, frozen, or on hold). If the document status is not compatible with an approval action, node 3 sends a notification to the approver that the document failed the state check. Then, at node 4, the subprocess reverts the purchase order to its status before it entered this subprocess, and the workflow ends at node 5. If you modify and resubmit the purchase order or create a new one, the PO Approval workflow starts over when you submit the purchase order for approval.

If the document passes the state check, node 6 verifies that the document is complete, such as ensuring that it contains at least one line and one distribution.

If the document is not complete, node 7 sends a notification of such to the approver. The approver can respond to the notification by choosing Retry, or reject the document. If node 8 cannot reject the document (because the state check fails again), node 11 sends the Unable to Reject Document notification to the document owner.

If the document is complete, node 13 approves and forwards the purchase order in one step and node 14 retrieves purchase order information and other internal workflow attributes, in case these have changed. The resulting status of the purchase order is Pre-Approved until the forward-to approver approves the purchase order (outside this subprocess) and Reserve Before Approve or Approve PO (also outside this subprocess) sets the purchase order status to Approved.

If the Document Approval Manager fails at node 2, 6, 8, or 13, the notification activity at node 9, 16, 17, or 18 sends a notification of the failure to the approver. Once the Document Approval Manager is restarted successfully, the workflow continues if the approver or system administrator responds to the notification with Retry.

See: Document Status Checks. See: Document Submission Checks.

Approve and Forward PO Subprocess Activities

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.

Summary of the Notify Approver Subprocess

To view the properties of the Notify Approver subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Notify Approver subprocess has a result type of PO Document Approval Action Process, indicating that when the subprocess completes, it has a result of Approve, Approve and Forward, Forward, Reject, or Timeout. These results correspond to the lookup codes in the PO Document Approval Action Process lookup type, in the PO Standard item type.

This subprocess activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

Node 2 sends a notification to the approver that the document requires approval.

If you have entered a Timeout number in the Properties window for node 2, node 12 sends a reminder notification to the approver. The Timeout number indicates how long the workflow waits before sending the reminder if the approver does not respond. If you have entered a Timeout number for node 12, node 22 sends another reminder. If you have entered a Timeout number for node 22, the workflow ends (times out) at node 33.

Depending on whether the approver responds with Approve, Approve and Forward, Forward, or Timeout, this subprocess sets the correct forward-to and forward-from information: nodes 9, 19, and 29 set this information after an Approve action; nodes 4, 14, and 24 after an Approve and Forward action; nodes 7, 17, and 27 after a Forward action; and node 32 after the subprocess times out if a Timeout is provided.

The PO Approval process, in which this subprocess is contained, behaves differently depending on how the approver responds here-with Approve And Forward, Approve, Reject, or Forward.

Notify Approver Subprocess Activities

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.

Summary of the Find Approver Subprocess

To view the properties of the Find Approver subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Find Approver subprocess has a result type of Yes/No, indicating that when the subprocess completes, it has a result of Yes or No. These results correspond to the lookup codes in the Yes/No lookup type, in the Standard item type.

This subprocess activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

This process looks for the next approver in the approval hierarchy if any of the following is true:

The subprocess begins at node 1.

If node 2 finds no forward-to approver, node 4 gets the default approval hierarchy-either a specific approval hierarchy that the buyer provides in the Approve Document window, or the default approval hierarchy in Purchasing.

Node 5 checks the forwarding method. If the forwarding method is Direct, the workflow sends the purchase order to the first person with enough approval authority, starting at node 13. If the forwarding method is Hierarchy, each person in the hierarchy must take action until a person with enough approval authority is reached, starting at node 6.

Nodes 6 and 13 check whether you use position hierarchies. If you do, nodes 7 and 14 use your position hierarchy to find the next approver. If you do not, nodes 10 and 19 use your employee/supervisor hierarchy to find the next approver.

If the Document Approval Manager fails at node 16 or 21, the notification activity at node 17 or 22 sends a notification of the failure to the approver. Once the Document Approval Manager is restarted successfully, the workflow continues if the approver or system administrator responds to the notification with Retry.

Find Approver Subprocess Activities

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.

Summary of the Forward PO Subprocess

To view the properties of the Forward PO subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Forward PO subprocess has a result type of PO Approval Action and Doc Verification, indicating that when the subprocess completes, it has a result of Invalid Action or Valid Action. These results correspond to the lookup codes in the PO Approval Action and Doc Verification lookup type, in the PO Standard item type.

This subprocess activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

If the Find Approver subprocess activity (outside this subprocess, in the overall workflow) finds an approver, this subprocess forwards the purchase order to the next approver.

Node 2 checks if the purchase order is pre-approved (it has been approved by the final approver, but also forwarded to an additional approver; or it has been authorized for approval but funds have not yet been reserved for it, if you use encumbrance accounting). If it has not been pre-approved, node 4 forwards the purchase order with a status of In Process. If it is pre-approved, node 8 forwards the purchase order with a status of Pre-Approved. 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.

After the document is forwarded, nodes 6 and 10 retrieve purchase order information and other internal workflow attributes, in case these have changed.

If the Document Approval Manager fails at node 4 or 8, the notification activity at node 5 or 9 sends a notification of the failure to the person who forwarded the document. Once the Document Approval Manager is restarted successfully, the workflow continues if the approver or system administrator responds to the notification with Retry.

Forward PO Subprocess Activities

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.

Summary of the Return PO to Submitter Subprocess

To view the properties of the Return PO to Submitter subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Return PO to Submitter subprocess has a result type of PO Activity Performed, indicating that when the subprocess completes, it has a result of Activity Performed. This result corresponds to the lookup code in the PO Activity Performed lookup type, in the PO Standard item type.

This subprocess activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

If the Find Approver subprocess activity (outside this subprocess activity, in the PO Approval Process) does not find an approver, the Return PO to Submitter subprocess returns the purchase order to the buyer.

The subprocess begins at node 1. Node 2 sets the document back to its status before it entered this subprocess. Node 3 sends the buyer a notification that no approver was found. Node 5 sends the last approver a notification that no approver was found; however, if node 4 finds that the buyer is also the sole or last approver, the subprocess skips node 5 and ends at node 6 so that the buyer does not receive two notifications.

Return PO to Submitter Subprocess Activities

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.

Summary of the Reject PO Subprocess

To view the properties of the Reject PO subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Reject PO subprocess has a result type of PO Approval Action and Doc Verification, indicating that when the subprocess completes, it has a result of Invalid Action or Valid Action. These results correspond to the lookup codes in the PO Approval Action and Doc Verification lookup type, in the PO Standard item type.

This subprocess activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

At node 2, this subprocess records the approver's rejection of the purchase order in the Action History window and changes the status of the document to Rejected. If the subprocess cannot reject the document (for example, the document's status has changed to closed, frozen, or on hold), node 5 sends a notification to the approver that the document could not be rejected. (If the document is rejected, a notification outside this subprocess in the PO Approval process, sends the rejection notification.)

If the Document Approval Manager fails at node 2, node 4 sends a notification of the failure to the approver. Once the Document Approval Manager is restarted successfully, the workflow continues if the approver or system administrator responds to the notification with Retry.

Reject PO Subprocess Activities

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.

Change Order Process Activities

See: Workflow Processes for Approving Change Orders.

Workflow Processes for Approving Change Orders

Whenever you make a change to a document that causes its status to change to Requires Reapproval, that document is routed through the change order workflow. The Change Order workflow uses the same reapproval rules already defined in Purchasing. See: Document Reapproval Rules.

With the change order workflow, Purchasing lets you define what changes to purchase orders or releases-for example, to amounts, suppliers, or dates-require manual reapproval and which are automatically reapproved. If you modify the change order workflow as described in the next section, you can allow certain changes to bypass full (manual) reapproval. All reapproved documents, either fully or automatically reapproved, result in the document revision number's being incremented.

All of the workflow processes and functions relating to change orders can be found within the PO Approval workflow.

The change order workflow begins when all of the following is true:

Related Topics

Purchase Order Approval Workflow

Customizing the Change Order 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 use the Workflow Monitor to follow where certain documents are in a workflow process. See: Overview of Workflow Monitoring, Oracle Workflow User's Guide.

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, Oracle Workflow Developer's Guide.

    The change order workflow is not actually an item type, like the other Purchasing workflows, but is a group of processes contained in the purchase order approval workflow. Therefore, to display the change order workflow, open the purchase order approval workflow. The Display name of the purchase order approval workflow is PO Approval. The name of its Workflow definition file is poxwfpoa.wft.

    the picture is described in the document text

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

  3. Expand the Processes branch, then double-click the PO Approval Top Process activity.

    You can see the change order processes within the PO Approval Top Process diagram.

Creating a New Custom Process

For the PO Approval workflow, which contains the change order workflow processes, you can either modify the default 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. See: Customizing the PO Approval Workflow.

Important: Creating a new workflow process with a new Internal Name affects the implementation of future upgrades. See: Upgrade Support.

Required Modifications

There are no required modifications you need to make to the change order workflow itself.

However, for the change order workflow to work, you must select Archive on Approve in the Document Types window, if you haven't already done this when you set up Purchasing. The Archive on Approve option copies the purchase order information into the archive tables in Purchasing every time you approve or reapprove a purchase order. The change order workflow uses this archive information to compare a document before and after you make a change.

Supported and Unsupported Customizations

You can modify percentage tolerances used by the change order workflow to determine what percentage increase to a unit price, quantity, or document total requires reapproval. The change order workflow represents these percentage tolerances as item attributes that you can change, using the Workflow Builder. For example, you can change the attribute Change Order Line Unit Price Tolerance from a value of 0 to a value of 20. This means that the document will be reapproved automatically by the change order workflow, without going through the full reapproval process, if the unit price is increased or decreased by less than 20 percent.

You can modify the percentage tolerances for these attributes:

For a complete discussion of what other change order workflow activities you can and definitely cannot modify, see: Purchase Order Approval Workflow.

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

To modify percentage tolerances:

  1. In the Workflow Navigator, select one of the modifiable Change Order tolerance item attributes listed above.

  2. Select the item attribute and open its Properties window.

  3. Change the Default value from 0 to your own tolerance value.

    For example, if you can change the attribute Change Order Line Unit Price Tolerance from a value of 0 to a value of 20, the document will be reapproved automatically by the change order workflow, without going through the full reapproval process, if the unit price is increased or decreased by less than 20 percent.

The Change Order Workflow Item Attributes

The change order workflow processes are associated with an item type called PO Approval. The change order process activities in the PO Approval item type are as follows:

These processes have many attributes associated with them. 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 change order processes.

The change order workflow item attributes are associated with the PO Approval item type.

Important: If one item attribute for one of the document lines does not pass the tolerance check, the entire document needs to go through full reapproval.

Change Order Workflow: Modifiable Item Type Attributes

Modifiable Item Display Name Description Type Length/Format/ Lookup Type
Change Order Distribution Quantity Ordered Tolerance If the change in the distribution Quantity ordered is less than this percentage, the document is reapproved automatically Number  
Change Order Header Amount Limit Tolerance If the change to the Amount Limit is less than this percentage, the document is reapproved automatically Number  
Change Order Header Blanket Total Tolerance If the change to the blanket Total is less than this percentage, the document is reapproved automatically Number  
Change Order Header Purchase Order Total Tolerance If the change to the purchase order Total is less than this percentage, the document is reapproved automatically Number  
Change Order Line Agreed Amount Tolerance If the change in Amount Agreed is less than this percentage, the document is reapproved automatically Number  
Change Order Line Price Limit Tolerance If the change in Price Limit is less than this percentage, the document is reapproved automatically Number  
Change Order Line Quantity Committed Tolerance If the change in Quantity Agreed is less than this percentage, the document is reapproved automatically Number  
Change Order Line Quantity Tolerance If the change in Quantity ordered is less than this percentage, the document is reapproved automatically Number  
Change Order Line Unit Price Tolerance If the change in unit Price is less than this percentage, the document is reapproved automatically Number  
Change Order Shipment Price Override Tolerance If the change in price override is less than this percentage, the document is reapproved automatically Number  
Change Order Shipment Quantity Tolerance If the change in the shipment Quantity ordered is less than this percentage, the document is reapproved automatically Number  

Change Order Workflow: Header Item Type Attributes

Header Display Name Description Type Length/Format/ Lookup Type
Change Order Document Type The type of the document, such as Standard or Blanket Purchase Agreement Text  
Change Order Header Acceptance Due Date Modified Indicator of whether the Acceptance Required By date (in the Terms and Conditions window) has changed Text 1
Change Order Header Acceptance Required Modified Indicator of whether the Acceptance Required option (in the Terms and Conditions window) has changed Text 1
Change Order Header Agent Modified Indicator of whether the buyer has changed Text 1
Change Order Header Amount Limit Change Percentage by which the Amount Limit (in the Terms and Conditions window) has changed Number  
Change Order Header Amount Limit Modified Indicator of whether the Amount Limit (in the Terms and Conditions window) has changed Text 1
Change Order Header Bill To Modified Indicator of whether the Bill-To location has changed Text 1
Change Order Header Blanket Total Change Percentage by which the document Total for a blanket purchase agreement has changed Number  
Change Order Header Blanket Total Modified Indicator of whether the document Total for a blanket purchase agreement has changed Text 1
Change Order Header Cancel Flag Modified Indicator of whether the document's Canceled status has changed Text 1
Change Order Header Confirming Order Modified Indicator of whether the Confirming Order option (in the Terms and Conditions window) has changed Text 1
Change Order Header End Date Modified Indicator of whether the Effective end date (in the Terms and Conditions window) has changed Text 1
Change Order Header FOB Modified Indicator of whether the free-on-board point (in the Terms and Conditions window) has changed Text 1
Change Order Header Freight Modified Indicator of whether the Freight (in the Terms and Conditions window) has changed Text 1
Change Order Header Note to Supplier Modified Indicator of whether the Supplier Note (in the Terms and Conditions window) has changed Text 1
Change Order Header PO Accepted Indicator of whether the purchase order's acceptance status (in the Acceptances window) has changed Text 1
Change Order Header PO Acknowledged Indicator of whether the purchase order has been acknowledged through the Acceptances window Text 1
Change Order Header PO Total Change Percentage by which the purchase order Total has changed Number  
Change Order Header Ship To Modified Indicator of whether the document's Ship-To information has changed Text 1
Change Order Header Ship Via Modified Indicator of whether the Ship Via information has changed Text 1
Change Order Header Start Date Modified Indicator of whether the Effective start date (in the Terms and Conditions window) has changed Text 1
Change Order Header Supplier Contact Modified Indicator of whether the Supplier Contact has changed Text 1
Change Order Header Supplier Site Modified Indicator of whether the Supplier Site has changed Text 1
Change Order Header Terms Modified Indicator of whether the Payment term (in the Terms and Conditions window) has changed Text 1

Change Order Workflow: Release Item Type Attributes

Release Display Name Description Type Length/Format/ Lookup Type
Change Order Release Acceptance Due Date Modified Indicator of whether the Acceptance Required Due By date has changed on a release Text 1
Change Order Release Acceptance Required Modified Indicator of whether the Acceptance Required option has changed on a release Text 1
Change Order Release Agent Modified Indicator of whether the buyer on the release has changed Text 1
Change Order Release Date Modified Indicator of whether the release creation date has changed Text 1
Change Order Release Number Modified Indicator of whether the release document number has changed Text 1
Change Order Release Total Change Percentage by which the release Total has changed Number  

Change Order Workflow: Line Item Type Attributes

Line Display Name Description Type Length/Format/ Lookup Type
Change Order Lines Agreed Amount Change Percentage by which the Amount Agreed has changed for an agreement line Number  
Change Order Lines Agreed Quantity Change Percentage by which the Quantity Agreed has changed on an agreement line Number  
Change Order Lines Cancel Flag Modified Indicator of whether a line's Canceled status has changed Text 1
Change Order Lines Category Modified Indicator of whether the item Category has changed Text 1
Change Order Lines Closed Code Modified Indicator of whether a line's Closed status has changed Text 1
Change Order Lines Committed Amount Modified Indicator of whether the Amount Agreed on the agreement line has changed Text 1
Change Order Lines Contract Number Modified Indicator of whether a line's Contract number (in the Reference Documents tabbed region) has changed Text 1
Change Order Lines From Header Modified Indicator of whether the unique identifier for the quotation header has changed Text 1
Change Order Lines From Line Modified Indicator of whether the unique identifier for the quotation line has changed Text 1
Change Order Lines Hazard Class Modified Indicator of whether a line's Hazard Class (in the More tabbed region) has changed Text 1
Change Order Lines Item Description Modified Indicator of whether a line's item Description has changed Text 1
Change Order Lines Item Modified Indicator of whether a line's Item has changed Text 1
Change Order Lines Item Revision Modified Indicator of whether a line's item revision (Rev) has changed Text 1
Change Order Lines Line Num Modified Indicator of whether a line number (Num) has changed Text 1
Change Order Lines Note to Supplier Modified Indicator of whether a line's Note to the Supplier (in the More tabbed region) has changed Text 1
Change Order Lines Price Limit Change Percentage by which the Price Limit (in the Price Reference tabbed region) has changed Number  
Change Order Lines Price Type Modified Indicator of whether a line's Price Type (in the Price Reference tabbed region) has changed Text 1
Change Order Lines Quantity Change Percentage by which a line's Quantity ordered has changed Number  
Change Order Lines Quantity Committed Modified Indicator of whether the Quantity Agreed on the agreement line has changed Text 1
Change Order Lines Quantity Modified Indicator of whether a line's Quantity ordered has changed Text 1
Change Order Lines Supplier Product Number Modified Indicator of whether a line's Supplier Item number has changed Text 1
Change Order Lines Unit of Measure Modified Indicator of whether a line's UOM has changed Text 1
Change Order Lines Unit Price Change Percentage by which a line's unit Price has changed Number  
Change Order Lines Unit Price Modified Indicator of whether a line's unit Price has changed Text 1
Change Order Lines UN Number Modified Indicator of whether a line's UN Number (in the More tabbed region) has changed Text 1

Change Order Workflow: Shipment Item Type Attributes

Shipment Display Name Description Type Length/ Format/ Lookup Type
Change Order Shipments Cancel Flag Modified Indicator of whether the shipment's Canceled status has changed Text 1
Change Order Shipments Closed Code Modified Indicator of whether the shipment's Closed status has changed Text 1
Change Order Shipments Last Accept Date Modified Indicator of whether the latest acceptable receipt date for the shipment (in the Receiving Controls window) has changed Text 1
Change Order Shipments Need By Date Modified Indicator of whether the shipment's Need By date has changed Text 1
Change Order Shipments Price Discount Modified Indicator of whether the price break has changed Text 1
Change Order Shipments Price Override Change Percentage by which the shipment's price override has changed Number  
Change Order Shipments Price Override Modified Indicator of whether the shipment's price override (in the Price Reference tabbed region) has changed Text 1
Change Order Shipments Promised Date Modified Indicator of whether the shipment's Promised Date has changed Text 1
Change Order Shipments Quantity Change Percentage by which the shipment's Quantity ordered has changed Number  
Change Order Shipments Quantity Modified Indicator of whether the shipment's Quantity ordered has changed Text 1
Change Order Shipments Shipment Number Modified Indicator of whether the shipment line number (Num) has changed Text 1
Change Order Shipments Ship To Location Modified Indicator of whether the shipment's Ship-To location has changed Text 1
Change Order Shipments Ship To Organization Modified Indicator of whether the shipment line's ship-to organization (Org) has changed Text 1
Change Order Shipments Taxable Flag Modified Indicator of whether the shipment line's Taxable status has changed Text 1

Change Order Workflow: Distribution Item Type Attributes

Distribution Display Name Description Type Length/ Format/ Lookup Type
Change Order Distribution Quantity Ordered Change Percentage by which the distribution Quantity ordered has changed Number  
Change Order Distribution Rate Change Percentage by which the currency conversion Rate on the distribution has changed Number  
Change Order Distribution Rate Tolerance Maximum percentage change allowed to the currency conversion rate Number  
Change Order Distribution Subinventory Modified Indicator of whether the distribution Subinventory has changed Text  
Change Order Distributions Charge Account Modified Indicator of whether the distributions Charge Account has changed Text 1
Change Order Distributions Deliver To Person Modified Indicator of whether the distributions Deliver-To person has changed Text 1
Change Order Distributions GL Encumbered Date Modified Indicator of whether the distributions GL Date (date the distribution was encumbered) has changed Text 1
Change Order Distributions Quantity Ordered Modified Indicator of whether the distribution Quantity ordered has changed Text 1
Change Order Distributions Rate Date Modified Indicator of whether the currency conversion Rate Date on the distribution has changed Text 1
Change Order Distributions Rate Modified Indicator of whether the currency conversion Rate on the distribution has changed Text 1
Change Order Distributions Rate Type Modified Indicator of whether the currency conversion Rate Type on the distribution has changed Text 1

Summary of the Get All Document Changes Subprocess

To view the properties of the Get All Document Changes subprocess, select the process in the navigator tree, then choose Properties from the Edit menu. The Get All Document Changes subprocess has a result type of PO Activity Performed, indicating that when the process completes, it has a result of Activity Performed. This result corresponds to the lookup code in the PO Activity Performed lookup type in the PO Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The Get All Document Changes subprocess is initiated when the PO Approval workflow determines that the document is a changed, not a new, document, and Archive on Approval is chosen for the document type in the Document Types window. (The change order workflow is not initiated unless you have chosen Archive on Approval. See: Required Modifications in Customizing the Change Order Workflow.)

The subprocess begins at node 1.

Node 2 determines the document type so that the correct subprocess (nodes 3 through 8) for gathering the document changes begins. For example, if node 2 finds that the document is a contract purchase order, node 3 finds all the changes in the contract purchase order. Nodes 3 through 8 find the changes by comparing the document with its previous archived revision.

Get All Document Changes Subprocess Activities

The following is a description of each activity in the Get All Document Changes subrocess 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 change order processes, view the Properties page for each function activity. For example, the function activity Determine Document Type uses the <PACKAGE>.<PROCEDURE> name PO_CHORD_WF0.CHORD_DOC_TYPE.

You can use the Item Type Definitions Web page to view <PACKAGE>.<PROCEDURE> names. See: Item Type Definitions Web Page, Oracle Workflow Developer's Guide.

Start (Node 1)

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

Determine Document Type (Node 2)

This function activity looks for the changed document's document type.

Get All Contract PO Changes (Node 3)

See: Get All Contract PO Changes.

Get All Blanket PO Changes (Node 4)

See: Get All Blanket PO Changes.

Get All Planned PO Changes (Node 5)

See: Get All Planned PO Changes.

Get All Standard PO Changes (Node 6)

See: Get All Standard PO Changes.

Get All Release Changes (Nodes 7 and 8)

Node 7 gathers all release changes for a blanket release, and node 8 gathers all release changes for a scheduled release. See: Get All Release Changes.

End (Node 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 Get All Document Changes 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.

Summary of the Get All Blanket PO Changes Subprocess

To view the properties of the Get All Blanket PO Changes subprocess, select the process in the navigator tree, then choose Properties from the Edit menu. The Get All Blanket PO Changes subprocess has a result type of PO Activity Performed, indicating that when the process completes, it has a result of Activity Performed. This result corresponds to the lookup code in the PO Activity Performed lookup type in the PO Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

Nodes 2 and 3 compare the document with its previous archived revision to find all header and line changes for a blanket purchase order. The activities update the appropriate item attributes with the changed values.

Get All Blanket PO Changes Subprocess Activities

The following is a description of each activity in the Get All Blanket PO Changes 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.

Get Header Changes (Node 2)

This function activity gathers all of the changes that occurred in the blanket purchase agreement header and updates the appropriate item attributes with the changes.

Get Lines Changes (Node 3)

This function activity gathers all of the changes that occurred in the blanket purchase agreement lines and updates the appropriate item attributes with the changes.

End (Node 4)

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 Get All Blanket PO Changes 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.

Summary of the Get All Contract PO Changes Subprocess

To view the properties of the Get All Contract PO Changes subprocess, select the process in the navigator tree, then choose Properties from the Edit menu. The Get All Contract PO Changes subprocess has a result type of PO Activity Performed, indicating that when the process completes, it has a result of Activity Performed. This result corresponds to the lookup code in the PO Activity Performed lookup type in the PO Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

Node 2 compares the document with its previous archived revision to find all the changes for a contract purchase order. (Contract purchase orders contain only header information.)

Get All Contract PO Changes Subprocess Activities

The following is a description of each activity in the Get All Contract PO Changes 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.

Get Header Changes (Node 2)

This function activity gathers all of the changes that occurred in the contract purchase order header and updates the appropriate item attributes with the changes.

End (Node 3)

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 Get All Contract PO Changes 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.

Summary of the Get All Planned PO Changes Subprocess

To view the properties of the Get All Planned PO Changes subprocess, select the process in the navigator tree, then choose Properties from the Edit menu. The Get All Planned PO Changes subprocess has a result type of PO Activity Performed, indicating that when the process completes, it has a result of Activity Performed. This result corresponds to the lookup code in the PO Activity Performed lookup type in the PO Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

Nodes 2, 3, 4, and 5 compare the document with its previous archived revision to find all header, line, shipment, and distribution changes for a planned purchase order.

Get All Planned PO Changes Subprocess Activities

The following is a description of each activity in the Get All Planned PO Changes 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.

Get Header Changes (Node 2)

This function activity gathers all of the changes that occurred in the planned purchase order header and updates the appropriate item attributes with the changes.

Get Lines Changes (Node 3)

This function activity gathers all of the changes that occurred in the planned purchase order lines and updates the appropriate item attributes with the changes.

Get Shipments Changes (Node 4)

This function activity gathers all of the changes that occurred in the planned purchase order shipments and updates the appropriate item attributes with the changes.

Get Distribution Changes (Node 5)

This function activity gathers all of the changes that occurred in the planned purchase order distributions and updates the appropriate item attributes with the changes.

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 Get All Planned PO Changes 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.

Summary of the Get All Release Changes Subprocess

To view the properties of the Get All Release Changes subprocess, select the process in the navigator tree, then choose Properties from the Edit menu. The Get All Release Changes subprocess has a result type of PO Activity Performed, indicating that when the process completes, it has a result of Activity Performed. This result corresponds to the lookup code in the PO Activity Performed lookup type in the PO Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

Nodes 2, 3, and 4 compare the document with its previous archived revision to find all release header, shipment, and distribution changes for a blanket or scheduled release.

Get All Release Changes Subprocess Activities

The following is a description of each activity in the Get All Release Changes 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.

Get Release Changes (Node 2)

This function activity gathers all of the changes that occurred in the release header and updates the appropriate item attributes with the changes.

Get Shipments Changes (Node 3)

This function activity gathers all of the changes that occurred in the release shipments and updates the appropriate item attributes with the changes.

Get Distribution Changes (Node 4)

This function activity gathers all of the changes that occurred in the release distributions and updates the appropriate item attributes with the changes.

End (Node 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 Get All Release Changes 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.

Summary of the Get All Standard PO Changes Subprocess

To view the properties of the Get All Standard PO Changes subprocess, select the process in the navigator tree, then choose Properties from the Edit menu. The Get All Standard PO Changes subprocess has a result type of PO Activity Performed, indicating that when the process completes, it has a result of Activity Performed. This result corresponds to the lookup code in the PO Activity Performed lookup type in the PO Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

Nodes 2, 3, 4, and 5 compare the document with its previous archived revision to find all header, line, shipment, and distribution changes for a standard purchase order.

Get All Standard PO Changes Subprocess Activities

The following is a description of each activity in the Get All Standard PO Changes 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.

Get Header Changes (Node 2)

This function activity gathers all of the changes that occurred in the standard purchase order header and updates the appropriate item attributes with the changes.

Get Lines Changes (Node 3)

This function activity gathers all of the changes that occurred in the standard purchase order lines and updates the appropriate item attributes with the changes.

Get Shipments Changes (Node 4)

This function activity gathers all of the changes that occurred in the standard purchase order shipments and updates the appropriate item attributes with the changes.

Get Distribution Changes (Node 5)

This function activity gathers all of the changes that occurred in the standard purchase order distributions and updates the appropriate item attributes with the changes.

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 Get All Standard PO Changes 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.

Summary of the Do Document Changes Require Reapproval? Subprocess

To view the properties of the Do Document Changes Require Reapproval? subprocess, select the process in the navigator tree, then choose Properties from the Edit menu. The Do Document Changes Require Reapproval? subprocess has a result type of Yes/No, indicating that when the process completes, it has a result of Yes or No. This result corresponds to the lookup code in the Yes/No lookup type in the Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

Node 2 determines the document type. Nodes 3 through 8 determine whether the changed components on the document require the document to go through the full approval process (find the next approver in the approval hierarchy, send notifications, and so on) or to be approved immediately. If the changed components require approval, the PO Approval Process (outside this subprocess, in the overall purchase order approval workflow) begins.

For example, if node 2 finds that the document is a blanket purchase agreement, node 3 checks if the changes to the agreement require full reapproval. Node 4 does the same for contract purchase orders, and so on.

The subprocess Do Document Changes Require Reapproval? uses reapproval rules that are already defined in Purchasing-or the Change Order Tolerance attributes, if you modified them-to determine if the document is required to go through the full approval process.

Do Document Changes Require Reapproval? Subprocess Activities

The following is a description of each activity in the Do Document Changes Require Reapproval? 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.

Determine Document Type (Node 2)

This function activity looks for the changed document's document type.

Does the Blanket PO Require Reapproval? (Node 3)

This function activity returns the value of Yes when the blanket purchase agreement is required to go through the approval process and No if it is not. This subprocess uses reapproval rules that are already defined in Purchasing-or the Change Order Tolerance attributes, if you modified them-to determine if the document is required to go through the full PO Approval Process, or if it can be approved immediately.

Does the Contract PO Require Reapproval? (Node 4)

This function activity does the same as the previous activity, for contract purchase orders.

Does the Planned PO Require Reapproval? (Node 5)

This function activity does the same as the previous activity, for planned purchase orders.

Does the Scheduled Release Require Reapproval? (Node 8)

This function activity does the same as the previous activity, for scheduled releases.

Does the Standard PO Require Reapproval? (Node 6)

This function activity does the same as the previous activity, for standard purchase orders.

Does the Blanket Release Require Reapproval? (Node 7)

This function activity does the same as the previous activity, for blanket releases.

End (Nodes 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19 and 20)

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 Do Document Changes Require Reapproval? 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.

Summary of the Change Order Reserve Before Approve Subprocess

To view the properties of the Change Order Reserve Before Approve subprocess, select the process in the navigator tree, then choose Properties from the Edit menu. The Change Order Reserve Before Approve subprocess has a result type of Yes/No, indicating that when the process completes, it has a result of Yes or No. This result corresponds to the lookup code in the Yes/No lookup type in the Standard item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

The subprocess begins at node 1.

If node 2 finds that encumbrance is on and funds are not yet reserved, node 4 attempts to reserve funds for the document.

If funds cannot be reserved, node 6 sends an Unable to Reserve Document notification to the approver. 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 to the notification with Retry; reject the document; or forward the document to somebody else with approval authority to reserve the funds.

If the approver forwards the document, node 7 checks if the forward-to approver has a valid user name. If so, node 8 sets the Forward-To/From information for the new approver.

If the approver rejects the document, node 9 rejects the purchase order. If it cannot reject the purchase order (because the document failed the state check-for example, its status has changed to closed, frozen, or on hold), node 11 sends a notification to the approver that the document could not be rejected.

If the Document Approval Manager fails at node 4 or 9, the notification activity at node 5 or 10 sends a notification of the failure to the approver, and the workflow continues if the approver or system administrator responds to the notification with Retry.

Change Order Reserve Before Approve Subprocess Activities

The following is a description of each activity in the Change Order 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 determines whether you are using encumbrance accounting, and whether the document is reserved.

Reserve Document (Node 4)

This function activity tries to reserve funds for the document.

Document Manager Failed (Nodes 5 and 10)

Any time the document manager fails, the approver receives a 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 document owner that Purchasing failed to reserve funds for the document, and provides instructions for resolving the failure.

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)

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

Reject the PO (Node 9)

This function activity sets a rejected purchase order 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 11)

This activity sends a notification to the document owner that Purchasing was unable to properly reject the document.

End (Nodes 3 and 12)

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 Change Order Reserve Before Approve 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.

Summary of the Approve PO (Change Order) Subprocess

To view the properties of the Approve PO (Change Order) subprocess, select its process activity in the navigator tree, then choose Properties from the Edit menu. The Approve PO (Change Order) subprocess has a result type of PO Approval Action and Doc Verification, indicating that when the subprocess completes, it has a result of Invalid Action or Valid Action. These results correspond to the lookup codes in the PO Approval Action and Doc Verification lookup type, in the PO Standard item type.

This subprocess activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

If the change to the purchase order requires full reapproval, this process approves the purchase order. If while approving the purchase order, validation fails, this process sends a notification to the buyer that the document failed state or correctness checks.

The subprocess begins at node 1.

Node 2 checks if the document was already approved (for example, in the Reserve Before Approve subprocess). If so, this subprocess ends at node 3 and the workflow (in the PO Approval Process), sends a notification to the buyer that the document has been approved.

Otherwise, node 4 verifies that the document is ready for approval. If not, node 5 sends a notification to the approver that the document failed the state check (for example, the document's status has changed to closed, frozen, or on hold). Then, node 6 reverts the purchase order to its status before it entered this subprocess, and the workflow ends at node 7. If you modify and resubmit the purchase order or create a new one, the PO Approval workflow starts over when you submit the purchase order for approval.

If the document passes the state check, node 8 verifies that the document is complete, such as ensuring that it contains at least one line and one distribution. If the document is not complete, node 10 sends a notification of such to the approver. The approver can respond to the notification by choosing Retry (useful if there is a system-level issue), or reject the document. If node 13 cannot reject the document (for example, the document's status has changed to closed, frozen, or on hold), node 14 sends the Unable to Reject Document notification to the document owner.

If the document passes the state check and is complete, node 17 approves the document, and node 19 retrieves purchase order information and other internal Workflow attributes, in case these have changed.

If the Document Approval Manager fails at node 4, 8, 13, or 17, the notification activity at node 9, 11, 12, or 18 sends a notification of the failure to the approver. Once the Document Approval Manager is restarted successfully, the workflow continues if the approver or system administrator responds to the notification with Retry.

See: Document Status Checks. See: Document Submission Checks.

Approve PO (Change Order) Subprocess Activities

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

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 (Change Order) 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.

Summary of the Print and Fax Document Processes (Change Order)

To view the properties of the Print Document Process (Change Order) or the Fax Document Process (Change Order), select its process activity in the navigator tree, then choose Properties from the Edit menu. This subprocess has a result type of PO Activity Performed, indicating that when the subprocess completes, it has a result of Activity Performed. This result corresponds to the lookup code in the PO Activity Performed lookup type, in the PO Standard item type.

Print Document Process (Change Order)

The subprocess begins at node 1.

Node 2 checks if Print was selected in the Approve Document window when the purchase order was first submitted for approval. If Print was selected, node 4 prints the document.

Fax Document Process (Change Order)

The Fax Document Process (Change Order) looks and behaves like the Print Document Process (Change Order) except that node 2 checks if Fax was selected in the Approve Document window. If Fax was selected, node 4 automatically sends a facsimile of the document if a Fax Number was also entered in the Approve Document window. (If a Fax Number was not specified, the document is sent to your facsimile server once it is approved. Depending on your CommercePath setup, you can choose where or when to send the documents that are stored on your facsimile server.)

CommercePath, or any facsimile software that uses the CommercePath Fax Command Language (FCL), must be installed to use the facsimile functionality.

Print and Fax Document Process (Change Order) Activities

The following is a description of each activity in the Print Document (Change Order) subprocess and the Fax Document (Change Order) 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 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 (Change Order) 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.

Workflow for Creating Purchase Orders and Releases

Purchasing integrates with Oracle Workflow technology to create standard purchase orders or blanket releases automatically from approved requisition lines. The workflow for creating purchasing documents automatically is called PO Create Documents. You can modify this workflow in the Oracle Workflow Builder to define additional business rules that determine when your approved requisitions are automatically converted into standard purchase orders and blanket releases.

In the Workflow Builder, PO Create Documents consists of several processes. Each of these processes is viewable in the Workflow Builder as a diagram whose objects and properties you can modify. Each workflow process consists of individual functions.

For each document that is created successfully by the PO Create Documents workflow, the PO Approval workflow is called to approve the document if you have allowed automatic approval. See: Choosing Document Creation Options. See: Purchase Order Approval Workflow.

The PO Create Documents workflow is initiated at the end of the requisition approval workflow for approved requisition lines. The workflow begins automatic document creation if you've kept the item attribute Is Automatic Creation Allowed? set to Y for Yes, if source documents are associated with the requisition lines, and you have properly set up sourcing rules (see: Setting Up Automatic Sourcing). If the source document associated with the requisition line is a quotation, a standard purchase order is created. If the source document is a blanket purchase agreement, a release is created.

In addition, the Create Standard Purchase Orders process autocreates a single standard purchase order from multiple requisitions. The concurrent program groups multiple requisitions, using either the supplier or the agreement as the grouping criteria, to create a standard purchase order.

There are also workflow processes for approving changes to purchase orders and releases. See: Workflow Processes for Approving Change Orders.

Customizing the Automatic Document Creation Workflow

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

You can also use the Workflow Builder to create unique document creation 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, Oracle Workflow User's Guide.

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, Oracle Workflow Developer's Guide.

    The Display name of the automatic document creation workflow is PO Create Documents. The name of its Workflow definition file is poxwfatc.wft.

    the picture is described in the document text

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

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

Creating a New Custom Process

You can either modify the default PO Create Documents workflow that Purchasing provides, or copy it and create a whole new workflow. Use the Document Types window to select a custom 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 Create Documents 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.

Important: Creating a new workflow process with a new Internal Name affects the implementation of future upgrades. See: Upgrade Support.

Required Modifications

There are no required modifications you need to make to the PO Create Documents 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

Following is a discussion of what you can and definitely cannot modify in the PO Create Documents 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 Guide.

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

Important: If a particular Workflow object does not appear in the following sections on the lists of things you can customize, do not modify it, regardless of its access level.

Attributes

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

For information on modifying these item attributes' default values, see: Choosing Document Creation 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, the function activity Get Req Line Info in the process Verify Req Line Information updates many item attributes with requisition line information. In turn, these item attributes pass that information on to other function activities and processes in the workflow. Therefore, you should not remove or bypass this function activity, and if you replace it with one of your own, you still need to make sure that these item attributes are set. However, you could add additional checks (processes or function activities) to the Verify Req Line Information process.

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

You can modify all of the processes in PO Create Documents, taking into careful consideration the information described below for each:

Overall Document Creation / Launch Approval

In the Overall Document Creation / Launch Approval process, you could replace the function activity Is Automatic Creation Allowed? with one of your own. Right now, this function activity looks to an item attribute of the same name to see whether automatic document creation from an approved requisition is allowed. But you could replace this function activity with one of your own that has more complex logic. For example, you could replace this function activity with one that allows automatic document creation for requisitions under a certain total price.

You could also add a notification activity-for example after Launch Process to Create and Approve Purchase Order and Release-to let buyers know that the workflow is currently attempting to create and approve your purchase order.

Other than these kinds of additions, you should not interrupt the basic flow of the Overall Document Creation / Launch Approval process by adding or removing any other function activity.

Create and Approve Purchase Order or Release

Just as with Is Automatic Creation Allowed? in the Overall Document Creation / Launch Approval process, you can replace the function activity Is Automatic Approval Allowed? with one of your own that allows automatic approval for only certain kinds of documents. For example, you could automatically approve purchase orders under a certain total price.

Get Buyer

You could modify the Get Buyer process by adding a final function activity that, if no buyer is found by any of the previous activities, always uses a certain buyer. Or, you could replace all of these function activities with one or more of your own that simply uses buyer workload to determine which buyer to use for the purchase order or release.

Does Req Line Have Enough Information to Automatically Create a Document?

It is not recommended that you replace the function activities in this process with function activities of your own.

For example, a supplier is required to create a purchase order or release. Therefore, you should not replace the function activity Does The Req Line Have Valid Supplier Information? with anything else. Additionally, information gathered from this function activity is used later by function activities like Launch Process to Create and Approve Purchase Order or Release and Get The Source Document Type which get required supplier and pricing information.

Similarly, if you don't gather source document information through the function activity Does The Req Line Have Valid Source Document Information?, many function activities in the Verify Req Line Information subprocess will not be able to complete.

Even though it is not recommended to replace any of the function activities in Does Req Line Have Enough Information to Automatically Replace a Document?, you could add function activities-for example, additional information checks-to this subprocess.

Verify Req Line Information

In the Verify Req Line Information subprocess, the function activity Should Workflow Create the Release? looks to an item attribute by the same name to see whether the item attribute says Y for Yes or N for No. (You can set this to Y or N yourself, as described in Choosing Document Creation Options. The default is Y for workflow to create the release.) The function activity Should Workflow Create the Release? looks to its corresponding item attribute to determine if Workflow should create the release, or if Workflow should leave the release to you to create, through the AutoCreate Documents window.

You could replace the function activity Should Workflow Create the Release? with one of your own that uses a different logic (besides Yes/No) to determine whether workflow should create the release. You could make a function activity that looks at the pricing or supplier information on a requisition to determine whether to create the release. For example, Workflow could create the release automatically only for certain suppliers; for other suppliers, it won't, and you would use AutoCreate to create those releases yourself.

Notifications

You can modify the following notifications in the PO Create Documents workflow, as your business needs require:

See: To Create a Notification Activity, Oracle Workflow Developer's Guide. See also: Message Result, Oracle Workflow Developer's Guide and To Create a Message, Oracle Workflow Developer's Guide.

Function Activities

You cannot modify any function activity in the PO Create Documents 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 Create Documents 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:

Messages

You can modify the message body of the following messages in the PO Create Documents workflow:

Lookup Types

You cannot modify any Lookup Types in the PO Create Documents workflow.

The PO Create Documents Item Type

The automatic document creation process is associated with an item type called PO Create Documents. This item type identifies all workflow processes available for automatic purchase order and release creation. The following workflow processes are associated with PO Create Documents:

The PO Create Documents 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 Create Documents Workflow Item Type Attributes

Display Name Description Type Length/ Format/ Lookup Type
Agent ID Unique identifier for the buyer Number  
Autocreated Document ID Unique, internal identifier for the workflow-created document Number  
Buyer UserName User name of the buyer as set up in Oracle Applications Text 100
Category ID Unique identifier for the item category Number  
Currency Code Currency used on the document, such as USD Text 15
Document Number Created Document (PO) number of the purchase order or release Text 50
Document Type Created Disp Display name for the document type Text 25
Document Type To Create Document type (standard or blanket) that the workflow will create from the requisition Text 25
Group ID Unique identifier for the requisition lines, once they are grouped Number  
Interface Header ID Temporary identifier for the requisition lines while they are being grouped in the temporary tables Number  
Interface Source Requisition Import source such as INV Text 30
Is Automatic Creation Allowed? Indicator (Y for Yes or N for No) of whether this workflow is initiated for all approved requisition lines Text 1
Is Automatic Approval Allowed? Indicator (Y for Yes or N for No) of whether the purchase order approval workflow is initiated automatically after this workflow Text 1
Item ID Unique identifier for the item Number  
On RFQ Flag Indicator of whether the requisition line is associated with an RFQ Text 1
Open Document Command that Purchasing sends to open the purchase order or release from the notification notifying you that workflow has created the document Form  
Org ID Unique identifier for the operating unit in which the document was created Number  
P-Card ID Unique identifier for the procurement card number specified on a requisition in iProcurement Number  
PO Number To Create Emergency PO Number specified on a requisition in iProcurement Text 20
Rate Exchange rate on the requisition that gets carried over to the purchase order Number  
Rate Date Date upon which the exchange rate is obtained Date  
Rate Type Exchange rate type Text 30
Release Generation Method Automatic Release/Review, Automatic Release, or Release Using AutoCreate as defined in the Approved Supplier List Text 25
Requisition ID Unique identifier for the requisition from which the purchase order or release is being created Number  
Requisition Line ID Unique identifier for the requisition line from which the purchase order or release is being created Number  
RFQ Required Flag Indicator of whether an RFQ is required for the item on the requisition line before the line can be automatically created onto a purchase order Text 1
Should Workflow Create The Release? Indicator (Y for Yes or N for No) of whether this workflow creates releases or leaves them to you to create using AutoCreate Text 1
Source Document ID Unique identifier for the source document referenced on the requisition Number  
Source Document Line Num Source document line number used on the requisition Number  
Source Document Type Code Type of the source document used Text 25
Suggested Buyer ID Unique identifier for the suggested buyer on the requisition Number  
Suggested Supplier ID Unique identifier for the suggested supplier on the requisition Number  
Suggested Supplier Site Unique identifier for the suggested supplier site on the requisition Text 240
Suggested Supplier Name Name of the suggested supplier on the requisition Text 80
Suggested Supplier Site ID Unique identifier for the suggested supplier site on the requisition Number  

Summary of Overall Document Creation / Launch Approval Process

To view the properties of the Overall Document Creation / Launch Approval process, select the process in the navigator tree, then choose Properties from the Edit menu. The Overall Document Creation / Launch Approval Process process has a result type of None, indicating that when the process completes, it does not have a specific result of, for example, Invalid or Valid, which are found in the Lookup Types branch in the Workflow Builder. Its subprocesses have specific result types associated with them.

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

The Overall Document Creation / Launch Approval process is initiated when requisition lines are approved, you've kept the item attribute Is Automatic Creation Allowed? set to Y for Yes, a source document is associated with the requisition line, and you have properly set up sourcing rules (see: Setting Up Automatic Sourcing).

The process begins at node 1.

Node 2 checks the item attribute Is Automatic Creation Allowed? to see if this workflow for creating documents automatically from approved requisition lines should begin at all.

If automatic document creation is allowed, node 4 launches the subprocess Verify Req Line Information, which checks if the requisition line has enough information from which to automatically create a document. For example, only requisition lines with source documents associated with them can be automatically created by this workflow.

Node 5 waits for all the requisition lines to be processed by the subprocess Verify Req Line Information.

After all requisition lines on the requisition are processed, node 6 checks if the requisition is an emergency requisition created in Oracle iProcurement. An emergency requisition is given a purchase order number in advance. Instead of waiting to group similar requisition lines onto single purchase orders or releases, the PO Create Documents workflow places emergency requisition lines onto their own purchase order at node 8. At node 8, the workflow puts all of an emergency requisition's lines (which have the same Emergency PO Number) onto one purchase order, bypassing the grouping of requisition lines at node 7.

For all other requisitions, the requisition lines on each requisition get grouped appropriately by node 7. For example, if two requisition lines on a requisition have the same Supplier, Site, Currency, and Buyer, they are created on a single purchase order header. Node 7 processes and groups lines from one requisition at a time.

Node 9 launches the Create And Approve Purchase Order or Release process. Node 10 waits for the purchase orders or releases to be created and approved before moving on to the next activity. Node 11 removes the requisition lines from the temporary storing place where they were kept to see which ones could be grouped together.

Overall Document Creation / Launch Approval Process Activities

The following is a description of each activity 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 Create Documents processes, view the Properties page for each function activity. For example, the function activity Is Automatic Creation Allowed? uses the <PACKAGE>.<PROCEDURE> name PO_AUTOCREATE_DOC.SHOULD_REQ_BE_AUTOCREATED.

You can use the Item Type Definitions Web page to view <PACKAGE>.<PROCEDURE> names. See: Item Type Definitions Web Page, Oracle Workflow Developer's Guide.

Start (Node 1)

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

Is Automatic Creation Allowed? (Node 2)

This function activity checks the item attribute Is Automatic Creation Allowed? The default value of this item attribute is Y for Yes. If the value is Y, then automatic document creation is allowed, and the workflow continues. You can prevent automatic document creation by setting the default value of this attribute in the Workflow Builder to N for No.

Launch Process To Verify Req Line Information (Node 4)

This function activity retrieves all requisition lines on the requisition that are available for processing and launches the Verify Req Line Information process for each requisition line.

Wait For Flow (Nodes 5 and 10)

The first Wait For Flow activity waits for all the requisition lines to be processed by Verify Req Line Information. The second Wait For Flow activity waits for the purchase orders or releases to be created and approved before moving on to the next activity.

Is This An Emergency Requisition? (Node 6)

Emergency requisitions are created in iProcurement and submitted to Purchasing for approval and document creation. An emergency requisition is given a purchase order number in advance. Instead of waiting to group similar requisition lines onto single purchase orders or releases, this workflow places emergency requisition lines onto their own purchase order, bypassing the grouping of requisition lines.

Note: In iProcurement, you cannot put multiple suppliers on an emergency requisition.

For more information about iProcurement, see the iProcurement Implementaion Manual.

Group Req Lines Into Purchase Orders Or Releases (Node 7)

Once Verify Req Line Information finishes processing all the requisition lines, this function activity groups together requisition lines that have similar characteristics and allows them to be created onto the same document. For example, if two requisition lines have the same Supplier, Site, Currency, and Buyer, they are created on a single purchase order header. This function activity also groups procurement card lines created in iProcurement that have the same procurement card number, supplier, and supplier site onto one purchase order or release.

Put All Requisition Lines On A Purchase Order (Node 8)

This function activity places all emergency requisition lines, which have the same Emergency PO Number, onto one purchase order.

Launch Process To Create/Approve PO or Release (Node 9)

This function activity initiates the Create and Approve Purchase Order Or Release process for each document. Then it initiates the PO Approval workflow so that purchase orders or blanket releases that match pre-defined approval criteria get approved automatically.

Remove Processed Req Lines From Temp Table (Node 11)

In the Verify Req Line Information process, the function activity Insert Req Line Into Temp Table As A Candidate For Creation puts into a temporary table those requisition lines that contain enough information to attempt automatic document creation. These lines are picked up from this table later when certain requisition lines are grouped onto particular purchase orders or releases. Once these purchase orders or releases are created, the lines in this temporary table can be purged. That is what this function activity, Remove Processed Req Lines From Temp Table, does.

End (Nodes 3 and 12)

This function activity marks the end of the process.

Summary of the Verify Req Line Information Process

To view the properties of the Verify Req Line Information process, select the process in the navigator tree, then choose Properties from the Edit menu. The Verify Req Line Information process has a result type of PO Req Line AutoCreatable?, indicating that when the process completes, it has a result of Automatic Creation Not Allowed, Automatic Creation Not Done Through Workflow, Not Enough Information For Autocreation, or Req Line Can Be Automatically Created. These results correspond to the lookup codes in the PO Req Line AutoCreatable? lookup type in the PO Create Documents item type.

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

The Verify Req Line Information process is initiated by the activity Launch Process To Verify Req Line Information.

The process begins at node 1.

Node 2 retrieves information from the requisition line. Node 3 checks how the profile option PO: Warn if RFQ Required before AutoCreate is set. If it is set to Yes, the requisition line is not on an RFQ, and RFQ Required is checked for the requisition line, the workflow stops automatic document creation because it is unable to issue the warning. This requisition line will be available in the AutoCreate Documents window. Otherwise, even if an RFQ is required for the requisition line, as long as the profile option PO: Warn if RFQ Required before AutoCreate is set to No, the workflow continues creating the document.

Node 5 checks if the requisition line has enough information from which to create a purchase order or release.

Node 7 checks if the requisition is an emergency requisition created in iProcurement, and node 8 checks if a procurement (credit) card number is associated with the requisition. Emergency and procurement card requisitions can be created in iProcurement only.

If the requisition line comes from an emergency or procurement card requisition, none of the activities related to node 12 are performed. Since the workflow does not require an emergency or procurement card requisition to have a source document associated with it, the workflow skips node 12, moves directly to node 9, and continues.

Note: Although a procurement card requisition line doesn't require a source document, if it is associated with a source document such as a blanket purchase agreement, the workflow (through the activity Group Requisition Lines, in a later subprocess) does create a release.

For all other requisition lines, the workflow uses node 12 to retrieve the source document type. If the source document is a quotation, or if the source document is a blanket purchase agreement but the requisition line is for a one-time item, node 9 inserts the requisition line into a temporary table as a candidate for automatic document creation, and the workflow continues.

For a requisition line that has a blanket purchase agreement as a source document (as determined by node 12) and that is not for a one-time time (as determined by node 13), the workflow at node 14 gives different results depending on the release generation method:

Note: No release generation method is retrieved for one-time items at node 14 since the Approved Supplier List does not support one-time items and the release generation method is specified in the Approved Supplier List. If the requisition line is for a one-item item but also associated with a blanket purchase agreement, the workflow does create a release from it later, using the activity Group Requisition Lines. The workflow in this case does not need to retrieve a release generation method from the Approved Supplier List.

Verify Req Line Information Process Activities

The following is a description of each activity in the Verify Req Line Information process, listed by the activity's display name.

Start (Node 1)

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

Get Req Line Info (Node 2)

This function activity retrieves information from the requisition line and updates the item attributes in the PO Create Documents workflow with the information. For example, the Currency Code attribute (under Attributes in the Workflow Builder) gets updated with information from the Currency field in the Requisition line.

Does This Req Line Require An RFQ? (Node 3)

This function activity checks if the following is true: RFQ Required is selected in the Requisitions window, the profile option PO: Warn if RFQ Required before AutoCreate is set to Yes, and the requisition line has not been autocreated into an RFQ. If all of these are true, the workflow ends because it is unable to issue the RFQ Required warning. Otherwise, the workflow continues.

Does Req Line Have Enough Information to Create Document? (Node 5)

See: Does This Req Line Have Enough Information to Automatically Create a Document?.

Is This An Emergency Requisition? (Node 7)

Emergency requisitions are created in iProcurement and submitted to Purchasing for approval and document creation. An emergency requisition is given a purchase order number in advance. Since this workflow does not require an emergency requisition line to have a source document, this workflow bypasses the function activity Get The Source Document Type (node 12) for emergency requisition lines.

Is This Req Line a P-Card Line? (Node 8)

This function activity checks if the requisition line has a procurement card number associated with it. A procurement card (or P-Card) is a corporate credit card used on iProcurement requisitions only.

Get The Source Document Type (Node 12)

This function activity checks for the source document type-blanket agreement or quotation-referenced on the requisition line.

Does the Req Line Have A One-Time Item? (Node 13)

This function activity checks for the type of item-one-time or predefined-used on the requisition line.

Get Release Generation Method From ASL (Node 14)

If the requisition line has a predefined item, this function activity checks if an approved supplier list (ASL) entry exists for that particular combination of item, supplier, and supplier site. Then the function activity retrieves the Release Generation Method specified in the ASL.

If the Release Generation Method is either Automatic Release or Automatic Release Review, then the Creates Releases process in Purchasing will create a blanket release for the requisition line. If the Release Generation Method is Release Using AutoCreate, then the workflow continues.

Should Workflow Create The Release? (Node 19)

This function activity checks the value of the attribute Should Workflow Create The Release? If the value of this attribute is set to Y for Yes, then the workflow creates the release; otherwise, you must use the AutoCreate Documents window to create the release.

Insert Req Line Into Temp Table As A Candidate For Creation (Node 9)

This function activity puts into a temporary table those requisition lines that contain enough information to attempt automatic document creation. These lines are picked up from this table later when certain requisition lines are grouped onto particular purchase orders or releases. Once these purchase orders or releases are created, the lines in this temporary table are purged. (The function activity that does the purging is Remove Processed Req Lines From Temp Table in the Overall Document Creation / Launch Approval Process.)

Continue Flow (Node 10)

This function activity tells the first Wait for Flow function activity in the Overall Document Creation / Launch Approval Process that Verify Req Line Information for a particular requisition line has been completed successfully. Wait for Flow now has to wait only for the other requisition lines to be processed.

End (Nodes 4, 6, 11, 15, 16, 17, and 18)

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 Req Line Information process activity has a result type of PO Req Line AutoCreatable?, each End activity node must have a process result matching one of the lookup codes in the PO Req Line AutoCreatable? lookup type.

Summary of the Does Req Line Have Enough Information To Automatically Create A Document? Process

To view the properties of the Does Req Line Have Enough Information To Automatically Create A Document? process, select the process in the navigator tree, then choose Properties from the Edit menu. This process has a result type of Yes/No, indicating that when the process completes, it has a result of Yes or No. These results correspond to the lookup codes in the Yes/No lookup type in the Standard item type.

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

The process Does Req Line Have Enough Information To Automatically Create A Document? process is used within the process Verify Req Line Information.

The process begins at node 1.

Node 2 checks if the requisition line has enough, correct supplier information, and node 5 checks if the requisition line has enough, correct source document information. This information is needed to automatically create a purchase order or blanket release.

If node 4 indicates that the requisition is an emergency requisition, or node 6 indicates that the requisition is a procurement card requisition, the workflow does not need to check for source document information at node 5 since a source document is not required for these requisitions. Emergency and procurement card requisitions can be created in iProcurement only.

At node 8, the workflow determines which buyer to use for the automatically created document.

Does Req Line Have Enough Information To Automatically Create A Document? Process Activities

The following is a description of each activity in the Does Req Line Have Enough Information To Automatically Create A Document? process, 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 The Req Line Have Valid Supplier Information? (Node 2)

This function activity checks if a valid Supplier and Supplier Site exist for the requisition line.

Is This An Emergency Requisition? (Node 4)

Emergency requisitions are created in iProcurement and submitted to Purchasing for approval and document creation. An emergency requisition is given a purchase order number in advance. Since this workflow does not require an emergency requisition line to have a source document, this workflow bypasses the function activity Does The Req Line Have Valid Source Document Information? (node 5) for emergency requisition lines.

Is This Req Line a P-Card Line? (Node 6)

This function activity checks if the requisition line has a procurement card number associated with it. A procurement card (or P-Card) is a corporate credit card used on iProcurement requisitions only.

Does The Req Line Have Valid Source Document Information? (Node 5)

This function activity checks if valid source document information (from a blanket agreement or quotation) exists for the requisition line. Specifically, it checks the source document type, the source document, and the source document line.

Get Buyer (Node 8)

See: Get Buyer

End (Nodes 3, 7, 9, and 10)

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 Does Req Line Have Enough Information To Automatically Create A Document? process 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.

Summary of the Create and Approve Purchase Order Or Release Process

To view the properties of the Create And Approve Purchase Order Or Release process, select the process in the navigator tree, then choose Properties from the Edit menu. The Create And Approve Purchase Order Or Release process has a result type of PO Document Processed, indicating that when the process completes, it has a result of Document Processed. This result corresponds to the lookup code in the PO Document Processed lookup type in the PO Create Documents item type.

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

The Create And Approve Purchase Order Or Release process is initiated by the activity Launch Process To Create/Approve PO or Release.

The process begins at node 1.

Node 2 creates the purchase order or release. For those documents created successfully, node 3 sends a notification to the buyer that the document has been created.

Node 4 checks if the item attribute Is Automatic Approval Allowed? is set to Y for Yes. If it is, node 5 launches the PO Approval workflow to approve the purchase order or release. Node 6 indicates that the workflow should continue with the final activities in the Overall Document Creation/Launch Approval process.

Create And Approve Purchase Order Or Release Process Activities

The following is a description of each activity in the Create And Approve Purchase Order Or Release process, listed by the activity's display name.

Start (Node 1)

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

Create Purchase Order Or Release (Node 2)

This function activity creates a standard purchase order or blanket release depending on the information on the requisition line.

Purchase Order Or Release Has Been Created (Node 3)

If the document is created successfully, this function activity sends a notification to the buyer.

Is Automatic Approval Allowed? (Node 4)

This function activity checks the value of the attribute, Is Automatic Approval Allowed?. If the item attribute is set to Y for Yes, this workflow launches the PO Approval workflow to approve the purchase order or release. (The default value for the item attribute is N for No.)

Launch Document Approval Process (Node 5)

This function activity launches the PO Approval workflow. See: Purchase Order Approval Workflow

Continue Flow (Node 6)

This function activity tells the second Wait for Flow function activity in the Overall Document Creation / Launch Approval Process that the process Create and Approve Purchase Order Or Release has completed. Wait for Flow now has to wait only for the other documents to be processed.

End (Node 7)

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 Create And Approve Purchase Order Or Release process activity has a result type of PO Document Processed, each End activity node must have a process result matching one of the lookup codes in the PO Document Processed lookup type.

Summary of the Get Buyer Subprocess

To view the properties of the Get Buyer process, select the process in the navigator tree, then choose Properties from the Edit menu. The Get Buyer process has a result type of PO Action Result, indicating that when the process completes, it has a result of Action Failed or Action Complete. These results correspond to the lookup code in the PO Action Result lookup type in the PO Create Documents item type.

This process activity is not runnable, indicating that it cannot be initiated as a top-level process to run, but rather can be run only as a subprocess when called by a higher-level process.

This process retrieves buyer information for the purchase order. Node 2 retrieves a valid buyer name from the buyer field on the requisition line. If no buyer is indicated there, node 4 retrieves the default buyer from the item definition in the Master Item window. If no buyer is indicated there, node 6 retrieves the default category assigned to a buyer in the Define Buyers window. If no buyer is indicated there, node 8 retrieves the buyer from the source document associated with the requisition line. When creating a release, this subprocess retrieves the buyer's name from the blanket agreement.

If the workflow does not find a buyer, it does not create the document. The requisition line, however, will still be available to you in the AutoCreate Documents window in Purchasing.

Get Buyer Subprocess Activities

The following is a description of each activity in the Get buyer process, listed by the activity's display name.

Start (Node 1)

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

Get Buyer From Req Line (Node 2)

This function activity tries first to get the buyer from the requisition line.

Get Buyer From Item (Node 4)

If Get Buyer From Req Line fails, then this function activity tries to get the buyer assigned to the item in the Master Item window.

Get Buyer From Category (Node 6)

If Get Buyer From Item fails, this function activity tries to get the buyer assigned to the Category on the requisition line.

Get Buyer From Source Doc (Node 8)

If Get Buyer From Category fails, this function activity tries to get the buyer from the source document associated with the requisition line. If more than one or no buyers are assigned, then this function activity fails.

End (Nodes 3, 5, 7, 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 Get Buyer subprocess activity has a result type of PO Action Result, each End activity node must have a process result matching one of the lookup codes in the PO Action Result lookup type.

Using the Workflow Monitor for the PO Create Documents Workflow

To monitor a document as it proceeds through a workflow, you need to provide the Workflow Monitor with an item key, which is specific both to the document you are monitoring and the process in which you're monitoring it.

For information on how to use the Workflow Monitor, see: Overview of Workflow Monitoring, Oracle Workflow User's Guide.

To determine the item key for the PO Create Documents workflow:

  1. Write down the requisition number of the requisition you're monitoring.

  2. Find the REQUISITION_HEADER_ID by writing the following SQL* statements. (The REQUISITION_HEADER_ID is an internal number not found in the Requisitions window.)

    For example, if the requisition number is 12012570, you would write this SQL* statement:

    select requisition_header_id
    from   po_requisition_headers_all
    where  segment1='12012570';

    A REQUISTION_HEADER_ID is returned.

  3. Using the REQUISITION_HEADER_ID returned in the step above, find the Overall Document Creation / Launch Approval process item key by writing the following SQL* statements.

    For example, if the REQUISITION_HEADER_ID is 1024961, you would write the following SQL* statement:

    select item_type, item_key, root_activity  
    from   wf_items
    where  item_key like '1024961'||'%'
    and    item_type='CREATEPO'
    and    root_activity='OVERALL_AUTOCREATE_PROCESS';

    The item key for your requisition, as it appears in the Overall Document Creation / Launch Approval process, is returned. For example:

       ITEM_TYP  ITEM_KEY            ROOT_ACTIVITY 
       --------  ------------------  ------------------------
       CREATEPO  1024961-12374       OVERALL_AUTOCREATE_PROCESS

    Next, you need to identify the unique item keys for your requisition as it appears in the other PO Create Documents processes, so that you can monitor it all the way through the workflow. This is described in the next step.

  4. Using the ITEM_KEY returned from the step above, find the ITEM_KEY for the other two workflow processes, Verify Req Line Information and Create and Approve Document, using the following SQL* statements.

    For example, if your ITEM_KEY is 1024961-12374, you would write this SQL* statement:

    select item_type, item_key, root_activity
    from   wf_items
    where  parent_item_type = 'CREATEPO'
    and    parent_item_key  = '1024961-12374';

    REQ_LINE_PROCESSING returns an item key for each requisition line. CREATE_AND_APPROVE_DOC returns an item key for each purchase order. For example:

       ITEM_TYP  ITEM_KEY            ROOT_ACTIVITY 
       --------- -------------------  ------------------------
       CREATEPO  1025575-12375         REQ_LINE_PROCESSING
       CREATEPO  1004590-12376         CREATE_AND_APPROVE_DOC

    You don't need to find item keys for the processes Get Buyer and Does This Req Line Have Enough Information to Automatically Create a Document, because they are subprocesses of the other processes; you can drill down to these subprocesses through the Workflow Monitor, without an item key.

Confirm Receipts Workflow

The Confirm Receipts workflow sends notifications through the Web, e-mail, or Notifications Summary window to requesters or buyers who create requisitions through Purchasing or Oracle iProcurement. It lets people know they should have received an item.

The Confirm Receipts workflow sends notifications for items with a Destination or Deliver-To Type of Expense, a Routing of Direct Delivery, and a Need-By date that is equal to or later than today's date.

This workflow requires that the Workflow Background Process and the Confirm Receipts Workflow Select Orders process be running. See: Confirm Receipts Workflow Select Orders.

Customizing the Confirm Receipts Workflow

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

You can use the Workflow Monitor to follow where certain documents are in a workflow process. See: Overview of Workflow Monitoring, Oracle Workflow User's Guide.

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, Oracle Workflow Developer's Guide.

    The Display name of the workflow is PO Confirm Receipt. The name of its Workflow definition file is poxwfrcv.wft.

    the picture is described in the document text

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

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

Creating a New Custom Process

If you want to customize the PO Confirm Receipt workflow, you must customize the default (original) workflow that Purchasing provides. Unlike the PO Approval, PO Requisition Approval, and PO Create Documents workflows in Purchasing, only one PO Confirm Receipt workflow can be called from the application itself. You can't select a separate customization, like you can with the other workflows in the Document Types window. Therefore, you need to make your customizations to the default workflow. You'll always have your backup to revert to, if you need, while you are testing your customizations.

Required Modifications

There are no required modifications you need to make to the PO Confirm Receipt workflow itself. However, for the confirm receipts workflow to work, you need to submit the Workflow Background Process and the Confirm Receipts Workflow Select Orders process. See: Confirm Receipts Workflow Select Orders.

Optional Customizations

You can change the amount of time given before reminding the requester to respond to a receipt confirmation. You do this by entering your own Timeout intervals in the Control Properties window for each of the notifications in the Notify Requestor subprocess.

These notifications already provide a default Timeout period before which a requester is reminded to respond to the receipt confirmation, but you can change the Timeout to suit your business needs.

To change the default Timeout intervals:

  1. Select any of the following notification activities in the Notify Requester process:

  2. Notify Requestor of Confirm Receipt - initial notification

  3. Notify Requestor of Confirm Receipt - first reminder

  4. Notify Requestor of Confirm Receipt - second reminder

  5. Open the notification's Properties window and change the Timeout period before which the next reminder is sent, or before which the last reminder times out and sends a notification to the requester's manager. For instructions, see the Oracle Workflow Guide, Oracle Workflow Developer's Guide.

Supported and Unsupported Customizations

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

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

Important: If a particular Workflow object does not appear in the following sections on the lists of things you can customize, do not modify it, regardless of its access level.

Attributes

You cannot modify any item attributes in the PO Confirm Receipt workflow. However, you can add item attributes.

Processes

If you modify a process, it is essential that the basic flow remain intact to maintain data integrity in the database:

You should not remove any default function activities from the following processes. You may, however, add your own additional function activities to them:

Notifications

You cannot modify any of the PO Confirm Receipt notifications except for the Timeout feature in the Notify Requester of Confirm Receipt notifications in the Notify Requester process.

Function Activities

You cannot modify any function activities in the PO Confirm Receipt workflow.

However, you can replace some function activities with function activities of your own. When you replace a function activity, you are effectively modifying the process in which it is contained. See the guidelines for customizing the PO Confirm Receipt 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:

Messages

You can modify any of the PO Confirm Receipt messages to suit your business needs.

See: Message Result, Oracle Workflow Developer's Guide and To Create a Message, Oracle Workflow Developer's Guide.

Lookup Types

You cannot modify any of the PO Confirm Receipt lookup types.

The Confirm Receipts Workflow Item Type

The Confirm Receipts workflow process is associated with an item type called PO Confirm Receipt. This item type identifies all workflow processes available for confirming receipts. The following workflow processes are associated with PO Confirm Receipt:

The PO Confirm Receipt 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 Confirm Receipt Workflow Item Type Attributes

Display Name Description Type Length/ Format/ Lookup Type
Buyer's Display Name Buyer's name as displayed in the window field Text 80
Buyer ID Unique identifier for the buyer Text  
Buyer's Username Buyer's user (short) name as defined in Oracle Applications Text 80
Currency Code 1-5 The Currency used on the first 5 lines of the requisition Text 3
Due Date Date the shipment is due Date DD-MON-YYYY
Filler11, 12, 21, 22, 31, 32, 41, 42, 51, and 52 Notification boiler-plate text such as "This is" and "for requisition number" Text 50
Functional Currency The functional currency used in your Ledger Text 10
Item description 1-5 Description of the first 5 items Text 240
Item price 1-5 Price of the first 5 items Text 20
Line 1-5 First 5 lines on the document, for reference Text 9
Quantity 1-5 Quantity of each of the first 5 requisition lines Number  
Manager's Display Name Name of the requester's manager Text 80
Manager ID Unique identifier for the requester's manager Number  
Manager's Username User (short) name of the requester's manager as defined in Oracle Applications Text 80
More Lines note Notification text indicating whether the requisition has more than the first 5 lines displayed in the notification Text 80
Note from requester Note from the requester Text 640
Note to receiver Note to the receiver of the purchase order, in Terms and Conditions window    
Number of Lines Number of lines in the notification message to the buyer Number  
PO Header ID Purchase order internal identification number Number  
PO Number Purchase order number Text 20
Rct_Qty1-5 Partially received quantity if indicated by requester Number  
Receive Orders URL iProcurement Receive Orders Web page URL URL  
Receiving Transaction Status Receiving status such as Failed or Pending Text 500
Requester's Display Name of the requester on the purchase order or requisition Text 80
Requester_ID Unique identifier for the requester Number  
Requester's Username User name of the requester on the purchase order or requisition Text 80
Requisition date 1-5 Date of each of the first 5 requisition lines Text 30
Requisition number 1-5 Requisition number for each of the first 5 requisition lines used on the order Text 30
Supplier's Display Name Supplier's name as displayed in the window field Text 80
Supplier ID Unique identifier for the supplier Number  
Total Number of Lines in PO Total number of lines in the purchase order Number  
Unit of measure 1-5 UOM for each of the first 5 document lines Text 15

Summary of the Confirm Receipt Process

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

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

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

The Confirm Receipt process begins when you submit the Confirm Receipts Workflow Select Orders process through the Requests window.

The workflow begins at node 1.

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

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

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

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

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

Confirm Receipt Process Activities

The following is a description of each activity 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 Confirm Receipts processes, view the Properties page for each function activity. For example, the function activity Retrieve Requester's Manager uses the <PACKAGE>.<PROCEDURE> name PORCPTWF.GET_REQUESTER_MANAGER.

You can use the Item Type Definitions Web page to view <PACKAGE>.<PROCEDURE> names. See: Item Type Definitions Web Page, Oracle Workflow Developer's Guide.

Retrieve Order Information (Node 1)

This function activity retrieves the purchase order and requisition information from the RCV_CONFIRM_RECEIPT_V table using the PO_HEADER_ID, EXPECTED_RECEIPT_DATE and REQUESTER_ID as search criteria. The retrieved data are used by the Notify Requester subprocess for sending the notification message, which contains the order header and order line data.

Retrieve Receive Orders Web Page URL (Node 2)

This function activity retrieves the URL of the Receive Orders Web page, which you set up through iProcurement. The URL provides a direct link from the workflow notification message to the Receive Orders web page for processing receipt confirmation through iProcurement, if iProcurement is installed.

Retrieve Requester's Manager (Node 10 )

If the requester does not respond before the number of days indicated by the notification activities in the Notify Requester subprocess, this function activity retrieves the manager's user name from your hierarchy setup. The workflow then notifies the manager.

Process Receiving Transactions (Node 6)

This function activity processes transactions in the Receiving Open Interface when the workflow notification is responded to as Fully Received. It ensures that the shipment or shipments are still open. It invokes the Receiving Open Interface program to insert the receipt records into the receiving transactions open interface table.

The Receiving Transaction Manager is then called in On-line mode (regardless of how you set the profile option RCV: Processing Mode) to process the receipt records immediately. If there are errors, you receive a notification of such, sent by the activity Notify Receiving Transactions Failure.

Notify Requester's Manager of Time Out (Node 11)

If the requester does not respond before the number of days indicated by the notification activities in the Notify Requester subprocess, this function activity notifies the requester's manager.

Notify Receiving Transactions Failure (Nodes 7 and 9)

There are two of these activities in the Confirm Receipt process. They are used whenever a receipt cannot be created-for example, when the Receiving Transaction Manager has not started or if someone has already created a receipt in the Receipts window. One activity sends a notification to the requester that the receipt could not be created; the other sends the same notification to the buyer. On the Web, this activity presents an error message immediately on the screen. This activity also sends a formal notification to your regular notification queue.

Notify Buyer of Partial Receipt (Node 5)

If the requester responds in the Notify Requester subprocess activity with Partially/Over Received, this activity notifies the buyer that the items have been partially or over-received. The notification shows the quantity that was supposed to be received and the quantity that was actually received.

Notify Buyer of Non-Receipt (Node 4)

If the requester responds in the Notify Requester subprocess activity with Not Received, this activity notifies the buyer that the items have not been received.

End (Node 12)

This activity ends the process.

Summary of the Notify Requester Subprocess

To view the properties of the Notify Requester process, select the process in the navigator tree, then choose Properties from the Edit menu. The Notify Requester process has a result type of Notify Requester Response, indicating that when the process completes, it has a result of Fully Received, Not Received, Partially/Over Received, or Time Out. These results correspond to the lookup code in the Notify Requester Response lookup type in the PO Confirm Receipt item type.

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

This process sends a notification to the requester to confirm the receipt of expense items that are past their due date. The requester can then respond that the items were not received, partially or over-received, or fully received.

The notification activities at nodes 1, 5, and 6 contain the following default Timeout days:

Because the first notification at node 1 contains a default Timeout of 7 days, the second notification at node 5 sends a reminder to the requester after 7 days. The third notification at node 6 sends a final reminder after another 7 days.

Node 6 times out after one additional day, if still no response is received from the requester. The Confirm Receipt process then notifies the requester's manager to confirm receipt of the goods.

You can change these default Timeout numbers to your own desired settings. See: Customizing the Confirm Receipts Workflow.

Notify Requester Subprocess Activities

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

Notify Requester of Confirm Receipt - initial notice (Node 1)

This activity notifies the requester that the requester should have received the goods, and asks for confirmation.

Notify Requester of Confirm Receipt - first reminder (Node 5)

This activity sends a reminder to the requester if no response is received after 7 days (or however many days you specify in the previous activity's Control Properties window; the default is 7 days).

Notify Requester of Confirm Receipt - second reminder (Node 6)

This activity sends a second reminder to the requester if no response is received after another 7 days (or however many days you specify in the previous activity's Control Properties window; the default is 7 days). If still no response is received after one day, the Notify Requester subprocess activity times out and sends the receipt confirmation notification to the requester's manager.

End (Nodes 2, 3, 4, 8, 10, and 12)

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 Requester subprocess activity has a result type of Notify Requester Response, each End activity node must have a process result matching one of the lookup codes in the Notify Requester Response lookup type.

PO Send Notifications Workflow

The workflow PO Send Notifications for Purchasing Documents looks for documents that are incomplete, rejected, or in need of reapproval and sends notifications to the appropriate people of the document's status. You can view and respond to these notifications through the Notifications Summary window.

For information on the kinds of notifications sent by the Send Notifications for Purchasing Documents process, see: Viewing and Responding to Notifications.

In order for these notifications to be sent, you need to start the concurrent program process, Send Notifications for Purchasing Documents, and choose how frequently you want the process to run. See: Send Notifications for Purchasing Documents.

Customizing the PO Send Notifications for Purchasing Documents Workflow

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

You can use the Workflow Monitor to follow where certain documents are in a workflow process. See: Overview of Workflow Monitoring, Oracle Workflow User's Guide.

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, Oracle Workflow Developer's Guide.

    The Display name of the workflow is PO Send Notifications for Purchasing Documents. The name of its Workflow definition file is poxwfarm.wft.

    the picture is described in the document text

  2. Expand the data source, then the PO Send Notifications for Purchasing Documents item type branch within that data source.

  3. Expand the Processes branch within PO Send Notifications for Purchasing Documents branch, then double-click on its process activity to display the process diagram.

Creating a New Custom Process

If you want to customize the PO Send Notifications for Purchasing Documents workflow, you must customize the default (original) workflow that Purchasing provides. Unlike the PO Approval, PO Requisition Approval, and PO Create Documents workflows in Purchasing, only one PO Send Notifications for Purchasing Documents workflow can be called from the application itself. You can't select a separate customization, like you can with the other workflows in the Document Types window. Therefore, you need to make your customizations to the default workflow. You'll always have your backup to revert to, if you need, while you are testing your customizations.

Required Modifications

There are no required modifications you need to make to the PO Send Notifications for Purchasing Documents workflow itself. However, for the workflow to work, you need to start the concurrent program process, Send Notifications for Purchasing Documents, if you didn't already start this process when you set up Purchasing. See: Send Notifications for Purchasing Documents.

Supported and Unsupported Customizations

Following is a discussion of what you can and definitely cannot modify in the PO Send Notifications for Purchasing Documents workflow. For those things you can modify, the discussion includes important guidelines that you need to be very 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 Send Notifications for Purchasing Documents Item Attributes. These sections describe the components of the automatic document creation processes in the workflow. If you haven't already, see also: Customization Guidelines.

Important: If a particular Workflow object does not appear in the following sections on the lists of things you can customize, do not modify it, regardless of its access level.

Attributes

You cannot modify any of the attributes in the PO Send Notifications for Purchasing Documents workflow.

Processes

If you modify a process, it is essential that the basic flow remain intact to maintain data integrity in the database:

There is one process in the PO Send Notifications for Purchasing Documents workflow, and you can modify it as your business needs require, paying careful attention to the guidelines described above and in the following section, Function Activities:

Notifications

You cannot modify any of the notifications in the PO Send Notifications for Purchasing Documents workflow.

Function Activities

You cannot modify any function activities in the PO Send Notifications for Purchasing Documents workflow.

However, you can replace some function activities with function activities of your own. When you replace a function activity, you are effectively modifying the process in which it is contained. See the guidelines for customizing the 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:

Messages

You can modify any of the messages in the PO Send Notifications for Purchasing Documents workflow, as your business needs require.

See: Message Result, Oracle Workflow Developer's Guide and To Create a Message, Oracle Workflow Developer's Guide.

Lookup types

You cannot modify any of the lookup types in the PO Send Notifications for Purchasing Documents workflow.

The PO Send Notifications for Purchasing Documents Item Type

The notification sending process is associated with an item type called PO Send Notifications for Purchasing Documents. This item type identifies all notification workflow processes available. There is one workflow process associated with PO Send Notifications for Purchasing Documents: PO Document Approval Reminder.

The PO Send Notifications for Purchasing Documents 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 Send Notifications for Purchasing Documents Item Type Attributes

Display Name Description Type Length/ Format/ Lookup Type
Acceptance Due Date Date acceptance is due Date  
Acceptance Past Due Indicator that the acceptance due date has passed Text 25
Agent Display Name Buyer's name as displayed in Purchasing Text 250
Agent ID Unique identifier for the buyer Number  
Agent User Name Buyer's user name Text 100
Document ID Unique identifier for the document submitted to this workflow Number  
Document Number Document number for the document submitted to this workflow Text 80
Document Subtype Document subtype Text 80
Document Type Document type Text 60
Document Type Display Document type as displayed in Purchasing Text 250
Forward From Display Name Name of the person who forwarded the document, as displayed in Purchasing Text 250
Forward From ID Unique identifier of the person who forwarded the document Number  
Forward From User Name User name of the person who forwarded the document Text 250
Forward to Display Name Name of the forward-to person as displayed in Purchasing Text 250
Forward to ID Unique identifier for the forward-to person Number  
Forward to ID Old Value Item attribute for internal use that keeps track of the previous forward-to person Number  
Forward to User Name User name of the forward-to person Text 250
Never Approved Message Text message that shows the document was never approved Text 500
Note Note text Text 240
Open PO Form Command Command that Purchasing sends to open the purchase order from the notification Form  
Open Quotations Form Command Command that Purchasing sends to open the quotation from the notification Form  
Open Release Form Command Command that Purchasing sends to open the release from the notification Form  
Open Req Form Command Command that Purchasing sends to open the requisition from the notification Form  
Open RFQ Form Command Command that Purchasing sends to open the RFQ from the notification Form  
Org ID Unique identifier for the operating unit Number  
Quotation Status Quotation status such as In Process or Active Text 25
Quote End Date Active Quotation expiration date Date  
Quote Type Display Quotation type as displayed in Purchasing Text 250
Quote Warning Delay Number of days prior to the expiration of the quotation that you want to be notified Number  
Release Revision Number Document revision number Number  
Requires Approval Message Text for the Requires Approval message Text 500
Requisition Rejected Message Text for the Requisition Rejected message Text 500
Requisition Returned Message Text for the Requisition Returned message Text 500
Response Forward To Forward-to response Text 250
RFQ Close Date Date the RFQ will be closed Date  
RFQ Reply Date Date the supplier replied to the RFQ Date  
RFQ Status RFQ status such as In Process or Active Text 25
Wrong Forward to Error Message Text for "wrong forward-to" message Text 500

Summary of the PO Document Approval Reminder Process

To view the properties of the PO Document Approval Reminder process, select the process in the navigator tree, then choose Properties from the Edit menu. The PO Document Approval Reminder process has a result type of None, indicating that when the process completes, it doesn't end with any particular result, such as End (Approved) or End (Rejected). Instead, its subprocesses end with specific results.

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

The workflow begins at node 1.

At node 2, this workflow branches differently depending on whether the document is a quotation, RFQ, requisition, purchase order, purchase agreement, or release; or a buyer's recording of a supplier's acceptance of a purchase order or release.

Then, at nodes 3, 7,11, and 15, the workflow uses the standard Workflow comparison activity to determine how to branch next. The comparison activities provide a standard way to compare two numbers, dates, or text strings. Node 3 checks whether the quotation requires completion or is near expiration. Node 7 checks the same for an RFQ. Node 11 checks whether release acceptance is required or past due. Node 15 checks the same for a purchase order.

Nodes 19, 23, and 27 send approval reminder notifications for documents that have not been submitted for approval, such as incomplete documents. These documents are detected by the Send Notifications for Purchasing Documents process.

If the person receiving the reminder notification responds with Ignore, Purchasing dismisses the notification from the person's notification queue until the next time the Send Notifications for Purchasing Documents process runs. The workflow then ends at node 22 or 26.

If the person receiving the reminder notification responds with Approve, the activity at node 20, 24, or 26 makes sure that the forward-to person specified is a valid forward-to approver. If not, the standard Workflow activity at node 21, 25, or 29 directs the workflow to resend the reminder notification.

Node 30 launches the appropriate approval workflow if the notification is answered with Approve and the forward-to approver (if any) is valid.

PO Document Approval Reminder Process Activities

The following is a description of each activity 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 Document Approval Reminder process, view the Properties page for each function activity. For example, the function activity Set Document Type uses the <PACKAGE>.<PROCEDURE> name PO_APPROVAL_REMINDER_SV.SET_DOC_TYPE.

You can use the Item Type Definitions Web page to view <PACKAGE>.<PROCEDURE> names. See: Item Type Definitions Web Page, Oracle Workflow Developer's Guide.

Start (Node 1)

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

Set Document Type (Node 2)

This function activity determines the document type: quotation, RFQ, requisition, purchase order, purchase agreement, release, or a purchase order or release that requires acceptance.

Compare Text (Nodes 3, 7, 11, and 15)

This is a standard Workflow comparison activity that provides a standard way to compare two numbers, dates, or text strings. See: Comparison Activities, Oracle Workflow Developer's Guide.

Quotation Requires Completion Notification (Node 4)

This activity sends a notification to the document preparer that the quotation requires completion because its status is still In Process.

Quotation Near Expiration Notification (Node 5)

This activity sends a notification to the document preparer that the quotation is nearing expiration. That is, the quotation is Active, and the current date is between the Effectivity end date on the document and the Quote Warning Delay date in the Purchasing Options window.

RFQ Near Expiration Notification (Node 9)

This activity sends a notification to the document preparer that the RFQ is nearing expiration. That is, the RFQ is Active, and the current date is between the Due Date and the Close Date on the RFQ.

RFQ Requires Completion Notification (Node 8)

This activity sends a notification to the document preparer that the RFQ requires completion because its status is still In Process.

Release Acceptance Required Notification (Node 12)

This activity sends a notification that acceptance is required if Acceptance Required is selected for the release in the Terms and Conditions window, and the release has not been entered as accepted in the Acceptances window.

Release Acceptance Past Due Notification (Node 13)

If the Acceptance Require By date for the release indicates that acceptance is overdue, this activity sends a notification that acceptance is past due.

PO Acceptance Required Notification (Node 16)

This activity sends a notification that acceptance is required if Acceptance Required is selected for the purchase order in the Terms and Conditions window, and the purchase order has not been entered as accepted in the Acceptances window.

PO Acceptance Past Due Notification (Node 17)

If the Acceptance Require By date for the purchase order indicates that acceptance is overdue, this activity sends a notification that acceptance is past due.

Approve Requisition Reminder Notification (Node 19)

This activity sends a notification that the requisition requires approval because it is incomplete, rejected, or in need of reapproval.

Approve Purchase Order Reminder Notification (Node 23)

This activity sends a notification that the purchase order requires approval because it is incomplete, rejected, or in need of reapproval.

Approve Purchase Order Release Reminder Notification (Node 27)

This activity sends a notification that the release requires approval because it is incomplete, rejected, or in need of reapproval.

Is Forward to Valid? (Nodes 20, 24, and 28)

This function activity checks if the person responding to the notification has provided a forward-to approver and, if so, if the forward-to approver is a valid approver.

Noop (Nodes 21, 25, and 28)

This is a standard Workflow activity. Here, it is used to simply return to the previous activity, the reminder notification, if the forward-to approver is not valid. See: Noop Activity, Oracle Workflow Developer's Guide.

Start Document Approval

If the notification is answered with Approve, and the forward-to approver (if any) is valid, this function activity launches the appropriate approval workflow.

End

This function activity marks the end of the process.

Price/Sales Catalog Notification Workflow

The price/sales catalog notification workflow uses the Price Update Tolerance you set to determine when a price increase in an Update price/sales catalog submission exceeds your tolerance. Workflow is an underlying technology that sends a notification to the buyer if the price tolerance is exceeded and waits for the buyer to accept or reject the price increase. The Purchasing Documents Open Interface applies or does not apply the price increase depending on the buyer's action.

The buyer is notified automatically by the workflow. The supplier is notified of price update rejections only if you customize the workflow to do so.

You can view or modify this workflow in the Oracle Workflow Builder. See the Oracle Workflow Guide.

The following figure shows how the workflow affects line statuses in the Purchasing Documents Open Interface tables:

the picture is described in the document text

Customizing the Issue Notifications Process

You can view the workflow in a Process window using the Workflow Builder.

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, Oracle Workflow Developer's Guide.

    The Display name of the price/sales catalog notification workflow is PO Catalog Price Tolerance Exceeded Notifications. The name of its Workflow definition file is poxprcat.wft.

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

  3. Expand the Processes branch, then double-click the Issue Notifications process activity to display its diagram.

    the picture is described in the document text

Required Modifications

There are no required modifications you need to make to this workflow.

Optional Customizations

Although you can use the workflow as is, you may wish to customize it further to accommodate your organization's specific needs. You can modify the Issue Notifications process to suit your business needs.

You could modify the process to send the buyer a reminder sooner or later than the activity Wait for Buyer Action from Exceeded Price Tolerances Form does by default. You could modify the workflow to send the notification to people other than the buyer. If you want to send the supplier an automatic notification of rejected price updates, you must modify the workflow. Some of these customizations are described below.

To help you with your customizations, refer to the sections later that describe the components of this process.

See also: Customization Guidelines.

To change the Timeout period from seven days:

  1. In the Workflow Builder, expand the Functions branch and select the Wait for Buyer Action from Exceeded Price Tolerances Form activity.

  2. Open the activity's Properties window.

  3. Change the Timeout to a period of time that best suits your organization's needs.

  4. In Oracle Applications, submit the Workflow Background Process if you haven't already. See: To Schedule Background Engines, Oracle Workflow Administrator's Guide.

Create Workflow users and roles for your suppliers and associate e-mail addresses with them.

See: Setting Up an Oracle Workflow Directory Service, Oracle Workflow Administrator's Guide.

To send automatic notifications of rejected price updates to the supplier:

  1. Create a function activity that for a given supplier assigns the correct supplier user name to the Supplier User Name item attribute.

    When you create a function activity in the Workflow Builder, you also have to create the PL/SQL stored procedure that the function activity calls.

    See: To Create a Function Activity, Oracle Workflow Developer's Guide.

  2. Place the function activity in the Issue Notifications process diagram.

    You could place it after the Were Any Items Rejected? activity and before the Supplier Username Value activity. Your new function activity will assign the supplier's user name to the Supplier User Name item attribute. Then, the Supplier Username Value activity retrieves the supplier name from the item attribute.

Supported and Unsupported Customizations

You cannot modify any of the item attributes except for Supplier User Name. (Information about when you might customize this attribute is provided in the section above.) You cannot modify any of the function activities or messages in the workflow; however, you could replace them in the Issue Notifications process with ones of your own. You can modify the notification activities.

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

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

Creating a New Custom Process

Customize the default (original) workflow that Purchasing provides, after you make a backup. Unlike the PO Approval, PO Requisition Approval, and PO Create Documents workflows, only one price/sales catalog notification workflow can be called in Purchasing. You can't select a separate customization, like you can with the other workflows in the Document Types window. Therefore, you need to make your customizations to the default workflow. You'll always have your backup to revert to, if you need, while you are testing your customizations.

The PO Catalog Price Tolerances Exceeded Notifications Item Type

The Issue Notifications process is associated with an item type called PO Catalog Price Tolerances Exceeded Notifications. This item type identifies all workflow processes available with the price/sales catalog update submission.

The PO Catalog Price Tolerances Exceeded Notifications item type also has several 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.

To view descriptions of each item type attribute, select the attribute in the Workflow Builder and choose Properties from the Edit menu. Look in the Description field.

Summary of the Issue Notifications Process

To view the properties of the Issue Notifications process, select the process in the navigator tree, then choose Properties from the Edit menu. The Issue Notifications process has no result type, indicating that when the process completes, it has no defined result of, for example, End (Valid) or End (Invalid) corresponding to any lookup type in the navigator tree.

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

Node 2 sends the buyer a notification if any of the supplier price updates exceed the price tolerance you have set as described in the section Monitoring Price Increases in a Price/Sales Catalog Update. Node 3 waits for the buyer to respond before updating the price or price breaks. If the buyer at node 3 does not respond after the amount of time you specify in the Control Properties page, the notification at node 2 is sent to the buyer again.

As soon as the buyer responds to all of the pending price updates, node 2 cancels the notification so that it does not show up the next time the buyer queries for notifications.

Node 5 determines if any price updates were rejected. If they were, node 7 can notify the supplier of the document lines whose prices were rejected if you customize the workflow to send automatic supplier notifications. See Optional Customizations.

Issue Notifications Process Activities

The following is a description of each activity 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 Issue Notifications process, view the Properties page for each function activity. For example, the function activity Cancel Any Outstanding Buyer Notifications uses the <PACKAGE>.<PROCEDURE> name PO_WF_PO_PRICAT_UPDATE.CANCEL_BUYER_NOTIF.

You can use the Item Type Definitions Web page to view <PACKAGE>.<PROCEDURE> names. See: Item Type Definitions Web Page, Oracle Workflow Developer's Guide.

Notify Buyer of Price Updates that Exceed Tolerance (Node 2)

If any of the price updates in the price/sales catalog update submission exceed the tolerance you have set, this activity sends the buyer a notification. One notification is sent for each document.

Wait for Buyer Action from Exceeded Price Tolerances Form (Node 3)

This function activity waits for the buyer to respond to the notification. The price update is not made and the workflow does not continue until the buyer responds. If the buyer does not respond after the amount of time specified in the Control Properties page of this activity, the notification is sent to the buyer again.

Cancel any Outstanding Buyer Notifications (Node 4)

As soon as the buyer responds to the notification, this activity cancels the notification so that it does not show up the next time the buyer queries for notifications.

Were Any Items Rejected? (Node 5)

This function activity determines if any price updates were rejected.

Supplier Username Value (Node 6)

This function activity is a standard Workflow activity used to do comparisons. It makes sure that the supplier's user name is on the list of user names in Oracle Applications. This activity is used only if you create a function activity to populate the Supplier User Name item attribute. This function activity is associated with the Standard item type.

Notify Supplier of Price Updates that were Rejected (Node 7)

If the function activity Were Any Items Rejected? records any price updates that the buyer rejected, this activity sends a notification to the supplier if your supplier is set up in Workflow to receive such notifications. See the Oracle Workflow Guide.

Debit Memo Notification Workflow

The workflow Debit Memo Notification notifies you through the Notifications Summary window of debit memos that could not be created. For example, if an invoice was not yet created for the receipt when entered the return, a debit memo for the invoice would not have been able to be created and you would receive a notification of such. See: Debit Memos.

Customizing the Debit Memo Notification Workflow

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

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, Oracle Workflow Developer's Guide.

    The Display name of the workflow is PO Debit Memo Notifcation. Its internal name, viewable through the Workflow Builder, is RCVDMEMO. The name of its Workflow definition file is rcvwfdmo.wft.

    the picture is described in the document text

  2. Expand the data source, then the PO Debit Memo Notification item type branch within that data source.

  3. Expand the Processes branch within the PO Debit Memo Notification branch, then double-click on its process activity to display the process diagram.

Creating a New Custom Process

If you want to customize the PO Debit Memo Notification workflow, you must customize the default (original) workflow that Purchasing provides. Unlike the PO Approval, PO Requisition Approval, and PO Create Documents workflows in Purchasing, only one PO Debit Memo Notification workflow can be called from the application itself. You can't select a separate customization, like you can with the other workflows in the Document Types window. Therefore, you need to make your customizations to the default workflow. Create a backup to revert to, if you need, while you are testing your customizations.

Required Modifications

There are no required modifications you need to make to the PO Debit Memo Notification workflow.

Supported and Unsupported Customizations

Following is a discussion of what you can and definitely cannot modify in the PO Debit Memo Notification 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 following sections, The PO Debit Memo Notification Item Type and Summary of the Debit Memo Process. These sections describe the components of the notification process in the workflow. If you haven't already, see also: Customization Guidelines.

Important: If a particular Workflow object does not appear in the following sections on the lists of things you can customize, do not modify it, regardless of its access level.

Attributes

You cannot modify any of the attributes in the PO Debit Memo Notification workflow.

Processes

There is one process, "Debit Memo," in the PO Debit Memo Notification workflow, and you can modify it as your business needs require.

Notifications

You cannot modify the notification in the PO Debit Memo Notification workflow. (You could remove it and replace it with your own.)

Messages

You can modify any of the messages in the PO Debit Memo Notification workflow, as your business needs require.

See: Message Result, Oracle Workflow Developer's Guide and To Create a Message, Oracle Workflow Developer's Guide.

The PO Debit Memo Notification Item Type

The notification sending process is associated with an item type called PO Debit Memo Notification. This item type identifies all notification workflow processes available. There is one workflow process associated with PO Debit Memo Notification: Debit Memo.

The PO Debit Memo Notification item type also has 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 Debit Memo Notification Item Type Attributes

Display Name Description Type Length/ Format/ Lookup Type
Debit Memo Message1 First part of the notification text, up until the receipt number is mentioned (the message text is divided into four messages for translation purposes) Text 100
Debit Memo Message2 The part of the notification text just before the purchase order number is mentioned Text 100
Debit Memo Message3 Main body of the notification text Text 1000
Debit Memo Message 4 The part of the notification text that mentions the returned quantity Text 100
Debitmemo Notification Title Notification title, "Automatic Debit Memo Creation Failed" Text 2000
PO Number Number of the purchase order against which the debit memo is created Text 20
Quantity Returned quantity for which the debit memo is created Text 20
Receipt Number Number of the receipt against which the debit memo is created Text 20
User Display Name Buyer's name as displayed in Purchasing Text 240
User Name Buyer's user name as set up in Oracle Applications Text 100

Summary of the Debit Memo Process

To view the properties of the Debit Memo process, select the process in the navigator tree, then choose Properties from the Edit menu. The Debit Memo process has a result type of None, indicating that when the process completes, it doesn't end with any particular result, such as End (Approved) or End (Rejected).

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

The workflow begins at node 1. It sends a notification to the buyer at node 2 if the debit memo could not be created-for example, if an invoice does not yet exist against which to create the debit memo, or if the invoice program that creates the memos failed. This includes notifications for debit memos that were not created because Payment on Receipt already accounted for the return using the Aging Period functionality. The notification instructs the buyer to contact the Accounts Payables department to create a debit memo manually.

Process Navigator Workflows

The Processes tab in the Oracle Purchasing Navigator, in the Purchasing application, allows access to the process navigator workflows. These Workflow-enabled diagrams guide you through the following procurement processes from beginning to end by automatically launching the appropriate windows:

These processes are the default navigator workflow processes that come with Purchasing.

Accessing the Navigator Processes in Purchasing

The Processes tab in the Purchasing application allows access to the process navigator workflows.

See also: Using the Navigator's Process Region, Oracle Applications User's Guide.

To use the process navigator workflows in Purchasing:

  1. In the Processes tab of the Purchasing Navigator in the Purchasing application, select any process.

  2. Select any activity in the process to display additional information about it.

  3. Double-click each activity to launch the appropriate window and guide yourself through the process.

    A few activities require other products to be installed. For example, the activity Create and Approve Requisition in the Procure-to-Pay process launches Oracle iProcurement if it is installed.

Accessing the Workflows in the Workflow Builder

You can also view these processes in the Oracle Workflow Builder. In the Workflow Builder, the procurement navigator processes are associated with an item type called Procurement Processes.

You should not change your access level to modify a locked process; however, you can use the default procurement navigator processes as examples to create your own processes for the Process Navigator. For more information, see: Administering Process Navigation, Oracle E-Business Suite Maintenance Guide.

PO Approval Error Workflow

When a purchasing document is submitted for approval, the Approval Workflow starts the approval process for that document. The Approval Workflow process moves the document from one sub-process to another, making various checks on the document.

The Document Approval Manager is a concurrent manager that executes the code needed to perform these various checks called by the Approval Workflow. This concurrent manager needs to be Active for the Approval Workflow process to complete successfully. The Document Approval Manager is setup and maintained like any other concurrent manager by the System Administrator. The figure below demonstrates the flow of the document during the approval process.

the picture is described in the document text

Since the Document Approval Manager is required for the Approval Workflow process to complete successfully, if the Document Approval Manager fails, times out, or is not active, the Approval Workflow process also errors and halts without resetting the status of the document being processed. This causes the document to remain in 'In Process' status and are inaccessible to the Oracle Purchasing application. The Document Approval Manager returns three error codes. These are explained in the table below.

Document Approval Manager Errors
Error Number Description
1 Document Approval Manager timed out.
This error occurs when the Approval Workflow process has been waiting for the Document Approval Manager for more than 180 seconds to finish execution and return a result to the PO/Req Approval Workflow.
2 Document Approval Manager is not Active.
3 Exception in the Document Approval Manager code.
Any other Document Approval Manager failure other than a Timeout (Error 1) or Not Active (Error 2) results in this Document Approval Manager Error 3 code. When this error occurs, the Document Approval Manager provides more details about the exact code error in an error message. Approval workflow then sets the value of attribute SYSADMIN_ERROR_MSG to this message.

Whenever one of the above errors occurs, the document that the Workflow is processing remains in status 'In Process'. PO Approval Error workflow can be configured to resubmit documents automatically that failed due to Document Approval Manager Errors 1 or 2. For Document Approval Manager Error 3 a notification is sent that allows the System Administrator to retry the document approval directly from the notification.

Customizing the PO Approval Error Workflow

Use the Oracle Workflow Builder to customize workflows. For the PO Approval Error workflow this is the set up. When you customize a workflow, only those documents that are created after you customize it are affected by the customized workflow.

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, Oracle Workflow Developer's Guide.

    The Display name of the workflow is PO Approval Error. Its internal name, viewable through the Workflow Builder, is POERROR. The name of its Workflow definition file is poxwfpoe.wft.

    the picture is described in the document text

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

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

Creating a New Custom Process

If you want to customize the PO Approval Error workflow, you must customize the default (original) workflow that Purchasing provides. Unlike the PO Approval, PO Requisition Approval, and PO Create Documents workflows in Purchasing, only one PO Approval Error workflow can be called from the application itself. You can't select a separate customization, like you can with the other workflows in the Document Types window. Therefore, you need to make your customizations to the default workflow. Create a backup to revert to, if you need, while you are testing your customizations.

Required Modifications

There are no required modifications you need to make to the PO Approval Error workflow.

Supported and Unsupported Customizations

Following is a discussion of what you can and definitely cannot modify in the PO Approval Error 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 following sections, The PO Approval Error Item Type and Summary of the PO Approval Error Process. These sections describe the components of the notification process in the workflow. If you haven't already, see also: Customization Guidelines.

Important: If a particular Workflow object does not appear in the following sections on the lists of things you can customize, do not modify it, regardless of its access level.

Attributes

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

Processes

There is one process, "PO Approval Error," in the PO Approval Error workflow, and you can modify it as your business needs require.

Notifications

You cannot modify the notification in the PO Approval Error workflow. (You could remove it and replace it with your own.)

Messages

You can modify any of the messages in the PO Approval Error workflow, as your business needs require.

See: Message Result, Oracle Workflow Developer's Guide and To Create a Message, Oracle Workflow Developer's Guide.

The PO Approval Error Item Type

PO Approval Error Item Type Attributes

Display Name Description Type Length/ Format/ Lookup Type
Timeout Value Length of time, in minutes, for the notification to automatically close itself.
Default value is 0.		 Number  
Relative Time of Auto Entry for Document Manager Length of time, in minutes, processes will have to wait before getting picked again.
Default value is 0.		 Number  
Auto Retry Count for Document Manager Number of attempts to get document manager for approval.
Default value is 0.		 Number  
System Administrator User Name Application user (typically the System Administrator) who will receive notifications for document manager-related errors in status 1 and 2.
This must be defined manually as a valid UserID name in the system.		 Text 30

Summary of PO Approval Error Workflow

Once the document is submitted for approval, the Approval Workflow is launched and the various activities of the workflow are executed. Typically a PO Approval workflow activity makes a call to the Document Approval Manager and the Document Approval Manager returns an error causing this activity to fail. As soon as an activity fails due to Document Approval Manager Error, workflow will spawn another process for the PO Approval Error (POERROR) item type.

This new spawned POERROR process submits the document for approval only if the Document Approval Manager errors. The value of the POERROR workflow item attribute RETRY_COUNT determines the number of times this process will try to process the document. If at the end of all the attempts, the document is still in error, a notification is sent to the user name specified for the POERROR Workflow item attribute SYSADMIN_USER_NAME.

The notification sent to SYSADMIN_USER_NAME has an option of Retry, to allow the System Administrator to resubmit the document for approval after taking corrective action. If no action is taken on this notification, the notification times out based on the value defined by the attribute TIMEOUT_VALUE. If the notification is timed out, the document is submitted for approval once again. When the document is submitted for approval in this manner and fails again due to Document Approval Manager Error, the entire process is repeated.

Limitations