Oracle iSupplier Portal Workflows
Chapter Overview
Oracle iSupplier Portal uses Oracle Workflow technology to provide a guided walk-through of business processes and to generate notifications. Oracle Workflow Builder is a graphical tool for creating, viewing, and modifying workflow process definitions. It contains a Navigator window that you use to define the activities in a process window to process a diagram.
For more information on Oracle Workflow, see Overview of Oracle Workflow in the Oracle Workflow Guide.
Oracle iSupplier Portal uses the following workflows:
-
Supplier Change Order Workflow
-
Update Capacity Workflow
-
Order Modifiers Workflow
-
Advance Shipment Notice (ASN) Workflow
-
Purchase Order Acknowledgement (handled by PO Approval Workflow)
Customizing Oracle iSupplier Portal Workflows
The Oracle Workflow Builder is used to customize workflows. When workflows are customized, only those business flows that are submitted after the customization are affected.
The Oracle Workflow Builder is also used to create unique approval workflows for each document type in your organization. Particular workflows are associated with certain document types in the Document Type window.
Notifications
All notifications can be modified to meet your individual business needs. However, if the notification has a reply code, you should verify that the Result Type of your customized notification matches the transitions in the workflow diagram.
For more information on creating notifications, see the Oracle Workflow Guide.
Function Activities
You cannot modify any function activity in the Oracle iSupplier Portal workflow. However, you can replace some function activities with function activities of your own. When your replace a function activity, you are modifying the process where it is contained. If you substitute default action 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. For example, a Result Type of Yes or No needs to match the result type that you specify in that function activity's corresponding PL/SQL procedure.
-
If you have two results (such as Yes and No) in your function activity and corresponding PL/SQL procedure, you need to verify 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 are not deleting or bypassing any special transitions or checks.
Messages
You can modify all of the messages to meet your individual business needs.
Lookup Types
You can modify all the lookup types to meet your individual business needs.
Note: If you change a lookup type, verify that all activities that use the lookup type allow 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.
For more information on Lookup Types see the Oracle Workflow Guide.
Supplier Change Order Workflow
The supplier change order workflow handles change requests made by the supplier and the buyer's response to those change requests, as well as implements the business rules pertaining to the supplier's change request and the buyer's response. A supplier can login to Oracle iSupplier Portal and can request for a change or do so through XML.
The supplier change order workflow supports changes on fields such as promised date, quantity ordered, unit price, supplier item, additional changes, split shipments, and acknowledgement of shipments. All change requests made by the supplier need to be approved or rejected by the buyer.
The supplier change order workflow processes the change request and sends a notification to the buyer about the supplier's intention to change the purchase order. Once the buyer responds to the purchase order, the response is processed. As part of processing the response, the workflow calls the appropriate procedures to update the existing purchase order and sends out the response notification to the supplier. All the notifications are generated dynamically according to the receiver's language preference.
Supplier Change Order Workflow
Supplier Change Order Workflow Main Process
In this process, the workflow receives a change request and sends a notification to the buyer.
Depending on the type of change requests, workflow decides if the change requires an approval or not. If the change is to the promised date, quantity, price, or shipment amount, the change request needs an approval. If the change request is for some additional information (FT Terms), it does not need any approval. In such cases, the workflow sends a notification. The buyer can respond through e-mail, through the notification, or through Oracle iSupplier Portal. Once the buyer response is received, the change PO API is called to update the purchase order, then the PO Approval workflow is initiated.
Supplier Change Order Workflow Main Process
| Number | Function/Notification Name | Package Procedure | Comments |
|---|---|---|---|
| 1 | ANY_NEW_SUP_CHANGE | PO_SUP_CHG_REQUEST_WF_GRP.ANY_NEW_SUP_CHN | Checks to see if there is a change request and whether it needs approval. |
| 2 | NOTIFY_REQ_PLAN | PO_SUP_CHG_REQUEST_WF_GRP.NOTIFY_REQ_PLAN | Notify the planner and requester about the change request. |
| 3 | IS_PRORATE_NEEDED | PO_SUP_CHG_REQUEST_WF_GRP.IS_PRORATE_NEEDED | Checks to see if the change request has an effect on other POs releases, and decides whether it needs approval or not. |
| 4 | FYI_BUYER_SUP_ACT | FYI to Buyer of Supplier Change (Message) | Notification to buyer which does not need any approval. |
| 5 | NOTIFY_BUYER_OF_CHN | Notify Buyer Of Change (Message) | Notification to the buyer which needs approval. |
| 6 | BUYER_ACC_CHN | PO_SUP_CHG_REQUEST_WF_GRP.BUYER_ACCEPT_CHANGE | Buyer has accepted the change. Record the event. |
| 7 | PROCESS_RESPONSE | PO_SUP_CHG_REQUEST_WF_GRP.PROCESS_RESPONSE | Handover the change request to PO Approval workflow for further processing. |
| 8 | BUYER_REJ_CHN | PO_SUP_CHG_REQUEST_WF_GRP.BUYER_REJECT_CHANGE | Buyer has rejected the change request. |
Receive Supplier Change Event Workflow
This workflow receives and processes the response to a change request. This process is triggered from PO Approval workflow once the change is approved (accepted or rejected).
This process checks if there is any acknowledgement required by the supplier and updates the PO Acceptances accordingly. It then sends a notification to the supplier about the buyer's response. The process also checks to see if the change request came through inbound XML, and if so, triggers another event to send the response in XML format.
Receive Supplier Change Event Workflow
| Number | Function/Notification Name | Package Procedure | Comments |
|---|---|---|---|
| 1 | RECEIVE_SUP_CHN_EVT | Receive Supplier Change PO Eventoracle.apps.po.event.supplier_change | Receive the response. |
| 2 | IS_PO_APPROVED_BY_HIE | PO_SUP_CHG_REQUEST_WF_GRP.is_po_approved_by_hie | Check to see if the change request was approved by the approval hierarchy. |
| 3 | DOES_PO_REQ_SUP_ACK | PO_SUP_CHG_REQUEST_WF_GRP.DOES_PO_REQ_SUP_ACK | If the change requested by the approval hierarchy, check to see if there further changes made and if supplier needs to acknowledge. |
| 4 | NOTIFY_SUP_FINAL_CHN_RESULTS | Notify Supplier of Change's Final Result (Message) | Notification to the buyer which needs approval. |
| 5 | CARYY_SUP_ACK_TO_NEW_REV | PO_SUP_CHG_REQUEST_WF_GRP.CARRY_SUP_ACK_TO_NEW_REV | See if the change request was made as part of acknowledgement and if so let it reflect on the new version of the PO. |
| 6 | IS_XML_CHNG_REQ_SOURCE | PO_SUP_CHG_REQUEST_WF_GRP.IS_XML_CHN_REQ_SOURCE | Check to see if the change request came through XML |
| 7 | SET_RAISE_EVENT_DATA | PO_SUP_CHG_REQUEST_WF_GRP.set_data_chn_resp_evt | If the change request came through XML, set all the necessary information required for the XML generation. |
| 8 | RAISE_SUPP_CHN_RESP-1 | Supplier Change request responded (Event oracle.apps.po.event.suppchnresp). | Raise an event to indicate the change request has been responded |
Send Change Responded Notification to the Supplier Workflow
This process handles the case when a change request is not processed through PO Approval workflow, for example, cancellations or rejections. This process is triggered by the Process_Response activity in the Main Process.
Send Change Responded Notification to the Supplier Workflow
| Number | Function/Notification Name | Package Procedure | Comments |
|---|---|---|---|
| 1 | NOTIFY_SUP_CHG_RESPONDEDN | Notify Supplier Changes are Responded (Message) | Send a notification to the supplier about the response. |
| 2 | CHG_STATUS_TO_APPROVED | PO_SUP_CHG_REQUEST_WF_GRP.CHG_STATUS_TO_APPROVED | Update the change request's status. |
| 3 | IS_XML_CHN_REQ_SOURCE | PO_SUP_CHG_REQUEST_WF_GRP.IS_XML_CHN_REQ_SOURCE | Check to see if the change request came through XML. |
| 4 | SET_RAISE_EVENT_DATA | PO_SUP_CHG_REQUEST_WF_GRP.set_data_chn_resp_evt | Set some information required for the receivers of change responded event. |
| 5 | RAISE_SUPP_CHN_RESP | Supplier Change request responded (eventoracle.apps.po.event.suppchnresp) | Event to indicate that the change request has been responded. |
Send Notification to Planner About Supplier's Change Request Workflow
This process is triggered by the NOTIFY_REQ_PLAN activity in the Main Process. This process sends a notification to the planner about the change request.
Send Notification to the Planner About Supplier's Change Request Workflow
| Number | Function/Notification Name | Package Procedure | Comments |
|---|---|---|---|
| 1 | NOTIFICATION_PLAN_SUP_CHN | Notification for Planner of Supplier Change | Notification to planners about the supplier's change request. |
Send Notification to Requester About Supplier's Change Request Workflow
This process is triggered in the NOTIFY_REQ_PLAN activity in the Main Process.
Send Notification to Requester About Supplier's Change Request Workflow
| Number | Function/Notification Name | Package Procedure | Comments |
|---|---|---|---|
| 1 | NOTIFICATION_REQ_SUP_CHNr | Notify Requester of Change by Supplier | Notify the requester about the change request by the supplier. |
Update Capacity Workflow
A supplier can accurately maintain your delivery capacity online. Buying companies can allocate planned orders taking into account your changes to the capacity constraints. This provides more accuracy and flexibility in making sourcing allocations during the organization's planning, scheduling, and procurement processes.
If a supplier is an approved supplier, they can update capacity abilities for various items. Suppliers can also define tolerance fences by Days in Advance and Tolerance Percent on the Maintain Capacity page. Once the updates are submitted, the buying company's buyer is notified and their approved supplier list is updated with this information. The buying company can then allocate planned orders taking allocation and current capacities into account.
Suppliers can update the following capacity constraints for each item sourced to you:
-
Processing lead time
-
Order modifiers: minimum order quantity and fixed lot multiple
-
Capacity per day for a range of effective date
-
Tolerance fences: tolerance percentage and days in advance
The purpose of this workflow is to allow the planner and buyer to have approval control over the updates and to inform all pertinent user throughout the process.
The Update Capacity workflow is contained in the file POSUPDNT.wft under $pos/patch/115/import/US.
Update Capacity Workflow
The following profile defined at the SYSTEM Level is used to control who (if any) is the approver for the order modifier and update capacity changes being made by the supplier:
-
POS: ASL planning attribute updates from supplier approved by (POS_ASL_MOD_APPR_REQD_BY )
-
NONE
-
BUYER
-
PLANNER
Main Process for Update Capacity Workflow
| Number | Function/Notification Name | Package Procedure | Comments |
|---|---|---|---|
| 1 | INIT_ATTRIBUTES | POS_UPDATE_CAPACITY_PKG. INIT_ATTRIBUTES | Initialize Attributes. |
| 2 | GET_BUYER_NAME | POS_UPDATE_CAPACITY_PKG. GET_BUYER_NAME | Get Buyer Name. |
| 3 | GET_PLANNER_NAME | POS_UPDATE_CAPACITY_PKG. GET_PLANNER_NAME | Get Planner Name. |
| 4 | BUYER_APPROVAL_REQUIRED | POS_UPDATE_CAPACITY_PKG. BUYER_APPROVAL_REQUIRED | Does the Updates Require Buyer's Approval? |
| 5 | PLANNER_APPROVAL_REQUIRED | POS_UPDATE_CAPACITY_PKG. PLANNER_APPROVAL_REQUIRED | Does the Updates Requires Planner's Approval? |
| 6 | UPDATE_MAIN_TABLE | POS_UPDATE_CAPACITY_PKG. UPDATE_ASL | Update ASL. |
| 7 | GET_BUYER | POS_UPDATE_CAPACITY_PKG. BUYER_EXIST | Does Buyer Exist? |
| 8 | INFORM_BUYER_OF_UPDATE_FYI | Inform Buyer/Planner of Capacity Updates | Inform Buyer of Updates. |
| 9 | GET_PLANNER | POS_UPDATE_CAPACITY_PKG. PLANNER_EXIST | Does Planner Exist? |
| 10 | BUYER_PLANNER_SAME_PERSON | POS_UPDATE_CAPACITY_PKG. BUYER_SAME_AS_PLANNER | Are the buyer and the planner same person? |
| 11 | INFORM_PLANNER_OF_UPDATES_FYI | Inform Buyer/Planner of Capacity Updates | Inform Planner of Updates. |
| 12 | GET_PLANNER | POS_UPDATE_CAPACITY_PKG. PLANNER_EXIST | Does Planner Exist? |
| 13 | NOTIFY_PLANNER_OF_UPDATES | Notify Approver of Updates | Notify Planner of Updates. |
| 14 | CHECK_DEFAULT_MODE | POS_UPDATE_CAPACITY_PKG. DEFAULT_APPROVAL_MODE | Check Default Approval Mode. |
| 15 | UPDATE_TEMP_TABLE | POS_UPDATE_CAPACITY_PKG. UPDATE_STATUS | Update status of the temp table. |
| 16 | NOTIFY_SUPPLIER_OF_REJECTION | Notify Supplier of Rejection | Notify Supplier of Rejection. |
| 17 | GET_BUYER | POS_UPDATE_CAPACITY_PKG. BUYER_EXIST | Does Buyer Exist? |
| 18 | NOTIFY_BUYER_OF_UPDATES | Notify Approver of Updates | Notify Buyer of Updates. |
| 19 | UPDATE_MAIN_TABLE | POS_UPDATE_CAPACITY_PKG. UPDATE_ASL | Update ASL. |
| 20 | GET_PLANNER | POS_UPDATE_CAPACITY_PKG. PLANNER_EXIST | Does Planner Exist? |
| 21 | INFORM_PLANNER_OF_UPDATES_FYI | Inform Buyer/Planner of Capacity Updates | Inform Planner of Updates. |
| 22 | NOTIFY_SUPPLIER_OF_ACCEPTANCE | Notify Supplier of Acceptance | Notify Supplier of Acceptance. |
Order Modifiers Workflow
Maintaining order modifiers enables you to view and make changes to the details of a purchase orders scheduled for delivery. You can view shipment processing lead times, minimum order quantities, and fixed lot multiples, all which can be adjusted to fit a supplier's delivery ability. You can make updates or modifications to manufacturing capacity, over capacity tolerance, and order modifier data such as Processing Lead Time, Minimum Order Quantity and Fixed Lot Multiple.
The purpose of this workflow is to allow the planner and buyer to have approval control over the updates and to inform all pertinent user throughout the process.
The Order Modifiers workflow is contained in the file POSORDNT.wft under $pos/patch/115/import/US.
Order Modifiers Workflow
The following profile defined at the SYSTEM Level is used to control who (if any) is the approver for the order modifier and update capacity changes being made by the supplier:
-
POS: ASL planning attribute updates from supplier approved by (POS_ASL_MOD_APPR_REQD_BY )
-
NONE
-
BUYER
-
PLANNER
Main Process for Order Modifiers Workflow
| Number | Function/Notification Name | Package Procedure | Comments |
|---|---|---|---|
| 1 | INIT_ATTRIBUTES | POS_UPDATE_CAPACITY_PKG. INIT_ATTRIBUTES | Initialize Attributes. |
| 2 | GET_BUYER_NAME | POS_UPDATE_CAPACITY_PKG. GET_BUYER_NAME | Get Buyer Name. |
| 3 | GET_PLANNER_NAME | POS_UPDATE_CAPACITY_PKG. GET_PLANNER_NAME | Get Planner Name. |
| 4 | BUYER_APPROVAL_REQUIRED | POS_UPDATE_CAPACITY_PKG. BUYER_APPROVAL_REQUIRED | Does the Updates Require Buyer's Approval? |
| 5 | PLANNER_APPROVAL_REQUIRED | POS_UPDATE_CAPACITY_PKG. PLANNER_APPROVAL_REQUIRED | Does the Updates Requires Planner's Approval? |
| 6 | UPDATE_MAIN_TABLE | POS_UPDATE_CAPACITY_PKG. UPDATE_ASL | Update ASL. |
| 7 | GET_BUYER | POS_UPDATE_CAPACITY_PKG. BUYER_EXIST | Does Buyer Exist? |
| 8 | INFORM_BUYER_OF_UPDATE_FYI | Inform Buyer/Planner of Capacity Updates | Inform Buyer of Updates. |
| 9 | GET_PLANNER | POS_UPDATE_CAPACITY_PKG. PLANNER_EXIST | Does Planner Exist? |
| 10 | BUYER_PLANNER_SAME_PERSON | POS_UPDATE_CAPACITY_PKG. BUYER_SAME_AS_PLANNER | Are the buyer and the planner same person? |
| 11 | INFORM_PLANNER_OF_UPDATES_FYI | Inform Buyer/Planner of Capacity Updates | Inform Planner of Updates. |
| 12 | GET_PLANNER | POS_UPDATE_CAPACITY_PKG. PLANNER_EXIST | Does Planner Exist? |
| 13 | NOTIFY_PLANNER_OF_UPDATES | Notify Approver of Updates | Notify Planner of Updates. |
| 14 | CHECK_DEFAULT_MODE | POS_UPDATE_CAPACITY_PKG. DEFAULT_APPROVAL_MODE | Check Default Approval Mode. |
| 15 | UPDATE_TEMP_TABLE | POS_UPDATE_CAPACITY_PKG. UPDATE_STATUS | Update status of the temp table. |
| 16 | NOTIFY_SUPPLIER_OF_REJECTION | Notify Supplier of Rejection | Notify Supplier of Rejection. |
| 17 | GET_BUYER | POS_UPDATE_CAPACITY_PKG. BUYER_EXIST | Does Buyer Exist? |
| 18 | NOTIFY_BUYER_OF_UPDATES | Notify Approver of Updates | Notify Buyer of Updates. |
| 19 | UPDATE_MAIN_TABLE | POS_UPDATE_CAPACITY_PKG. UPDATE_ASL | Update ASL. |
| 20 | GET_PLANNER | POS_UPDATE_CAPACITY_PKG. PLANNER_EXIST | Does Planner Exist? |
| 21 | INFORM_PLANNER_OF_UPDATES_FYI | Inform Buyer/Planner of Capacity Updates | Inform Planner of Updates. |
| 22 | NOTIFY_SUPPLIER_OF_ACCEPTANCE | Notify Supplier of Acceptance | Notify Supplier of Acceptance. |
Create ASN Workflow
The workflow related components in Create ASN flow are sending the notifications for ASN Creation and ASN Cancellation. This workflow has been defined in the file $pos/patch/115/import/US/posasnnb.wft
Create ASN Workflow
Notification to Buyer of ASN Creation
Notification to Buyer of ASN Creation
| Number | Function/Notification Name |
Package Procedure |
Comments |
|---|---|---|---|
| 1 | SET_BUYER_USERNAME | POS_ASN_NOTIF:GAT_ASN_BUYERS | Get Buyer Username |
| 2 | DUMMY | POS_ASN_NOTIF:SET_NEXT_BUYER | Set Next Buyer |
| 3 | NOTIFY_BUYER | Notify Buyer of ASN Submission | Notify Buyer of ASN Submission |
Notification to Buyer of ASN Cancellation
Notification to Buyer of ASN Cancellation
| Number | Function/Notification Name |
Package Procedure |
Comments |
|---|---|---|---|
| 1 | SET_BUYER_USERNAME | POS_ASN_NOTIF:GET_ASN_BUYERS | Get Buyer Username |
| 2 | DUMMY | POS_ASN_NOTIF:SET_NEXT_BUYER | Set Next Buyer |
| 3 | NOTIFY_BUYER | Notify Buyer of ASN Cancellation | Notify Buyer of ASN Cancellation |
Purchase Order Acknowledgement Workflow
The notifications sent to the supplier and buyer for Purchase Order Acknowledgement are handled as part of PO Approval Workflow.
For detailed description of PO Approval Workflow, see the Oracle Purchasing Implementation Guide.