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 and Allowing Access to an Object.
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.
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.
Attention: 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.