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.
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 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.
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.
Attention: 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 and To Create a Message.
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 |
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.
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.
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.