Customizing Workflows
This chapter covers the following topics:
- Overview
- Default Workflow Processes
- Guidelines for Customizing Workflow Processes
- Contract Approval Workflow
- Default Approval Process
- Change Management Workflow
- Default Approval Process
- Default Implementation Process
- Default Status Change Process
- Deliverable Workflows
- Default Planning Process
- Default Requisition Process
- Default Shipping Process
- Default Billing Process
- Other Workflows
- Hold Management Workflow
- Communication Action Workflow
Overview
Oracle Project Contracts uses Oracle Workflow to automate contract processes. Oracle Project Contracts provides default workflows for various contract processes. You can modify these workflows and create additional processes to accommodate the needs of your business.
Default Workflow Processes
Oracle Project Contracts provides default workflow processes for contract approval, change request approval, status change and implementation, contract hold processing, planning, shipping, billing and procurement integration, and contract communication processing. You can customize the processes or create new processes. If you want to create a new process to meet your company's needs, use the Oracle Workflow Builder to create a new process, or copy the existing default process and change its name before making changes to it.
Guidelines for Customizing Workflow Processes
Use the following guidelines when you want to customize a default workflow process:
Process Diagram
Use the diagram of the default workflow process as a reference to guide you in developing the workflow process for your implementation. A diagram for each of the default workflow processes is provided in this implementation manual for reference. You can also use the Oracle Workflow Builder to open a default workflow process.
Using the Default Process
While the default processes can be modified or replaced, customization is not required for the default process to function without errors. Some setup may be required for the default process to function. These setup steps will be discussed in more detail in the following sections.
Customizing the Default Process
You can customize the default process, or create a new one, using the Oracle Workflow Builder.
We recommend copying the default process into a new process before customizing. This will prevent future upgrades from overwriting the customized process.
Customizing the Process Activities
You can alter, delete, or move any of the activities in the default process as necessary to meet your business and implementation requirements.
Customizing Workflow Messages
Instead of modifying a workflow notification, you should create a new message.
-
When you create a process definition, Oracle Workflow Builder assigns a new version number to an activity if you make changes to it. It saves the new version of the activity to the database without overwriting older versions of the activity. In Oracle Workflow, activities also have dates of effectivity so that at any time, only one version of the activity is in effect.
-
If a process is running, Oracle Workflow uses the version of the activity that was in effect when the process was initiated. It does not switch versions of the activity midway through the process. Since a process itself is an activity, a process definition always remains constant until the process instance completes.
-
Oracle Workflow Builder does not maintain version information for objects such as item types, item type attributes, messages, and lookup types. For these objects, the latest definition always applies, so you must consider whether a change to any of these objects is backwards compatible. If the modification affects existing processes, you should create a new object rather than edit the existing object.
Contract Approval Workflow
The contract approval process can be dynamic and complex. Different types of contract documents often require different levels of approvals. A typical approval cycle may involve various departments, such as program office, engineering, finance, and legal. Oracle Project Contracts enables you to route contract documents to one or more destinations for approval.
Oracle Project Contracts provides a default approval workflow called OKE Contract Approval. If you need to create your own contract approval process, register the approval process in Oracle Contracts. Once you have registered the new approval process, you can submit your approval process in the Administration tab of the Contract Authoring Workbench.
See Also
Setting up the Approval Process, Oracle Contracts Implementation and Administration Guide
Default Approval Process
The diagram shown below illustrates the approval process provided by Oracle Project Contracts:
The default contract approval process consists of an initialization routine and three sub-processes. The following is a description of each of the sub-processes. All PL/SQL functions mentioned below reside in the package OKE_K_APPROVAL_WF.
Document State Check Sub-Process
The diagram below depicts the Document State Check Sub-Process:
This sub-process is used to verify whether a contract document is eligible for approval. It consists of four separate checks. If the contract document passes the checks, the sub-process will return with a result code of True. Otherwise, it will return with a result code of False.
| Activity | Description |
|---|---|
| Is Document Approved? | This activity checks whether the contract document has already been approved or not. A contract document can go through the approval process only if its current status is of type Entered or Canceled. This activity invokes the PL/SQL function IS_DOC_APPROVED. |
| Is Document Inactive? | This activity checks whether the contract document is currently active or not. A contract document cannot go through the approval process if it is currently inactive. This activity invokes the PL/SQL function IS_DOC_INACTIVE. |
| Is Document a Delivery Order? | This activity checks whether the contract document is a delivery order. If so, additional validation against the master agreement is needed. This activity invokes the PL/SQL function IS_DOC_DELV_ORDER. |
| Is Master Agreement Approved? | This activity checks whether the master agreement associated to the contract document is approved or not. A delivery order cannot be approved if the associated master agreement is not approved. This activity invokes the PL/SQL function IS_BOA_APPROVED. |
Approval Sub-Process
The diagram below depicts the Approval Sub-Process:
This is the main approval engine. It routes the approval through the approval path as specified on the contract document type setup. If the contract document is approved, the sub-process will return with a result code of True. Otherwise, it will return with a result code of False.
| Activity | Description |
|---|---|
| Verify Approval Path | This activity validates the approval path that is associated to the contract document type. It also determines the approval sequence based on the approval path. The approval sequence consists of a list of approver roles. This activity invokes the PL/SQL function VALIDATE_APPROVAL_PATH. |
| Select Next Approver | This activity selects the next approver using the PL/SQL function SELECT_NEXT_APPROVER. The next approver is determined from the current approver role from the approval path. Based on the role assignments of the contract, the appropriate employee is located. If the next approver is found, the assignment is recorded in the approval history. In addition, the PL/SQL function populates the attributes Approver, Approver Role and Approval Sequence and returns TRUE. Otherwise, it returns FALSE. |
| Is Requestor Next Approver? | This activity determines whether the next approver is the same person who requests the contract approval process. If so, the approval process assumes that the intention of the requestor is to approve the contract and will automatically record the approval without generating a notification. This activity invokes the PL/SQL function IS_REQUESTOR_APPROVER. |
| Contract Approval | This activity kicks off a notification to the approver requesting approval of the contract document. By default there are three options: Approve – approve the contract document. Reject – reject the contract document. A rejection note must be provided. Reassign – reassign the approval to another person. The action by the approver is recorded in the approval history via the post-notification function SET_APPROVAL_HISTORY. |
| Rejection Note Filled? | This activity checks whether the rejection note has been filled. It should be invoked after the approval has been rejected. This activity invokes the PL/SQL function REJ_NOTE_FILLED. |
| Is Final Approver? | This activity checks whether the last approver is also the last approver based on the approval path. It is used to determine if additional approvals are needed. This activity invokes the PL/SQL function IS_FINAL_APPROVER. |
| Record Contract Approval Date | This activity records the contract approval date. It invokes the PL/SQL function RECORD_APPROVED. |
Signature Sub-Process
The diagram below depicts the Signature Sub-Process:
This sub-process handles the contract signature process. Contract signature is a required step in the contract status life cycle. A contract cannot become active without a contract signature. Oracle Project Contracts provides a mechanism to bypass the signature process if not necessary based on business requirements while maintaining the required data for the proper contract status management.
If signature is required based on the contract document type approval path, this workflow process seeks the signature, in the form of a workflow notification response, from the signatory. Otherwise if signature is not required, the approval date is used as the signed date automatically.
| Activity | Description |
|---|---|
| Is Signature Required? | This activity determines whether signature is required as specified in the approval path. This activity invokes the PL/SQL function IS_SIGNATURE_REQUIRED. |
| Select Signatory | This activity determines the signatory (the person from which signature is needed) using the PL/SQL function SELECT_SIGNATORY. The signatory is determined from signatory role as specified in the approval path. Based on the role assignments of the contract, the appropriate employee is located. |
| Contract Signature | This activity kicks off a notification to the signatory requesting a signature on the contract document. The signature is currently captured as a signed date on the contract header. The action by the signatory is recorded in the approval history via the post-notification function SET_APPROVAL_HISTORY. |
| Set Signed Date | This activity records the contract approval date. It invokes the PL/SQL function RECORD_APPROVED. |
| Is Final Approver? | This activity checks whether the last approver is also the last approver based on the approval path. It is used to determine if additional approvals are needed. This activity invokes the PL/SQL function IS_FINAL_APPROVER. |
| Record Contract Approval Date | This activity records the contract signed date. It invokes the PL/SQL function RECORD_SIGNED. |
Change Management Workflow
Oracle Project Contracts enables you to specify a workflow process for each change status. The appropriate workflow process, if specified, will be initiated if a change request has been set to the corresponding status.
Oracle Project Contracts provides a default workflow item type called OKE Change Request Processes with three processes: Approval, Implementation, and Status Change. The three default processes will be discussed in this section.
Additional activities and branches can be added to each process based on change types and reasons to fit your business requirements.
Default Approval Process
The diagram shown below illustrates the Approval process provided by Oracle Project Contracts:
The default change request approval process consists of 14 nodes. The following is a description of each of the nodes. All PL/SQL functions mentioned below reside in the package OKE_CHG_REQUESTS_WF.
| Activity | Description |
|---|---|
| Start | This is a standard activity that marks the start of the process. |
| Initialize | When the workflow process is initiated, some of the item attributes are loaded into the Workflow engine. In this activity, the remaining item attributes are loaded. Such attributes include the display names for many internal codes that can be used in notifications. This activity invokes the PL/SQL function INITIALIZE. |
| Select Next Approver | This activity selects the next approver using the PL/SQL function SELECT_NEXT_APPROVER. If the next approver is found, the PL/SQL function populates the attribute Next Approver and returns TRUE. Otherwise, it returns FALSE. By default, the PL/SQL function looks up the first Contract Administrator as specified. Contract level administrators will be searched first, followed up program level and lastly site level. You can customize this activity by using a custom function that returns the appropriate approver based on a hierarchy suitable for your implementation. |
| Change Request Approval | This activity kicks off a notification to the Next Approver requesting approval of the change request. By default there are three options: Approve – approve the change request. This option will direct to look for additional approver using the Select Next Approver activity. Reject – reject the change request. A rejection note must be provided. Reassign – reassign the approval to another person. |
| Select Next Informed | This activity selects the next informee using the PL/SQL function SELECT_NEXT_INFORMED. If the next informee is found, the PL/SQL function populates the attribute Next Informed and returns TRUE. Otherwise, it returns FALSE. This activity is used in both approval and rejection notification. The underlying PL/SQL function is also used in the Status Change process. By default, the approval or rejection notification will be sent to the original requestor. You can customize this activity by using a custom function that returns the appropriate list of informee suitable for your implementation. |
| Change Request Approved By | This activity kicks off a notification to the Next Informed regarding the last change request approval. This notification is for information only and does not require a response. |
| Update Approved Status | This activity invokes the PL/SQL function SET_APPROVED_STATUS updates the change request to the default Approved status. |
| Change Request Approved | This activity kicks off a notification to the original requestor regarding the final approval of the change request. At this point, the change request status has already been updated to one of Approved type. This notification is for information only and does not require a response. |
| End (Approve) |
This is a standard activity that marks the end of the process. It returns a result of APPROVE for the workflow process. |
| Rejection Note Filled | This activity checks for the rejection note by calling the PL/SQL function REJ_NOTE_FILLED. Rejection note is required if the approver rejects the change request. This activity returns TRUE is rejection note is filled, FALSE otherwise. |
| Change Request Rejected | This activity kicks off a notification to the Next Informed regarding the change request rejection. This notification is for information only and does not require a response. |
| Update Rejected Status | This activity invokes the PL/SQL function SET_REJECTED_STATUS updates the change request to the default Approved status. |
| End (Reject) |
This is a standard activity that marks the end of the process. It returns a result of REJECT for the workflow process. |
Default Implementation Process
The diagram shown below illustrates the Implementation process provided by Oracle Project Contracts:
The default change request implementation process consists of eight nodes. The following is a description of each of the nodes. All PL/SQL functions mentioned below reside in the package OKE_CHG_REQUESTS_WF.
| Activity | Description |
|---|---|
| Start | This is a standard activity that marks the start of the process. |
| Initialize | When the workflow process is initiated, some of the item attributes are loaded into the Workflow engine. In this activity, the remaining item attributes are loaded. Such attributes include the display names for many internal codes that can be used in notifications. This activity invokes the PL/SQL function INITIALIZE. |
| Change Impact Funding? | This activity checks whether this change request impacts funding using the PL/SQL function IMPACT_FUNDING. This activity is useful in routing the workflow to different organizations when a change request impacts funding. |
| Change Request Implementation | This activity notifies the original requestor that the change request is ready for implementation. This notification can be routed to the appropriate department that is responsible for implementing contract changes. This notification is for information only and does not require a response. |
| Change Request Funding Implementation | This activity notifies the original requestor that the change request is ready for implementation. This implementation can be routed to a different department that is responsible for implementing funding changes to a contract. This notification is for information only and does not require a response. |
| And / Or | This is a standard activity to merge the results from the two different branches in the workflow process. |
| End | This is a standard activity that marks the end of the process. |
Default Status Change Process
The diagram shown below illustrates the Status Change process provided by Oracle Project Contracts:
The default change request status change process consists of six nodes. The following is a description of each of the nodes. All PL/SQL functions mentioned below reside in the package OKE_CHG_REQUESTS_WF.
| Activity | Description |
|---|---|
| Start | This is a standard activity that marks the start of the process. |
| Initialize | When the workflow process is initiated, some of the item attributes are loaded into the Workflow engine. In this activity, the remaining item attributes are loaded. Such attributes include the display names for many internal codes that can be used in notifications. This activity invokes the PL/SQL function INITIALIZE. |
| Select Next Informed | This activity selects the next informee using the PL/SQL function SELECT_NEXT_INFORMED. If the next informee is found, the PL/SQL function populates the attribute Next Informed and returns TRUE. Otherwise, it returns FALSE. The underlying PL/SQL function is also used in the Approval process. By default, the status change notification will be sent to the original requestor. You can customize this activity by using a custom function that returns the appropriate list of informee suitable for your implementation. |
| Change Request Status Change | This activity kicks off a notification to the Next Informed regarding the last status change. This notification is for information only and does not require a response. |
| End | This is a standard activity that marks the end of the process. |
Deliverable Workflows
Workflow processes are used throughout the Deliverable Tracking System to route specific actions that have been initiated and to perform the relevant tasks.
Oracle Project Contracts provides a default workflow item type called OKE Deliverable Processes. The OKE Deliverable Processes item type includes three processes: Planning Process, Requisition Process, and Planning Process. In addition, Oracle Project Contracts also provides another default workflow item type called OKE Deliverable-Based Billing to handle billing activities.
Each default process integrates with the respective Oracle application to process the activity. The processes can be tailored to integrate with third party systems.
The default processes will be discussed in this section.
Default Planning Process
The diagram shown below illustrates the Planning process provided by Oracle Project Contracts:
The default planning process consists of 4 nodes. The following is a description of each of the nodes.
| Activity | Description |
|---|---|
| Start | This is a standard activity that marks the start of the process. |
| Create Planned Entry | This activity creates the corresponding MDS entry in Oracle Advanced Planning and Scheduling using the PL/SQL function OKE_DTS_INTEGRATION_PKG.CREATE_EVENT. You can replace this activity with the appropriate action if you are not using Oracle Advanced Planning and Scheduling. |
| Planning Notification | This activity fires off a notification to the original requestor about the planning entry details and can be routed to the appropriate department. This notification is for information only and does not require a response. |
| End | This is a standard activity that marks the end of the process. |
Default Requisition Process
The diagram shown below illustrates the Requisition process provided by Oracle Project Contracts:
The default requisition process consists of 4 nodes. The following is a description of each of the nodes.
| Activity | Description |
|---|---|
| Start | This is a standard activity that marks the start of the process. |
| Create Requisition | This activity creates a requisition in the requisition interface in Oracle Purchasing using the PL/SQL function OKE_DTS_INTEGRATION_PKG.CREATE_EVENT. You can replace this activity with the appropriate action if you are not using Oracle Purchasing. |
| Requisition Notification | This activity fires off a notification to the original requestor about the requisition details and can be routed to the appropriate department. This notification is for information only and does not require a response. |
| End | This is a standard activity that marks the end of the process. |
Default Shipping Process
The diagram shown below illustrates the Shipping process provided by Oracle Project Contracts:
The default shipping process consists of 4 nodes. The following is a description of each of the nodes.
| Activity | Description |
|---|---|
| Start | This is a standard activity that marks the start of the process. |
| Create Shipping Request | This activity creates a shipping request in Oracle Shipping Execution using the PL/SQL function OKE_DTS_INTEGRATION_PKG.CREATE_EVENT. You can replace this activity with the appropriate action if you are not using Oracle Shipping Execution. |
| Shipping Notification | This activity fires off a notification to the original requestor about the shipping details and can be routed to the appropriate department. This notification is for information only and does not require a response. |
| End | This is a standard activity that marks the end of the process. |
Default Billing Process
The diagram shown below illustrates the Billing process provided by Oracle Project Contracts:
The default billing process consists of 6 nodes. The following is a description of each of the nodes.
| Activity | Description |
|---|---|
| Start | This is a standard activity that marks the start of the process. |
| Notification | This activity fires off a notification to the original requestor about the billing details and can be routed to the appropriate department. This notification is for information only and does not require a response. |
| Create Event | This activity creates a billing event in Oracle Projects using the PL/SQL function CREATE_BILLING_EVENT in package OKE_DELIVERABLE_BILLING_WF. This activity returns TRUE if the billing event has been successfully created, FALSE otherwise. You can replace this activity with the appropriate action if you are not using Oracle Projects. |
| Create Event Failed | This activity sends a notification to the original requestor in case the billing event creation failed. The reason for the failure is included in the body of the notification. This notification can then be routed to the appropriate department for corrective actions. This notification is for information only and does not require a response. |
| End (True) |
This is a standard activity that follows the successful creation of the billing event and marks the end of the process. This activity returns a value of True for the workflow process. |
| End (False) |
This is a standard activity that follows the failed attempt to create the billing event and marks the end of the process. This activity returns a value of False for the workflow process. |
Other Workflows
Oracle Project Contracts includes additional default workflow processes for Hold Management and Communications Action Processing.
Hold Management Workflow
Oracle Project Contracts enables you to specify a workflow process for each hold status. The appropriate workflow process, if specified, will be initiated if a contract hold has been set to the corresponding status.
Oracle Project Contracts provides a default workflow item type called OKE Hold Status Change with a default process called Hold Status Change. The diagram below illustrates this default process:
The default process includes an activity to trigger a notification that can be routed to the appropriate departments, such as engineering, production, and purchasing, to process the contract hold. Additional activities and branches can be added based on hold types and reasons to fit your business requirements.
Communication Action Workflow
Oracle Project Contracts enables you to specify a workflow process for each communication action. The appropriate workflow process, if specified, will be initiated if a communication has been logged with the corresponding action.
Oracle Project Contracts provides a default workflow item type called OKE Communication Action with a default process called Communication Action Process. The diagram below illustrates this default process:
The default process includes an activity to trigger a notification that can be routed to the appropriate departments to take action on the communications. Additional activities and branches can be added to fit your business requirements.