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.
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.
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. See also: Message Result and To Create a Message.
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 |
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.
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.
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.
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.
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.
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.