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:
PO Account Generator workflow for automatically generating accrual, budget, charge, and variance accounts on purchase orders and releases. See: Using the Account Generator in Oracle Purchasing.
PO Requisition Account Generator workflow for automatically generating accrual, budget, charge, and variance accounts on requisitions. See: Using the Account Generator in Oracle Purchasing.
PO Requisition Approval workflow for approving requisitions. See: Requisition Approval Workflow.
PO Approval workflow for approving purchase orders. See: Purchase Order Approval Workflow.
Change Order workflow for controlling which changes to purchase orders require a manual reapproval and which are automatically reapproved; the change order workflow is really a group of workflow processes contained in the PO Approval workflow. Workflow Processes for Approving Change Orders.
PO Create Documents workflow for automatically creating purchase orders and releases. See: Workflow for Creating Purchase Orders and Releases.
PO Confirm Receipts workflow for sending receipt notifications to requesters or buyers notifying them that they should have received their order. Confirm Receipts Workflow.
PO Send Notifications for Purchasing Documents workflow for looking for documents that are incomplete, rejected, or in need of reapproval, and sending notifications to the appropriate people of the document's status. See: Send Notifications Workflow.
PO Catalog Price Tolerance Exceeded Notifications workflow for sending a notification to the buyer when the price/sales catalog information sent through the Purchasing Documents Open Interface includes price increases that exceed a price tolerance that you set. Price/Sales Catalog Notification Workflow.
Procurement Processes workflow for guiding you through procurement processes by launching the appropriate windows in Purchasing. See: Process Navigator Workflows.
PO Approval Error workflow for troubleshooting errors that occur when using the PO Approval workflow. See: PO Approval Error Workflow
Related Topics
Following are some of the important guidelines you should follow when customizing any workflow in Purchasing.
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.
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.
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.
You can use the Workflow Monitor to monitor a workflow's progress. See: Overview of Workflow Monitoring, Oracle Workflow User's Guide.
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.
You can modify only the attributes listed as customizable in the documentation for each Purchasing workflow.
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:
Attributes that are set by default function activities in the default processes must also be set if you replace the default function activities with ones of your own. If a function activity uses a SetItemAttr statement, then that function activity is setting an attribute to be used by another function activity later. Therefore, your new function activity must do the same. You should also preserve SetItemUserKey and SetItemOwner statements, if any. (Depending on your customizations, you may also want to preserve GetItemAttr statements.)
Any database state maintained by the default process must also be maintained by the processes you customize. If a function activity in a process uses an Update or Insert Into statement, then that function activity is updating or inserting rows in the database. Therefore, your new function activity must maintain the same database state.
To get a list of the workflow function activities that use SetItemAttr, GetItemAttr, SetItemUserKey, SetItemOwner, Insert Into, or Update statements, run the PL/SQL script powfcust.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:
Change to the directory where the PL/SQL-stored procedures are kept:
cd $PO_TOP/sql
At the SQL prompt, start the following script:
@powfcust.sql
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.
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.
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:
The result type of your new function activity must match the result type of the default activity. That is, the Result Type of the function activity in the Workflow Builder-for example, a Result Type of Yes/No-needs to match the result type that you specify in that function activity's corresponding PL/SQL procedure. In addition, if you have, for example, two results (such as Yes and No) in your function activity and corresponding PL/SQL procedure, make sure that there are two corresponding transitions in the workflow diagram (one for Yes and one for No). If you alter the result types and transitions in a process, be careful that you aren't deleting or bypassing any special transitions or checks.
Just as in the section Processes above, any attributes that were set by the default function activity must also be set by your customized function activity.
Just as in the section Processes above, any database state maintained by the default function activity must also be maintained by the customized function activity.
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
Workflow Processes for Approving Change Orders
Workflow for Creating Purchase Orders and Releases
Price/Sales Catalog Notification Workflow
Using the Workflow Monitor for the Account Generator
Using the Workflow Monitor for the PO Create Documents Workflow
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:
Improve accuracy and speed document generation by automatically constructing accounting distributions.
Relieve buyers, requestors, and document preparers from the responsibility of specifying which accounts should be charged for their purchases.
Customize Account Generator account construction rules to match your business rules.
For public sector installations, perform fund accounting.
See also: Overview of Account Generator, Oracle Applications Flexfields Guide.
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.
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:
Use the default Account Generator processes:
Generate Default Accrual Account
Generate Default Budget Account
Generate Default Charge Account
Generate Default Variance Account
Generate Default Destination Charge Account
Generate Default Destination Variance Account
Customize the default Account Generator processes
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.
Define your Accounting Flexfield structure for each ledger.
Define flexfield segment values and validation rules.
Set up Oracle Workflow.
Choose whether you want to use the default Account Generator processes, or if you need to customize them to meet your accounting needs.
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
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 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.
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 |
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 |
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 |
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 |
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 |
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.
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:
Charge
Budget
Accrual
Variance
Destination Charge
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.
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
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:
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.
Expand the data source, then the Account Generator item type branch within that data source.
Expand the Processes branch within the Account Generator branch, then double-click on a process activity to display its diagram.
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.
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.
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.
You cannot modify any attributes in the PO Account Generator or the PO Requisition Account Generator.
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:
Attributes that are set by default function activities in the default processes must also be set if you replace default function activities with ones of your own. That is, if a function activity in that process uses a SetItemAttr statement, then that function activity is setting an attribute to be used by another function activity later. Therefore, your new function activity must do the same. You should also preserve SetItemUserKey and SetItemOwner statements, if any. Depending on your customizations, you may also want to preserve GetItemAttr statements.
Any database state maintained by the default processes must also be maintained by processes you customize. That is, if a function activity in that process uses an Update or Insert Into statement, then that function activity is updating or inserting rows in the database. Therefore, your new function activity must maintain the same database state.
To get a list of the workflow function activities that use SetItemAttr, GetItemAttr, SetItemUserKey, SetItemOwner, Insert Into, or Update statements, run the PL/SQL script powfcust. For instructions on running this script, see: Customization Guidelines.
You can modify the following processes in both the PO Account Generator and the PO Requisition Account Generator, as your business needs require:
Generate Default Accrual Account
Generate Default Budget Account
Generate Default Charge Account
Generate Default Variance Account
Build Expense Charge Account
Build Inventory Budget Account
Build Inventory Charge Account
Build Expense Project Accrual Account
Build Expense Project Budget Account
Build Expense Project Charge Account
Build Expense Project Variance Account
Build Shop Floor Charge Account
Get Charge Account for Variance Account
Get Variance Account from Organization
You cannot modify the following processes in the PO Account Generator or the PO Requisition Account Generator:
Generate Default Accounts
Generate Accounts Using FlexBuilder Rules
Generate Charge Account Using FlexBuilder Rules
Generate Budget Account Using FlexBuilder Rules
Generate Accrual Account Using FlexBuilder Rules
Generate Variance Account Using FlexBuilder Rules
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:
The result type of your new function activity must match the result type of the default activity. That is, the Result Type of the function activity in the Workflow Builder needs to match the result type specified by that function activity's corresponding PL/SQL procedure-for example, a Result Type of Yes/No. It also means that if you have, for example, two results (such as Yes and No) in your function activity and corresponding PL/SQL procedure, make sure that there are two corresponding transitions in the workflow diagram (one for Yes and one for No). If you alter the result types and transitions in a process, be careful that you aren't deleting or bypassing any special transitions or checks.
Just as with Processes above, any attributes that were set by the default function activity must also be set by your customized function activity.
Just as with Processes above, any database state maintained by the default function activity must also be maintained by the customized function activity.
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:
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.
Drag and drop the Set Encoded Error Message function activity into the process diagram of the process you want to modify.
Select the activity in the process diagram and choose Properties from the Edit menu.
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.
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:
PO Work Item Destination Type
PO WIP Type
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.
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.
Navigate to the Account Generator Processes window by switching to the System Administrator responsibility and choosing Application > Flexfield > Key > Accounts.
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.
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
Oracle Purchasing comes with the following Account Generator workflow item types-the first for purchase orders and releases, and the second for requisitions:
PO Account Generator
PO Requisition Account
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.
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 |
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.
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.
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.
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.
This function activity gets the accrual account for the expense item.
This function activity gets the accrual account for inventory and shop floor items from the organization.
This function activity gets the appropriate charge account for inventory items based on whether the item is an expense or asset item.
This function activity gets the charge expense account for expense items.
This function activity gets the budget account for inventory items from the subinventory.
This function activity gets the charge account.
This function activity gets the budget account for inventory items from the item.
This function activity gets the budget account for inventory items from the organization.
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.
This function activity checks if encumbrance accounting is being used.
For an outside processing job, this function activity gets the charge account based on the resource cost element associated with the job.
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.
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.
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.
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.
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.
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.
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.
In the PO Account Generator, this function activity checks if the purchase order item is for a project in Oracle Projects.
In the PO Requisition Account Generator, this function activity checks if the requisition item is for a project in Oracle Projects.
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.
For an outside processing schedule, this function activity gets the charge account based on the resource cost element associated with the schedule.
For shop floor items, this function activity checks if the outside processing type is Job or Schedule.
This function activity gets the variance account for inventory and shop floor items from the organization.
This function activity checks if the destination type of the item is Inventory, Shop Floor, or Expense.
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.
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.
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.
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:
If so, node 12 uses the function attribute Generate Code Combination ID to generate the complete code combination identifier (CCID).
If not, node 11 uses the function attribute Validate Segment With Values Only to validate just those segments that were provided.
Nodes 6, 10, 11, and 12 are standard flexfield workflow activities. See: Standard Flexfield Workflow, Oracle Applications Flexfields Guide.
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.
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.
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.
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.
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.
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:
Build Expense Project Accrual Account
Build Expense Project Budget Account
Build Expense Project Charge Account
Build Expense Project Variance Account
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:
Replace Requisition Project-Related? (or PO Project-Related?) with your own function activity that branches to Build Project Account subprocess if a document has a Project ID.
Customize the appropriate Build Project Account subprocess. In the example above, you would customize the Build Expense Project Charge Account subprocess. If you wanted to use your project-related account for all accounts-accrual, budget, charge, and variance-you would customize all four of the Build Project Account subprocesses.
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.
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.
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.
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:
(Node 3) Generate Charge Account Using FlexBuilder Rules replicates your charge account FlexBuilder rules in the Account Generator.
(Node 8) Generate Budget Account Using FlexBuilder Rules replicates your budget account FlexBuilder rules in the Account Generator (if the activity at node 7 finds that the item is under budgetary control).
(Node 11) Generate Accrual Account Using FlexBuilder Rules replicates your accrual account FlexBuilder rules in the Account Generator.
(Node 13) Generate Variance Account Using FlexBuilder Rules replicates your variance account FlexBuilder rules in the Account Generator.
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.
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:
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.
Select the down-arrow box to the right of the Block field.
In the list of values that appears, choose PARAMETER and choose OK.
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.
Whenever you submit a requisition for approval or take an action in the Notifications Summary window, Purchasing uses Oracle Workflow technology in the background to handle the approval process. Workflow uses the approval controls and hierarchies you define according to the setup steps in the section Setting Up Document Approval and Security to route documents for approval. You can use the Workflow Builder to modify your approval process.
The requisition approval workflow consists of processes, which are viewable in the Workflow Builder as a diagram, some of whose objects and properties you can modify. Each workflow process, in turn, consists of individual function activities.
The PO Requisition Approval workflow is initiated at the following points in Purchasing:
When you choose Submit for Approval (and then choose OK) in the Approve Document window in Purchasing or submit a requisition for approval in Oracle iProcurement.
When you respond to a reminder in the Notifications Summary window reminding you to submit a document for approval that has not yet been submitted.
When you run Requisition Import. If the requisitions are incomplete or preapproved, Requisition Import launches the PO Requisition Approval workflow to approve the requisitions, unless you specify not to.
For information on the purchase order approval workflow, see: Purchase Order Approval Workflow.
Use the Oracle Workflow Builder to customize workflows. When you customize a workflow, only those documents that are submitted for approval after you customize it are affected by the customized workflow.
You can also use the Workflow Builder to create unique approval workflows for each document type in your organization. You associate particular workflows with certain document types in the Document Types window. See: Defining Document Types.
You can use the Workflow Monitor to follow where certain documents are in a workflow process. See: Monitoring Workflow Processes, Oracle Workflow User's Guide.
To display the workflow in the Oracle Workflow Builder:
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.
Expand the data source, then the PO Requisition Approval item type branch within that data source.
Expand the Processes branch within the PO Requisition Approval branch, then double-click on a process activity to display its diagram.
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.
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.
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.
You can modify the following attribute only, by changing its Default Value:
Send PO Autocreate to Background
Its Default Value is Y for Yes, to send automatic document creation to Background mode, but you can change it to N for No, to operate in Online mode. See: Choosing Workflow Options.
If you modify a process, it is essential that the basic flow remain intact to maintain data integrity in the database. For example, you should not remove or bypass the function activity Is Document Complete? in the Verify Requisition subprocess because this may allow incomplete data to be inserted into the database tables. However, you could add additional checks (processes or function activities) before allowing data to be inserted into the tables.
If you modify any process, either by replacing a portion of its flow or by adding additional function activities, remember the following:
Attributes that are set by default function activities in the default processes must also be set if you replace default function activities with ones of your own. That is, if a function activity in that process uses a SetItemAttr statement, then that function activity is setting an attribute to be used by another function activity later. Therefore, your new function activity must do the same. You should also preserve SetItemUserKey and SetItemOwner statements, if any. (Depending on your customizations, you may also want to preserve GetItemAttr statements.)
Any database state maintained by the default processes must also be maintained by processes you customize. That is, if a function activity in that process uses an Update or Insert Into statement, then that function activity is updating or inserting rows in the database. Therefore, your new function activity must maintain the same database state.
To get a list of the workflow function activities that use SetItemAttr, GetItemAttr, SetItemUserKey, SetItemOwner, Insert Into, or Update statements, run the PL/SQL script powfcust. For instructions on running this script, see: Customization Guidelines.
The process listed below may be modified as your business processes require; however, remember that after your customizations, the attributes that were set and the database states that were maintained by the default process must also be set or maintained by your customized process.
Print Document Process
You may add your own additional function activities to the processes listed below, but do not remove any default function activities from them:
Approve Requisition
Reject Requisition
Reserve at the Start
Reserve Before Approve
Return Requisition to Submitter
Verify Approval Authority
Verify Approval Authority for Approve Action
Verify Approval Authority for Approve and Forward Action
Verify Requisition
Approval List Routing
Main Requisition Approval
Notify Approver
Response with Approve Action
Response with Approve and Forward Action
Response with Forward Action
Response with Reject Action
Reserve Before Approve
Start of Approve Requisition Process
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.
You cannot modify any functions in the PO Requisition Approval workflow.
However, you can replace some function activities with function activities of your own. When you replace a function activity, you are modifying the process in which it is contained. See the guidelines for customizing the PO Requisition Approval processes in the section Processes above.
If you substitute default function activities in a process with function activities that you create, you must remember the following:
The result type of your new function activity must match the result type of the default activity. That is, the Result Type of the function activity in the Workflow Builder needs to match the result type specified by that function activity's corresponding PL/SQL procedure-for example, a Result Type of Yes/No. It also means that if you have, for example, two results (such as Yes and No) in your function activity and corresponding PL/SQL procedure, you need to make sure that there are two corresponding transitions in the workflow diagram (one for Yes and one for No). If you alter the result types and transitions in a process, be careful that you aren't deleting or bypassing any special transitions or checks.
Just as with Processes above, any attributes that were set by the default function activity must also be set by your customized function activity.
Just as with Processes above, any database state maintained by the default function activity must also be maintained by the customized function activity.
All of the messages can be modified to meet your individual business needs.
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 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.
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 |
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:
Node 23 turns iProcurement information templates into attachments, if information templates were used in iProcurement. Note that the information template is created as a short text attachment if the size of the attachment does not exceed 4000 bytes. If the size of the attachment exceeds 4000 bytes, then the information template is created as a long text attachment.
Node 24 sends a notification to the document owner that the requisition was approved.
Node 25 prints the document if Print was selected when the requisition was submitted.
Node 26 looks to the item attribute Send PO Autocreation to Background, which sets the processing mode to Background (if the item attribute is set to Y) or Online (if the item attribute is set to N) specifically for automatic document creation. How this mode is set affects system performance. For definitions of Background and Online modes, see: Profile Options in Purchasing.
Node 28 automatically starts the PO Create Documents workflow, which creates purchase orders and releases from the approved requisition lines, if you've allowed this in the Purchasing setup. See: Choosing Workflow Options.
The following is a description of each activity in the Main Requisition Approval process.
See: Start of Approve Requisition Process.
See: Verify Requisition.
See: Reserve At The Start.
This activity checks if a requester in iProcurement created or modified an approval list.
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.
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.
See: Verify Approval Authority.
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.
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.
See: Approval List Routing.
See: Reject Requisition.
This activity sends a notification to the requester that the requisition has been rejected.
See: Return Requisition to Submitter .
If the requisition is forwarded, this activity rebuilds the approval list to include that forward-to person.
Approver A
Approver B
Approver C
A requester in iProcurement adds Approvers X and Y:
Approver A
Approver B
Approver C
Approver X
Approver Y
Approver C, however, forwards the document to Approver D, who is part of another branch in the hierarchy:
Approver D
Approver E
Approver F
The approval routing will then be as follows, assuming Approver D does not have final approval authority:
Approver A
Approver B
Approver C
Approver X
Approver Y
Approver D
Approver E
Approver F
See: Reserve Before Approve.
See: Approve Requisition.
This activity checks if the requisition was created through iProcurement.
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.
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.
See: Print Document Process.
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.
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.
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.)
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).
The following is a description of each activity in the Start of Approve Requisition Process, listed by the activity's display name.
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.
This function activity sets all initial values necessary to identify a unique requisition.
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.
This activity looks for an approval list created in iProcurement.
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.
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.
This function activity retrieves key values from the requisition header and lines, and assigns them to Workflow attributes.
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.
The following is a description of each activity in the Verify Requisition subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
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.
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.
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.
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.
This activity sends a notification to the requester that the document failed the state check. See: Document Status Checks.
This activity sends a notification to the requester that the document failed the correctness check. See: Document Submission Checks.
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.
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.
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.
The following is a description of each activity in the Reserve At The Start subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
This activity determines if the requisition was created through iProcurement.
This activity checks if the requisition sent through Requisition Import was created in Web Requisitions Release 11.
This function activity checks whether you are using encumbrance accounting, and whether the document is already reserved.
This activity tries to reserve funds for the document.
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.
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.
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.
The following is a description of each activity in the Verify Approval Authority subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
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.
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.
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.
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.)
The following is a description of each activity in the Approval List Routing subprocess, listed by the activity's display name.
This activity finds the first (or next) approver in the approval list.
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.
See: Notify Approver.
See: Response with Reject Action.
See: Response with Approve Action.
See: Response with Approve and Forward Action.
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.
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.
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.
The following is a description of each activity in the Reject Requisition subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
This activity sets a requisition to a Rejected status. It also reverses encumbrance if the document has been encumbered.
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.
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.
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.
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.
The following is a description of each activity in the Return Requisition to Submitter subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
This activity sets the requisition back to its status before it entered this process activity, if no approver was found.
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.
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.
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.
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.
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.
The following is a description of each activity in the Notify Approver subprocess, listed by the activity's display name.
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.
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.
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.
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.
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.
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.)
The following is a description of each activity in the Response with Approve Action subprocess, listed by the activity's display name.
This activity updates the Oracle internal approval list tables PO_APPROVAL_LIST_HEADERS and PO_APPROVAL_LIST_LINES with the approver's approval.
This activity records an Approve action action in the Action History window.
A requisition's status is set to Pre-Approved if any of the following has occurred:
It has already been approved by the appropriate individual, who also chose to forward it to yet another person for approval.
It has been authorized for approval but funds have not yet been reserved for it.
The document has been approved but the subprocess Approve Requisition or the subprocess Reserve Before Approve has not yet set its status to Approved.
This activity updates the document status only, not the action history.
This function activity checks if the purchase order has been pre-approved.
See: Verify Approval Authority for Approve Action.
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.
The following is a description of each activity in the Response with Approve and Forward Action subprocess, listed by the activity's display name.
This activity records an Approve and Forward action in the Action History window.
See: Verify Approval Authority for Approve and Approve/Forward Action.
A requisition's status is set to Pre-Approved if any of the following has occurred:
It has already been approved by the appropriate individual, who also chose to forward it to yet another person for approval.
It has been authorized for approval but funds have not yet been reserved for it.
The document has been approved but the subprocess Approve Requisition or Reserve Before Approve has not yet set its status to Approved.
This activity updates the document status only, not the action history.
This function activity checks if the requisition has been pre-approved.
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.
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.
The following is a description of each activity in the Response with Forward Action subprocess, listed by the activity's display name.
This activity updates the Oracle internal approval list tables PO_APPROVAL_LIST_HEADERS and PO_APPROVAL_LIST_LINES with the approver's forward action.
This activity records a Forward action in the Action History window.
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.
The following is a description of each activity in the Response with Reject Action subprocess, listed by the activity's display name.
This activity updates the Oracle internal approval list tables PO_APPROVAL_LIST_HEADERS and PO_APPROVAL_LIST_LINES with the approver's rejection.
This activity records a Reject action in the Action History window.
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.
Following is a description of each activity in the Reserve Before Approve subprocess, listed by the activity's display name.
This function activity checks whether you are using encumbrance accounting and whether the document is already reserved.
This activity tries to reserve funds for the document.
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.
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.
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.
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.
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.
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.
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.
The following is a description of each activity in the Approve Requisition subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
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.
Examples of document statuses that allow an approval action are Incomplete, In Process, and Pre-Approved.
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.
This activity sets the status of the requisition to Approved.
This function activity retrieves key values from the requisition header and lines, in case these have changed, and assigns them to Workflow attributes.
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.
This function activity sends a notification to the approver that the document failed the state check. See: Document Status Checks.
This function activity sends a notification to the approver that the document failed the correctness check. See: Document Submission Checks.
This function activity sets the requisition back to its original status, if the document has failed state or correctness checks.
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.
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.
The following is a description of each activity in the Print Document subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
This activity checks if Print was selected when the requisition was first submitted.
If Print was selected when the requisition was first submitted, this activity prints the document.
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.
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.
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.
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.
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.
Whenever you submit a purchase order or release for approval or take an action in the Notifications Summary window, Purchasing uses Oracle Workflow technology in the background to handle the approval process. Workflow uses the approval controls and hierarchies you define according to the setup steps in the section Setting Up Document Approval and Security to route documents for approval. You can use the Workflow Builder interface to modify your approval process.
The purchase order approval workflow consists of processes, which are viewable in the Workflow Builder as a diagram, some of whose objects and properties you can modify. Each workflow process, in turn, consists of individual function activities.
The PO Approval workflow is initiated at the following points in Purchasing:
When you choose Submit for Approval (and then choose OK) in the Approve Document window. See: Submitting a Document for Approval.
When you respond to a reminder in the Notifications Summary window reminding you to submit a document for approval that has not yet been submitted.
For information on the requisition approval workflow, see: Requisition Approval Workflow.
Use the Oracle Workflow Builder to customize workflows. When you customize a workflow, only those documents that are submitted for approval after you have customized it are affected by the customized workflow.
You can also use the Workflow Builder to create unique approval workflows for each document type in your organization. You associate particular workflows with certain document types in the Document Types window. See: Defining Document Types.
You can use the Workflow Monitor to follow where certain documents are in a workflow process. See: Overview of Workflow Monitoring, Oracle Workflow User's Guide.
To display the workflow in the Oracle Workflow Builder:
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.
Expand the data source, then the PO Approval item type branch within that data source.
Expand the Processes branch within the PO Approval branch, then double-click a process activity to display its diagram.
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.
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.
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.
You can modify the following attributes only, by changing their Default Value:
Change Order Header Blanket Total Tolerance
Change Order Header Amount Limit Tolerance
Change Order Header Purchase Order Total Tolerance
Change Order Line Quantity Tolerance
Change Order Line Unit Price Tolerance
Change Order Line Quantity Committed Tolerance
Change Order Line Agreed Amount Tolerance
Change Order Line Price Limit Tolerance
Change Order Shipment Price Override Tolerance
Change Order Shipment Quantity Tolerance
Change Order Distribution Quantity Ordered Tolerance
For information about how to modify these attributes, see: Workflow Processes for Approving Change Orders.
If you modify a process, it is essential that the basic flow remain intact to maintain data integrity in the database. For example, you should not remove or bypass the function activity Is Document Complete? in the Verify PO subprocess because this may allow incomplete data to be inserted into the database tables. However, you could add additional checks (processes or function activities) before allowing data to be inserted into the tables.
If you modify any process, either by replacing a portion of its flow or by adding additional function activities, remember the following:
Attributes that are set by default function activities in the default processes must also be set if you replace default function activities with ones of your own. That is, if a function activity in that process uses a SetItemAttr statement, then that function activity is setting an attribute to be used by another function activity later. Therefore, your new function activity must do the same. You should also preserve SetItemUserKey and SetItemOwner statements, if any. (Depending on your customizations, you may also want to preserve GetItemAttr statements.)
Any database state maintained by the default processes must also be maintained by processes you customize. That is, if a function activity in that process uses an Update or Insert Into statement, then that function activity is updating or inserting rows in the database. Therefore, your new function activity must maintain the same database state.
To get a list of the workflow function activities that use SetItemAttr, GetItemAttr, SetItemUserKey, SetItemOwner, Insert Into, or Update statements, run the PL/SQL script powfcust. For instructions on running this script, see: Customization Guidelines.
The processes listed below may be modified as your business processes require; however, remember that after your customizations, the attributes that were set and the database states that were maintained by the default process must also be set or maintained by your customized process:
Do Document Changes Require Reapproval?
Find Approver
Get All Blanket PO Changes
Get All Contract PO Changes
Get All Planned PO Changes
Get All Release Changes
Get All Standard PO Changes
Notify Approver
Print Document Process
Print Document Process (Change Order)
Fax Document Process
Fax Document Process (Change Order)
You may add your own additional function activities to the processes listed below, but do not remove any default function activities from them:
Approve and Forward PO
Approve PO
Approve PO (Change Order)
Change Order Reserve Before Approve
Forward PO
Get All Document Changes
PO Approval Process
PO Approval Top Process
Reject PO
Reserve Before Approve
Return PO to Submitter
Verify Approval Authority
Verify PO
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.
You cannot modify any function activities in the PO Approval workflow.
However, you can replace some function activities with function activities of your own. When you replace a function activity, you are modifying the process in which it is contained. See the guidelines for customizing the PO Approval processes in the section Processes above.
If you substitute default function activities in a process with function activities that you create, you must remember the following:
The result type of your new function activity must match the result type of the default activity. That is, the Result Type of function activity in the Workflow Builder-for example, a Result Type of Yes/No-needs to match the result type that you specify in that function activity's corresponding PL/SQL procedure. It also means that if you have, for example, two results (such as Yes and No) in your function activity and corresponding PL/SQL procedure, you need to make sure that there are two corresponding transitions in the workflow diagram (one for Yes and one for No). If you alter the result types and transitions in a process, be careful that you aren't deleting or bypassing any special transitions or checks.
Just as in the section Processes above, any attributes that were set by the default function activity must also be set by your customized function activity.
Just as in the section Processes above, any database state maintained by the default function activity must also be maintained by the customized function activity.
All of the messages can be modified to meet your individual business needs.
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 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:
Approve PO (Change Order) *
Change Order Reserve Before Approve *
Do Document Changes Require Reapproval? *
Get All Blanket PO Changes *
Get All Contract PO Changes *
Get All Document Changes *
Get All Planned PO Changes *
Get All Release Changes *
Get All Standard PO Changes *
Print Document Process (Change Order) *
Fax Document Process (Change Order) *
* 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.
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 |
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.
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.
This is a Standard function activity that simply marks the start of the process.
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.
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.
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.
When you submit a purchase order for approval, its status changes to In Process.
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.
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.
This function activity retrieves key values from the purchase order header and lines, and assigns them to Workflow attributes.
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.
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.
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.
See: PO Approval Process.
See: Get All Document Changes.
See: Do Document Changes Require Reapproval?.
See: Change Order Reserve Before Approve.
See: Approve PO (Change Order).
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.
See: Print, Fax, and Email Document Processes.
See: Print, Fax, and Email Document Processes.
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).
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.
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.
This notification activity does not appear in any process diagram, but is used by the workflow in case an internal, PL/SQL error occurs when a function activity performs. If such an error occurs, this notification activity sends a notification to the document owner or approver that a Workflow error has occurred.
The PO AME Approval Top Process is available in the PO Approval workflow item type. The AME feature for PO review, approval, and multiple e-signatures uses this workflow process. Purchasing administrator must select this workflow for a document style in the Document Controls region. See: Using AME for Purchase Order Review, Approval, and Multiple E-Signatures
The following is a description of each activity in the PO AME Approval Top Process listed by the activity's display name. You can create all the components for an activity in the graphical Workflow Builder except for the PL/SQL stored procedures that the function activities call. All function activities execute PL/SQL stored procedures which you must create and store in the Oracle RDBMS. The naming convention for the PL/SQL stored procedures is:
<PACKAGE>.<PROCEDURE>
<PACKAGE> is the name of the package that groups all of the procedures. <PROCEDURE> represents the name of the procedure.
To view the package and procedure names used by the PO Approval processes, view the Properties page for each function activity. For example, the function activity Remove All Notifications For This Document uses the <PACKAGE>.<PROCEDURE> name PO_REQAPPROVAL_INIT1.REMOVE_REMINDER.
You can use the Item Type Definitions Web page to view <PACKAGE>.<PROCEDURE> names. See: Item Type Definitions Web Page, Oracle Workflow Developer's Guide.
This is a Standard function activity that simply marks the start of the process.
This function performs the following activities:
removes previous notifications for a purchase order previously submitted to the workflow that was not completed because of an error or because of an action such as rejection.
Sets all initial values necessary to identify a unique purchase order, such as the preparer's user name and a forward-to user name.
Updates the document header with the item type and item key, which indicate that the purchase order has been submitted to the workflow.
When you submit a purchase order for approval, its status changes to In Process.
Retrieves the value from the profile option PO: Workflow Processing Mode, which lets you choose whether you want the approval process to run in Online or Background modes.
If the profile option PO: Workflow Processing Mode is set to Background, this function activity waits for the Workflow Background Engine to pick up this document for processing by the workflow. This activity enables you to proceed to your next Purchasing activity while the approval process for this document completes in the background.
Retrieves key values from the purchase order header and lines, and assigns them to Workflow attributes.
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.
This function performs the following activities:
Checks if the document is open (for example, not finally closed).
Checks if the document status is compatible with the approval action. Examples of document statuses that allow an approval action are Incomplete, In Process, and Pre-Approved.
Verifies that the purchase order is complete-for example, verifying that all the quantities match, and at least one line and one distribution exist.
Sends a notification to the document owner that the document failed the state check.
Sets the document back to its status before it entered this process activity, if the document has failed state or correctness checks.
Inserts a Submit Action row into the PO_ACTION_HISTORY table to record that the document has been submitted for approval. It also inserts an additional row with a null ACTION_CODE to simulate a forward-to action, since the document status is In Process. The document manager looks for this row.
This function performs the following activities:
Retrieves the list of approvers based on the AME rules. If there are no approvers, then verfies whether the document approval is complete or not. If the e-signature functionality is used, then the function ensures that the multiple e-signatures are done only after the entire approval process is complete. If the supplier signature is available, then the process routes the document for multiple e-signatures only after the supplier signature.
Launches the parallel approval process. The parallel approval process determines the Approver category using the APPROVER_CATEGORY attribute which is set while launching the parallel approval workflow. When the approver approves the document, the approver receives the approval notification. The function checks whether the approver forwards the document or not. If the forward is valid, then the Verify PO process runs or if the forward is invalid, the approver receives a message notification. It routes the document to reviewers. Based on the response of approvers and reviewers, the status of the document is set to the following actions: Reviewe Accepted, Review Rejected, Signed, Signer Rejected, and Approved and Forward. The function updates the AME process with the approval response.
Sends a reminder notification, in case of Timeout. The current no of reminder is tracked through workflow attribute NO_REMINDER which is initially set to 0. It is incremented in Reminder Process and notification is sent again. The maximum no of reminders is 3. Purchasing records the following reminder actions in the Action History: First Reminder, Second Reminder, Timed Out.
Generates PDF document for buyer and supplier, if print requests exist.
The document is printed for supplier only if the authorization status is Approved.
Sends notifications to FYI approver, if FYI approver is selected in the document Approval Options page.
This function handles the AME Exception case and sends Approval Error encountered notification.
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.
This function performs the following activities:
Checks whether encumbrance accounting is used.
Tries to reserve funds for the document.
Routes the reserved document for approval, if approvals are in place.
Sends notifications to preparer if Purchasing is unable to reserve the document
Routes the document to the Rejection process if the document is sent back to preparer.
This function performs the following activities:
Sends rejection notification to the preparer of the document.
Updates the status of the document to Rejected and records the rejection in the Action History window. It also reverses encumbrance if the document has been encumbered.
Deletes PDF attachments associated with the document.
This function performs the following activities:
Verifies the order documents by launching the Verify PO sub process
See:Verify PO
Deletes PDF attachments associated with the document.
Raises change event to check the document to see if XML is the chosen supplier transmission method. If true, it will raise an event that will cause the document to be sent by way of XML. Processing following this node takes two paths and workflow executes both of them in parallel. One path is to an end node to wait and the other links to a sub-process to automatically create sourcing rules and approved supplier lists (ASL).
This function performs the following activities:
Verifies whether the purchase order requires signature.
Manages the communication for purchase documents. If Print was selected in the Approve Document window when the purchase order was first submitted for approval. If Print was selected, prints the document. checks if Email was selected in the Approve Document window. If Email was selected, automatically sends an Email of the document if an Email Address was also entered in the Approve Document window. If Fax was selected, automatically sends a facsimile of the document if a Fax Number was also entered in the Approve Document window.
Checks the profile PO: Allow Auto-generate Sourcing Rules and ASL. If the profile is set to Yes and automatic sourcing rule generation was selected, either from Purchasing Document Import or by the user in the Approval window, this activity will return true and the Create SR and ASL sub-process will be invoked.
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.
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.
The following is a description of each activity in the PO Approval Process, listed by the node number from the above graphic.
This is a Standard function activity that simply marks the start of the process.
See: Verify PO.
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.
See: Verify Approval Authority.
This function activity checks if a forward-to person was provided in the Approve Document or Notifications Summary windows.
See: Approve And Forward PO.
See: Notify Approver.
See: Reserve Before Approve.
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.
See: Find Approver.
See: Return PO to Submitter.
This function activity checks if the user name of the approver found by the Find Approver activity is valid.
See: Forward PO.
See: Reject PO.
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.
See: Approve PO.
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.
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).
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.
This sub-process will generate the requested sourcing rules and ASL for all eligible lines in the blanket purchase agreement that is being approved.
See: Print, Fax, and Email Document Processes.
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.
See: Print, Fax, and Email Document Processes.
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.
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.
The following is a description of each activity in the Verify PO subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
This function activity checks if the document is open (for example, not finally closed).
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.
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.
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.
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.
This function activity sends a notification to the document owner that the document failed the state check. See: Document Status Checks.
This function activity sends a notification to the document owner that the document failed the correctness check. See: Document Submission Checks.
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.
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.
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.
The following is a description of each activity in the Reserve Before Approve subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
This function activity checks whether you are using encumbrance accounting, and whether the document is already reserved.
This function activity tries to reserve funds for the document.
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.
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.
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.
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.
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.
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.
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.
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.
The following is a description of each activity in the Verify Approval Authority subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
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.
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.
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.
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.
The following is a description of each activity in the Approve PO subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
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.
Examples of document statuses that allow an approval action are Incomplete, In Process, and Pre-Approved.
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.
This function activity sets the status of the purchase order to Approved.
This function activity retrieves key values from the purchase order header and lines, in case these have changed, and assigns them to Workflow attributes.
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.
This activity sends a notification to the approver that the document failed the state check. See: Document Status Checks.
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.
This activity sends a notification to the approver that Purchasing was unable to approve the document.
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.
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.
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.
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.
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.
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.
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.
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.
This is a Standard function activity that simply marks the start of the subprocess.
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.
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.
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.
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.
The following is a description of each activity in the Approve and Forward PO subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
Examples of document statuses that allow an approval action are Incomplete, In Process, and Pre-Approved.
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.
This function activity approves the purchase order and forwards it to the next approver.
This function activity retrieves key values from the purchase order header and lines, in case these have changed, and assigns them to Workflow attributes.
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.
This function activity sends a notification to the approver that the document failed the state check. See: Document Status Checks.
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.
This activity sends a notification to the approver that Purchasing was unable to approve the document because the document was incomplete.
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.
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.
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.
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.
The following is a description of each activity in the Notify Approver subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
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.
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.
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.
This function activity resets the Forward-To and Forward-From attributes after an Approve action.
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.
This function activity resets the Forward-To and Forward-From attributes after an Approve and Forward action.
This function activity resets the Forward-To and Forward-From attributes after a Forward action.
This function activity resets the Forward-To and Forward-From attributes after the previous activity times out (if a Timeout is associated with it).
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.
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:
Verify Approval Authority determines that the document owner does not have the authority to approve the document as defined in the Approval Groups and Assign Approval Groups windows. (See: Defining Approval Groups. See: Assigning Approval Groups.)
Can Owner Approve? finds that Owner Can Approve is not checked for the specific document type in the Document Types window. See: Defining Document Types.
The approver forwarded the document to another approver during the Notify Approver process, or didn't respond after a certain time, if the Timeout feature is set up.
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.
The following is a description of each activity in the Find Approver subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
This function activity checks whether the buyer or the approver provided a forward-to user name.
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.
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.
This function activity checks whether position hierarchies are being used in approvals. See: Setting Up Document Approval and Security.
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.
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.
This function activity verifies the approver's approval authority based on the authority limits defined in the Approval Groups and Assign Approval Groups windows.
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.
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.
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.
The following is a description of each activity in the Forward PO subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
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.
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.
If the purchase order status is Pre-Approved, this activity forwards the purchase order to the next approver without changing its status.
This function activity retrieves key values from the purchase order header and lines, in case these have changed, and assigns them to Workflow attributes.
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.
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.
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.
The following is a description of each activity in the Return PO to Submitter subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
This activity sets the purchase order back to its status before it entered this process activity, if no approver was found.
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.
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.
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.
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.
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.
The following is a description of each activity in the Reject PO subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
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.
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.
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.
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.
See: 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:
Changes to a purchase order cause its Status to change to 'Requires Reapproval.'
The document revision number of the purchase order increases.
You select Submit for Approval (and then choose OK) in the Approve Document window or otherwise submit the document for approval.
Related Topics
Purchase Order Approval Workflow
Use the Oracle Workflow Builder to customize workflows. When you customize a workflow, only those documents that are submitted for approval after you customize it are affected by the customized workflow.
You can 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:
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.
Expand the data source, then the PO Approval item type branch within that data source.
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.
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.
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.
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:
Change Order Header Blanket Total Tolerance
Change Order Header Amount Limit Tolerance
Change Order Header Purchase Order Total Tolerance
Change Order Line Quantity Tolerance
Change Order Line Unit Price Tolerance
Change Order Line Quantity Committed Tolerance
Change Order Line Agreed Amount Tolerance
Change Order Line Price Limit Tolerance
Change Order Shipment Price Override Tolerance
Change Order Shipment Quantity Tolerance
Change Order Distribution Quantity Ordered Tolerance
For 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:
In the Workflow Navigator, select one of the modifiable Change Order tolerance item attributes listed above.
Select the item attribute and open its Properties window.
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 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.
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 |
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 |
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 |
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 |
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 |
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 |
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.
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.
This is a Standard function activity that simply marks the start of the subprocess.
This function activity looks for the changed document's document type.
See: Get All Contract PO Changes.
See: Get All Blanket PO Changes.
See: Get All Planned PO Changes.
See: Get All Standard PO Changes.
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.
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.
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.
The following is a description of each activity in the Get All Blanket PO Changes subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
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.
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.
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.
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.)
The following is a description of each activity in the Get All Contract PO Changes subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
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.
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.
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.
The following is a description of each activity in the Get All Planned PO Changes subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
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.
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.
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.
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.
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.
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.
The following is a description of each activity in the Get All Release Changes subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
This function activity gathers all of the changes that occurred in the release header and updates the appropriate item attributes with the changes.
This function activity gathers all of the changes that occurred in the release shipments and updates the appropriate item attributes with the changes.
This function activity gathers all of the changes that occurred in the release distributions and updates the appropriate item attributes with the changes.
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.
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.
The following is a description of each activity in the Get All Standard PO Changes subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
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.
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.
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.
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.
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.
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.
The following is a description of each activity in the Do Document Changes Require Reapproval? subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
This function activity looks for the changed document's document type.
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.
This function activity does the same as the previous activity, for contract purchase orders.
This function activity does the same as the previous activity, for planned purchase orders.
This function activity does the same as the previous activity, for scheduled releases.
This function activity does the same as the previous activity, for standard purchase orders.
This function activity does the same as the previous activity, for blanket releases.
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.
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.
The following is a description of each activity in the Change Order Reserve Before Approve subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
This function activity determines whether you are using encumbrance accounting, and whether the document is reserved.
This function activity tries to reserve funds for the document.
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.
This activity notifies the document owner that Purchasing failed to reserve funds for the document, and provides instructions for resolving the failure.
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.
This function activity resets the Forward-To and Forward-From attributes after a Forward action.
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.
This activity sends a notification to the document owner that Purchasing was unable to properly reject the document.
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.
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.
The following is a description of each activity in the Approve PO subprocess, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
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.
Examples of document statuses that allow an approval action are Incomplete, In Process, and Pre-Approved.
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.
This function activity sets the status of the purchase order to Approved.
This function activity retrieves key values from the purchase order header and lines, in case these have changed, and assigns them to Workflow attributes.
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.
This activity sends a notification to the approver that the document failed the state check. See: Document Status Checks.
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.
This activity sends a notification to the approver that Purchasing was unable to approve the document.
This function activity updates the status of the document to Rejected and records the rejection in the Action History window.
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.
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.
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.
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.
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.
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.
This is a Standard function activity that simply marks the start of the subprocess.
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.
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.
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.
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.
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:
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.
Expand the data source, then the PO Create Documents item type branch within that data source.
Expand the Processes branch, then double-click a process activity to display its diagram.
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.
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.
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.
You can modify the following attributes only, by changing their Default Value:
Is Automatic Creation Allowed?
Is Automatic Approval Allowed?
Should Workflow Create the Release?
For information on modifying these item attributes' default values, see: Choosing Document Creation Options.
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:
Attributes that are set by default function activities in the default processes must also be set if you replace default function activities with ones of your own. That is, if a function activity in that process uses a SetItemAttr statement, then that function activity is setting an attribute to be used by another function activity later. Therefore, your new function activity must do the same. You should also preserve SetItemUserKey and SetItemOwner statements if any. Depending on your customizations, you may also want to preserve GetItemAttr statements.
Any database state maintained by the default processes must also be maintained by processes you customize. That is, if a function activity in that process uses an Update or Insert Into statement, then that function activity is updating or inserting rows in the database. Therefore, your new function activity must maintain the same database state.
To get a list of the workflow function activities that use SetItemAttr, GetItemAttr, SetItemUserKey, SetItemOwner, Insert Into, or Update statements, run the PL/SQL script powfcust. For instructions on running this script, see: Customization Guidelines.
You can modify all of the processes in PO Create Documents, taking into careful consideration the information described below for each:
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.
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.
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.
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.
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.
You can modify the following notifications in the PO Create Documents workflow, as your business needs require:
Purchase Order Or Release Has Been Created
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.
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:
The result type of your new function activity must match the result type of the default activity. That is, the Result Type of the function activity in the Workflow Builder needs to match the result type specified by that function activity's corresponding PL/SQL procedure-for example, a Result Type of Yes/No. It also means that if you have, for example, two results (such as Yes and No) in your function activity and corresponding PL/SQL procedure, you need to make sure that there are two corresponding transitions in the workflow diagram (one for Yes and one for No). If you change the result types and transitions in a process, be careful that you aren't deleting or bypassing any special transitions or checks.
Just as in the section Processes above, any attributes that were set by the default function activity must also be set by your customized function activity.
Just as in the section Processes above, any database state maintained by the default function activity must also be maintained by the customized function activity.
You can modify the message body of the following messages in the PO Create Documents workflow:
PO Document Created
You cannot modify any Lookup Types in the PO Create Documents workflow.
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.
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 |
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.
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.
This is a Standard function activity that simply marks the start of the subprocess.
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.
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.
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.
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.
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.
This function activity places all emergency requisition lines, which have the same Emergency PO Number, onto one purchase order.
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.
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.
This function activity marks the end of the 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:
If there is no release generation method, the workflow ends at Node 15.
If the release generation method is Automatic Release/Review or Automatic Release, the workflow ends at node 16 or 17 respectively; instead the document will be created automatically through the Create Releases process.
If the release generation method is Release Using AutoCreate, node 19 checks the item attribute Should Workflow Create the Release? to see how you set up Purchasing. If you left this item attribute set to Y for Yes, the workflow creates the release. Otherwise, it ends at node 18, and you can create the release through the AutoCreate Documents window.
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.
The following is a description of each activity in the Verify Req Line Information process, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
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.
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.
See: Does This Req Line Have Enough Information to Automatically Create a Document?.
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.
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.
This function activity checks for the source document type-blanket agreement or quotation-referenced on the requisition line.
This function activity checks for the type of item-one-time or predefined-used on the requisition line.
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.
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.
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.)
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.
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.
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.
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.
This is a Standard function activity that simply marks the start of the subprocess.
This function activity checks if a valid Supplier and Supplier Site exist for the requisition line.
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.
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.
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.
See: Get Buyer
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.
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.
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.
This is a Standard function activity that simply marks the start of the subprocess.
This function activity creates a standard purchase order or blanket release depending on the information on the requisition line.
If the document is created successfully, this function activity sends a notification to the buyer.
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.)
This function activity launches the PO Approval workflow. See: Purchase Order Approval Workflow
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.
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.
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.
The following is a description of each activity in the Get buyer process, listed by the activity's display name.
This is a Standard function activity that simply marks the start of the subprocess.
This function activity tries first to get the buyer from the requisition line.
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.
If Get Buyer From Item fails, this function activity tries to get the buyer assigned to the Category on the requisition line.
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.
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.
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:
Write down the requisition number of the requisition you're monitoring.
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.
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.
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.
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.
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:
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.
Expand the data source, then the PO Confirm Receipt item type branch within that data source.
Expand the Processes branch within the PO Confirm Receipt branch, then double-click on a process activity to display its diagram.
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.
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.
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:
Select any of the following notification activities in the Notify Requester process:
Notify Requestor of Confirm Receipt - initial notification
Notify Requestor of Confirm Receipt - first reminder
Notify Requestor of Confirm Receipt - second reminder
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.
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.
You cannot modify any item attributes in the PO Confirm Receipt workflow. However, you can add item attributes.
If you modify a process, it is essential that the basic flow remain intact to maintain data integrity in the database:
Attributes that are set by default function activities in the default processes must also be set if you replace default function activities with ones of your own. That is, if a function activity in that process uses a SetItemAttr statement, then that function activity is setting an attribute to be used by another function activity later. Therefore, your new function activity must do the same. You should also preserve SetItemUserKey and SetItemOwner statements, if any. (Depending on your customizations, you may also want to preserve GetItemAttr statements.)
Any database state maintained by the default processes must also be maintained by processes you customize. That is, if a function activity in that process uses an Update or Insert Into statement, then that function activity is updating or inserting rows in the database. Therefore, your new function activity must maintain the same database state.
To get a list of the workflow function activities that use SetItemAttr, GetItemAttr, SetItemUserKey, SetItemOwner, Insert Into, or Update statements, run the PL/SQL script powfcust. For instructions on running this script, see: Customization Guidelines.
You should not remove any default function activities from the following processes. You may, however, add your own additional function activities to them:
Confirm Receipt Process
Notify Requester
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.
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:
The result type of your new function activity must match the result type of the default activity. That is, the Result Type of the function activity in the Workflow Builder needs to match the result type specified by that function activity's corresponding PL/SQL procedure-for example, a Result Type of Yes/No. It also means that if you have, for example, two results (such as Yes and No) in your function activity and corresponding PL/SQL procedure, you need to make sure that there are two corresponding transitions in the workflow diagram (one for Yes and one for No). If you change the result types and transitions in a process, be careful that you aren't deleting or bypassing any special transitions or checks.
Just as with Processes above, any attributes that were set by the default function activity must also be set by your customized function activity.
Just as with Processes above, any database state maintained by the default function activity must also be maintained by the customized function activity.
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.
You cannot modify any of the PO Confirm Receipt lookup types.
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.
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 |
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
This activity ends the process.
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:
Notify Requestor of Confirm Receipt - initial notification (node 1) - 7 days
Notify Requestor of Confirm Receipt - first reminder (node 5) - 7 days
Notify Requestor of Confirm Receipt - second reminder (node 6) - 1 day
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.
The following is a description of each activity in the Notify Requester subprocess listed by the activity's display name.
This activity notifies the requester that the requester should have received the goods, and asks for confirmation.
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).
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.
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.
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.
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:
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.
Expand the data source, then the PO Send Notifications for Purchasing Documents item type branch within that data source.
Expand the Processes branch within PO Send Notifications for Purchasing Documents branch, then double-click on its process activity to display the process diagram.
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.
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.
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.
You cannot modify any of the attributes in the PO Send Notifications for Purchasing Documents workflow.
If you modify a process, it is essential that the basic flow remain intact to maintain data integrity in the database:
Attributes that are set by default function activities in the default processes must also be set if you replace default function activities with ones of your own. That is, if a function activity in that process uses a SetItemAttr statement, then that function activity is setting an attribute to be used by another function activity later. Therefore, your new function activity must do the same. You should also preserve SetItemUserKey and SetItemOwner statements, if any. (Depending on your customizations, you may also want to preserve GetItemAttr statements.)
Any database state maintained by the default processes must also be maintained by processes you customize. That is, if a function activity in that process uses an Update or Insert Into statement, then that function activity is updating or inserting rows in the database. Therefore, your new function activity must maintain the same database state.
To get a list of the workflow function activities that use SetItemAttr, GetItemAttr, SetItemUserKey, SetItemOwner, Insert Into, or Update statements, run the PL/SQL script powfcust. For instructions on running this script, see: Customization Guidelines.
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:
PO Document Approval Reminder
You cannot modify any of the notifications in the PO Send Notifications for Purchasing Documents workflow.
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:
The result type of your new function activity must match the result type of the default activity. That is, the Result Type of the function activity in the Workflow Builder needs to match the result type specified by that function activity's corresponding PL/SQL procedure-for example, a Result Type of Yes/No. It also means that if you have, for example, two results (such as Yes and No) in your function activity and corresponding PL/SQL procedure, you need to make sure that there are two corresponding transitions in the workflow diagram (one for Yes and one for No). If you change the result types and transitions in a process, be careful that you aren't deleting or bypassing any special transitions or checks.
Just as with Processes above, any attributes that were set by the default function activity must also be set by your customized function activity.
Just as with Processes above, any database state maintained by the default function activity must also be maintained by the customized function activity.
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.
You cannot modify any of the lookup types in the PO Send Notifications for Purchasing Documents workflow.
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.
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 |
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.
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.
This is a Standard function activity that simply marks the start of the process.
This function activity determines the document type: quotation, RFQ, requisition, purchase order, purchase agreement, release, or a purchase order or release that requires acceptance.
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.
This activity sends a notification to the document preparer that the quotation requires completion because its status is still In Process.
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.
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.
This activity sends a notification to the document preparer that the RFQ requires completion because its status is still In Process.
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.
If the Acceptance Require By date for the release indicates that acceptance is overdue, this activity sends a notification that acceptance is past due.
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.
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.
This activity sends a notification that the requisition requires approval because it is incomplete, rejected, or in need of reapproval.
This activity sends a notification that the purchase order requires approval because it is incomplete, rejected, or in need of reapproval.
This activity sends a notification that the release requires approval because it is incomplete, rejected, or in need of reapproval.
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.
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.
If the notification is answered with Approve, and the forward-to approver (if any) is valid, this function activity launches the appropriate approval workflow.
This function activity marks the end of the process.
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:
You can view the workflow in a Process window using the Workflow Builder.
To display the workflow in the Oracle Workflow Builder:
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.
Expand the data source, then the item type branch within that data source.
Expand the Processes branch, then double-click the Issue Notifications process activity to display its diagram.
There are no required modifications you need to make to this workflow.
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:
In the Workflow Builder, expand the Functions branch and select the Wait for Buyer Action from Exceeded Price Tolerances Form activity.
Open the activity's Properties window.
Change the Timeout to a period of time that best suits your organization's needs.
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:
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.
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.
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:
Attributes that are set by default function activities in the default processes must also be set if you replace default function activities with ones of your own. That is, if a function activity in that process uses a SetItemAttr statement, then that function activity is setting an attribute to be used by another function activity later. Therefore, your new function activity must do the same. You should also preserve SetItemUserKey and SetItemOwner statements, if any. (Depending on your customizations, you may also want to preserve GetItemAttr statements.)
Any database state maintained by the default processes must also be maintained by processes you customize. That is, if a function activity in that process uses an Update or Insert Into statement, then that function activity is updating or inserting rows in the database. Therefore, your new function activity must maintain the same database state.
To get a list of the workflow function activities that use SetItemAttr, GetItemAttr, SetItemUserKey, SetItemOwner, Insert Into, or Update statements, run the PL/SQL script powfcust. For instructions on running this script, see: Customization Guidelines.
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 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.
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.
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.
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.
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.
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.
This function activity determines if any price updates were rejected.
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.
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.
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.
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:
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.
Expand the data source, then the PO Debit Memo Notification item type branch within that data source.
Expand the Processes branch within the PO Debit Memo Notification branch, then double-click on its process activity to display the process diagram.
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.
There are no required modifications you need to make to the PO Debit Memo Notification workflow.
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.
You cannot modify any of the attributes in the PO Debit Memo Notification workflow.
There is one process, "Debit Memo," in the PO Debit Memo Notification workflow, and you can modify it as your business needs require.
You cannot modify the notification in the PO Debit Memo Notification workflow. (You could remove it and replace it with your own.)
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 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.
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 |
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.
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:
Procure-to-Pay, from creating a requisition and purchase order to transferring invoice and payment accounting information to the general ledger.
Sourcing, from using the Oracle Business Intelligence System to analyze commodities and suppliers to defining sourcing rules in Purchasing.
Define Sourcing, a subprocess of Sourcing, which describes how to define sourcing rules.
Purchase Order Creation, from creating the purchase order to modifying it and communicating it to the supplier.
Receiving, from receiving an Advance Shipment Notice from the supplier to delivering the goods.
These processes are the default navigator workflow processes that come with 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:
In the Processes tab of the Purchasing Navigator in the Purchasing application, select any process.
Select any activity in the process to display additional information about it.
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.
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.
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.
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.
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.
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:
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.
Expand the data source, then the PO Approval Error item type branch within that data source.
Expand the Processes branch within the PO Approval Error branch, then double-click on its process activity to display the process diagram.
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.
There are no required modifications you need to make to the PO Approval Error workflow.
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.
You can modify the following attributes only, by changing their Default Value:
Timeout Value
Relative Time of Auto Entry for Document Manager
Auto Retry Count for Document Manager
System Administrator User Name
There is one process, "PO Approval Error," in the PO Approval Error workflow, and you can modify it as your business needs require.
You cannot modify the notification in the PO Approval Error workflow. (You could remove it and replace it with your own.)
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.
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 |
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
The document is automatically submitted again for approval only when the Document Approval Manager fails with error number 1 (Timed Out) and error number 2 (Not Active).
When the Document Approval Manager fails with error number 3 (Unknown Error), a notification is sent to SYSADMIN_USER_NAME with a retry option. This document will not be automatically submitted again for approval and the notification sent will not time out. This will allow the System Administrator to communicate to the Users to correct the issue and allows the System Administrator to retry the document approval without having to access the database to use wfretry.sql.
When a document fails approval process due to a Generic or PL/SQL error, a FYI notification will be sent to SYSADMIN_USER_NAME. This document will not be automatically submitted again for approval and does not have a retry option.