This chapter explains how you can automate the closure of service requests with related tasks. The first topic explains closure. The second provides the procedure for setting it up.
This chapter covers the following topics:
Service requests can have multiple associated tasks that have a completion status independent of the service request itself. If you do not implement closure automation, the closure of each task is independent of the closure of the service request. This means that agents must remember to close all tasks when they close a service request and remember to close the service request after all tasks are completed.
You can automate closure by one or both of the following methods:
If an agent wishes to close the service request, you can have the application check if the service request is ready to be closed and then automatically close all of the related tasks.
The application prevents agents from closing the service request for any of the following reasons:
If any task with the Restrict Closure check box selected is not closed
Agents can select this check box when they create a task to prevent closure of the service request when the task is not in a closed status.
If the service request has associated non-field service tasks that are still being worked on
The application determines a task is still being worked if the task start date is equal or earlier than the system date and if there is no end date. The application checks both the scheduled and actual start date. This is because an engineer may start a task without having yet had the chance to record the actual start date.
This rule does not check Oracle Field Service tasks as this application has its own rules for preventing closure.
If the service request has field service tasks that are scheduled or in progress
See Oracle Field Service documentation for details.
If the service request includes charges that have not yet been successfully submitted
The application only checks charge lines of type Actual with the OM Interface check box selected.
The application does not check for open Oracle Enterprise Asset Management work orders, Oracle Depot Repair repair orders, and maintenance requirements. This means that the service request and associated tasks can be closed even with work orders or repair orders in progress.
You can enable downward propagation by setting the system profile Service: Validate and Auto Close on Service Request Closure to "Yes". The system profile Service: Task Auto Close Status determines the status of the closed tasks.
Oracle Complex Maintenance Repair, and Overhaul closes its own maintenance requirements.
The closure of associated tasks is immediate. As soon as the agent closes the request, all of the tasks are closed as well. If any of the rules are violated, the application warns the agent with an error message.
If all service request tasks have been closed or all charges have been submitted, you can have the application check if the service request is ready to be closed and then close it.
The application prevents the service request from being closed if:
Not all tasks are closed
The application prevents the service request from being closed if any associated task is in a status that does not have the Closed check box selected.
If any debriefed tasks have encountered errors when being converted to charges
If there are any charges that have not been submitted to Oracle Order Management
If there are any Oracle Depot Repair repair orders, Oracle Enterprise Asset Management work orders, or Oracle Complex Maintenance Repair, and Overhaul maintenance requirements.
Closure is prevented if any of these are associated with the service request, regardless of status.
You can turn upward propagation on by setting the system profile Service: Auto Closure of Service Request to "Yes". You specify the status you wish to apply to the service request in Service: Service Request Auto Close Status.
The speed with which the service request is closed depends on your implementation of the Oracle Workflow Event Manager.
This module has seeded event subscriptions for the following two business events:
oracle.apps.jtf.cac.task.updateTask: This event is raised whenever a task is updated.
oracle.apps.cs.chg.Charges.submitted: This event is raised whenever a charge line is submitted to Order Management.
For information on business events and the manager, see the Oracle Workflow Developer's Guide.
Your organization can take advantage of either or both of these methods of automating closure. Most organizations will want to turn on at least the downward propagation because it prevents agents from accidentally closing service requests that have tasks still being worked on.
If your organization delivers field service, you will also benefit from enabling upward closure. If your organization does not perform manual wrap-up of service requests after the engineers enter debrief information in the field, you can have the service requests set to a final status.
Or you can have all service requests set to a special wrap-up status that tells agents which service requests need to be wrapped up.
Use this procedure to set up automatic closure of service requests and associated tasks.
To set up automatic closure for service requests and tasks
Under the Service responsibility, navigate to Setup, Others, Profile System Values.
To turn on downward propagation, set the following two system profiles:
Set Service: Validate and Auto Close on Service Request Closure to "Yes" at the site level to turn on downward propagation. By default this profile is set to "No".
Set Service: Task Auto Close Status to the status you wish to use for all tasks closed automatically. By default, this profile option is not set to any status.
To turn on upward propagation, set the following two system profiles:
Set Service: Auto Closure of Service Request to "Yes" at the site level to turn on upward propagation. By default this profile is set to "No".
Set Service: Service Request Auto Close Status to the status you wish to use for a service request that has been closed automatically. By default, this profile option is not set to any status.