This chapter presents an overview of service request and work order statuses and discusses how to:
Define service request statuses.
Define work order statuses.
Maintenance Management uses system-defined internal statuses and user-defined statuses to control the functionality and flow of service requests and work orders as they progress through their life cycles in the system. Service request statuses and work order statuses are not related and are defined in separate components.
Service request statuses control the functionality and the flow of only the service request, which is created separately from a work order. Any user can create a service request from the self-service components. Using these components does not require access on the part of the requester to the work order or other components of Maintenance Management. However, service requests are assigned to agents and technicians within Maintenance Management. Agents can also create new service requests from within Maintenance Management. Once a service request is created, the agent may choose to create a work order, depending on the problem reported. When a work order is created from a service request, the system uses the work order status definitions to control the behavior of the work order from creation through closure of the work order. The service request status definitions still control the service request, even if the agent created a work order from the service request.
Users can also create work orders from third party help desk applications, Project Costing and Program Management. However, the work order functionality is performed completely within Maintenance Management . The statuses for a work order are set up separately to control the functionality and flow of work orders as they progress through Maintenance Management. In both service requests and work orders, the status transitions are primarily performed manually by the user, with the exception of the service request close and the work order complete and close statuses.
See Understanding Service Request Creation and Use.
See Understanding Work Orders.
To set up service request statuses use the Service Request Status (WM_WR_STATUS) component.
This section discusses how to set up service request statuses.
To manage the processing of a service request, Maintenance Management provides a set of system-defined internal statuses that have specific requirements. In addition, Maintenance Management provides predefined statuses in the delivered data that correspond to the internal statuses. Your organization can use these statuses as defined or use them as a basis for setting up your own status definitions based on your organization's business logic and processes. You must map these user-defined statuses to the system-defined internal statuses. For example, you can create statuses such as open-new, in progress-assigned, and open-awaiting information, and map each of them to the required system-defined internal status, open.
This table describes how the system-defined internal statuses for a service request work in the system:
Service Request System-Defined Internal Status |
Description |
Closed |
This status occurs when a requester clicks the Close button in the service request, the agent selects Close from the status drop-down list, or the service request Close (WM_CLOSE_WR) process changes the status from Complete to Closed based on the expiration of a specific number of days specified in the service request business unit. |
Complete |
This status occurs when the agent selects Complete in the status drop-down list or a user completes the work order associated with the service request. |
Canceled |
This status occurs when a user clicks the Cancel button. |
Open |
This status occurs when you create a service request. |
Work in Progress |
This status occurs when the agent assigns the service request. |
Work Order Created |
This status occurs when an agent creates a work order from a service request. |
This table lists the statuses that Maintenance Management predefines for service requests in the sample data for users and describes how they are mapped to Maintenance Management required system-defined internal statuses. You can use these sample data statuses as they are or modify them based on the needs of your organization:
Maintenance Management Predefined Sample Data User Service Request Status |
Maintenance Management Required System-Defined Internal Status |
Closed |
Closed |
Canceled |
Canceled |
Complete |
Complete |
In Progress — Assigned. |
Work in Progress |
Open — New Open |
Open |
In Progress — Work Order Created |
Work Order Created |
This table describes how a system-defined internal service request status affects the locking of the service request document:
System-Defined Internal Service Request Status |
Is Service Request Document Locked? |
Closed |
Yes – All fields are read only. |
Canceled |
Yes – All fields are read only. |
Complete |
Yes – Service request is locked, but you can change the status back to an Open status to unlock the service request and make changes. |
Open |
No |
Work In Progress |
No |
Work Order Created |
Yes – Locks fields common to service request and work order depending on the status of the work order. |
Service Request Status Transitions
Service request status transitions are triggered by user interaction and automatic processing. An agent or administrator can change a status by selecting a status in the Status field on the service request. Automatic status transitions are triggered when a work order is complete or canceled. A requester can only close, cancel, or re-open (change from complete back to open) a service request.
Note. The user-defined service request status values, which are used for the allowable status transitions, depend on how an organization sets up each service request status.
Setting up the service request statuses is required so that an agent or administrator can select allowable status transitions for each status. Users cannot select the WO Created status, because it is set by the Maintenance Management program. The following table describes the allowable internal status transitions for each service request status.
From Status/To Status |
Open |
Work in Progress |
Complete |
Canceled |
Closed |
WO Created |
Open |
N/A |
Yes |
Yes |
Yes |
No |
No |
Work in Progress |
No |
N/A |
Yes |
No |
No |
No |
Complete |
No |
Yes |
N/A |
No |
Yes |
No |
Closed |
No |
No |
No |
No |
No |
No |
WO Created |
No |
No |
Yes |
No |
Yes |
N/A |
Page Name |
Object Name |
Navigation |
Usage |
WM_STATUS |
Set Up Financials/Supply Chain, Product Related, Maintenance Management, Setup, Service Request Status |
Defines service request status values specific for an organization and matches them with the Maintenance Management required system-defined internal statuses. |
Access the Service Request Status Setup page.
Status |
Enter a status code when you add a new value that is recognizable to your end users. This value is matched with one of the required system-defined internal status values. |
Status Type |
Displays default value of Service Request. |
Internal Status |
Select the Internal Status to match with this user-defined status. Internal statuses for service requests include:
|
Initial Status |
Select this check box if you want this value to be the initial status when a service request is created. You can only select one of the service request statuses at any given point in time. |
Allowed Status Transitions
Status |
Lists allowable status transitions based on the internal status transition you select and the number of defined statuses you created. Note. The Allowed Status Transitions group box only appears if you create a status with an internal status value of Open, Work in Progress, Work Order Created, and Complete. It does not display if the internal status value is Canceled or Closed. |
Use as default |
Select one or more of the Use as Default check boxes to indicate the new status of the service request when a user clicks the Reopen or Close buttons on the Service Request. If two or more transition statuses have the same internal status, then you can only check one of them. We recommend that you not change the status setup as delivered, but if you do, make sure the transition grid for the Complete status contains at least one transition status for Work in Progress and one for Closed selecting the Use as Default check box on each. For example, if the current status of a service request is Complete and you want to reopen the service request by changing the status back to Assigned. If you have multiple user-defined assigned statuses, then you must identify which of these user-defined assigned statuses is the default status that you want to display when you re-open a service request. This is also true when you close a service request. |
To set up work order statuses use the Work Order Status (WM_WO_STATUS) component .
This section describes how to:
Create work order statuses.
Set up work order statuses.
You must set up work order statuses separately for the work order header and the work order task. The work order header status reflects the state of the work order based on the current work order task statuses. You can not modify this status. Like service request statuses, you can establish statuses that are applicable to their organization and map these statuses to Maintenance Management system-defined internal statuses for work orders.
You are not required to set up user-defined statuses for each system-defined internal status for either work order header statuses or work order task statuses. However, you must set up at least one user-defined status for each of these internal statuses:
Open
Complete
Closed
Important! When you set up work order header statuses, you can only set up one user-defined status for each of the system defined internal statuses. However, for work order tasks, you may set up more than one user-defined status for each of the work order task system-defined internal statuses.
Work Order Header Statuses
The work order header status is a passive indicator of the state of all the work order tasks under this work order. Users may not directly modify the work order header status. The system reassesses and potentially changes the work order header status when you access or save the work order based on an internal calculation that determines which task status carries the most weight and should thus apply to the work order header.
The system-defined internal statuses are the same for the work order header and the work order task. To weight the task statuses to determine the status of the work order header, the internal statuses are prioritized from 1 to 8, with 1 being the highest priority. This is described in the following table:
Order |
State |
Description |
1 |
Work in Progress |
At least one work order task has been set to a Work In Progress status, typically meaning that work execution has begun on that task. |
2 |
Awaiting Schedule |
At least one work order task has been set to Awaiting Schedule and there are no tasks in Work in Progress. This status is typically encountered after a work order is approved. |
3 |
Open |
At least one work order task has been set to Open and there are no tasks in either Work in Progress or Awaiting Schedule status. This status would normally occur when a user creates a new work order and saves it with at least one work order task. |
4 |
On Hold |
At least one work order task has been set to On Hold and there are no tasks in Work in Progress, Awaiting Schedule or Open status. This status would normally occur when execution of a work order task has been interrupted due to a problem. Note. You can only go back to the status prior to setting the status on hold, regardless of transitions defined for the On Hold status. |
5 |
Scheduled |
User changes to this status when at least one work order task has been set to Scheduled and there are no tasks in Work in Progress, Awaiting Schedule, Open or On Hold status. Note. If the work order task does not require scheduling, this status is ignored. |
6 |
Complete |
All tasks are complete or canceled, implying that the work associated with the work order task has been completed. Note. Standing work orders do not automatically move to a status of Closed, Canceled, or Complete. When all tasks are completed for a standing work order, the work order status stops immediately at the previous status instruction. You identify a standing work order by selecting a check box in the Miscellaneous page of the work order. |
7 |
Closed |
All tasks are closed or canceled. The work order is closed upon completion of all of the tasks and at the end of the grace period. No status transitions are permitted once a work order task is closed. |
8 |
Canceled |
All tasks are canceled. The work order task has been canceled. No status transitions are permitted for a work order task once it is canceled. Note. If you have not assigned resources to a task, you should delete the task instead of canceling it. You cannot uncancel a task. |
The system updates and displays the work order header status based on all of the statuses of the work order tasks that fall under it. It uses the highest status priority as the work order header status. The following example shows the effect of different task statuses on the work order header for WO001:
Status of Task #1 |
Status of Task #2 |
Status of Task #3 |
Status of Task #4 |
Work Order Header Status |
Notes |
Open Priority = 3 |
Open Priority = 3 |
Open Priority = 3 |
Open Priority = 3 |
Open |
Open is the most outstanding status for all the tasks. |
Closed Priority = 7 |
Canceled Priority = 8 |
Canceled Priority = 8 |
Canceled Priority = 8 |
Closed |
The Closed status in Task 1 has a priority of 7 which is higher than the Canceled status priority of 8 in the system. |
Closed Priority = 7 |
Complete Priority = 6 |
Complete Priority = 6 |
Canceled Priority = 8 |
Complete |
The Complete status has a priority of 6, which exceeds the Canceled priority of 8 and the Closed priority of 7 in the system. |
Work in Progress Priority = 1 |
Open Priority = 3 |
Open Priority = 3 |
On Hold Priority = 4 |
Work in Progress |
The Work in Progress has the highest priority (1) in the system. |
Open Priority = 3 |
Scheduled Priority = 5 |
Closed Priority = 7 |
Complete Priority = 6 |
Open |
Task #1 has a status of Open with a priority of 3, which is the highest priority in the system. |
The relationship between the workflow approval statuses and the work order header statuses determines if and when you can add a task to a work order. The following table describes this relationship.
Workflow Statuses/ WO Header Statuses |
Work in Progress |
Awaiting Schedule |
Open |
On Hold |
Scheduled |
Complete |
Closed |
Cancelled |
No Workflow Approval |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
No |
No |
Workflow Approval Initial, Canceled, Denied |
No |
No |
Yes |
Yes |
No |
No |
No |
No |
Workflow Approval, Pending Approval |
N/A |
N/A |
No |
N/A |
N/A |
N/A |
N/A |
N/A |
Worflow Approval, Approved |
No |
No |
No |
No |
No |
No |
No |
No |
The work order header status level only defines the status display behavior at the work order header level. The work order task status display behavior is only defined by the work order task status. However, the work order header status does define whether you can insert a new task into the work order. The following table indicates the operations that you can and cannot perform based on each of the internal work order header status settings.
Work Order Activity / Internal Status |
Open |
Closed/ Canceled |
Awaiting Schedule |
Scheduled |
Complete |
Work in Progress |
Add notes. |
Yes |
No |
Yes |
Yes |
Yes |
Yes |
Delete notes. |
No |
No |
No |
No |
No |
No |
Add more tasks. |
Yes |
No |
Yes based on workflow rules. |
Yes, based on workflow rules. |
No |
Yes, based on workflow rules. |
Delete task. |
Yes, as long as no assignments were made and based on workflow rules. |
No |
Yes, as long as no assignments were made and based on workflow rules. |
No |
No |
No |
Add attachments. |
Yes |
No |
Yes |
Yes |
Yes |
Yes. |
Modify attachments. |
Yes |
No |
Yes |
Yes |
Yes. |
Yes. |
Delete attachments. |
Yes |
No |
Yes |
No |
No |
No |
Add Job Templates. |
Yes, based on workflow rules. |
No |
Yes, based on workflow rules. |
Yes, based on workflow rules. |
No |
Yes, based on workflow rules. |
Work Order Task Statuses
Users manually change the statuses for work order tasks. The work order task status reflects the true state of the work order task, assuming that there is no discrepancy between work order task status and the state of the actual work order task. For example, if the work order task status in the system is Work in Progress, but the work being performed in the field is actually On Hold due to a delay in the delivery of a part.
The following table indicates the operations that you can and cannot perform based on each of the internal work order task status settings:
Workflow Status = Pre-Approved (No Approval Required) |
||||||||
Task Activity / Internal Task Status |
(1) Work in Progress |
(2) Awaiting Schedule |
(3) Open |
(4) On Hold |
(5) Scheduled |
(6) Complete |
(7) Closed |
(8) Canceled |
Add Labor Requirement. |
No |
Yes |
Yes |
Depends on prior status. |
No |
No |
No |
No |
Modify/Delete Labor Requirement. |
No |
Yes, depending on Requirement being copied to Schedule. |
Yes, depending on Requirement being copied to Schedule. |
Yes, depending on Requirement being copied to Schedule. |
No |
No |
No |
No |
Add Inventory Requirement. |
No |
Yes |
Yes |
Depends on prior status. |
No |
No |
No |
No |
Modify/ Delete Inventory Requirement. |
No |
Yes, depending on Requirement being copied to Schedule. |
Yes, depending on Requirement being copied to Schedule. |
Depends on prior status. |
No |
No |
No |
No |
Add Tools Requirement. |
No |
Yes |
Yes |
Depends on prior status. |
No |
No |
No |
No |
Modify/ Delete Tools Requirement. |
No |
Yes, depending on Requirement being copied to Schedule. |
Yes, depending on Requirement being copied to Schedule. |
Depends on prior status. |
No |
No |
No |
No |
Add Purchase/ On-Hand Requirement. |
No |
Yes |
Yes |
Depends on prior status. |
No |
No |
No |
No |
Modify/ Delete Purchase/ On-Hand Requirement. |
No |
Yes, depending on Requirement being copied to Schedule. |
Yes, depending on Requirement being copied to Schedule. |
Depends on prior status. |
No |
No |
No |
No |
Add Labor Schedule. |
No |
Yes |
Yes |
Depends on prior Status. |
No |
No |
No |
No |
Modify/ Delete Labor Schedule. |
No |
Each row depends on Assignment Status. |
Each row depends on Assignment Status. |
Depends on prior status. |
No |
No |
No |
No |
Add Tool Schedule. |
No |
Yes |
Yes |
Depends on prior status. |
No |
No |
No |
No |
Modify/ Delete Tool Schedule. |
No |
Each row depends on Assignment Status. |
Each row depends on Assignment Status. |
Depends on prior status. |
No |
No |
No |
No |
Add Inventory Schedule. |
No |
Yes |
Yes |
Depends on prior status. |
No |
No |
No |
No |
Modify/ Delete Inventory Schedule. |
No |
Each row depends on Assignment Status. |
Each row depends on Assignment Status. |
Depends on prior status. |
No |
No |
No |
No |
Add Purchase/ On-Hand Schedule. |
No |
Yes |
Yes |
Depends on prior status. |
No |
No |
No |
No |
Modify/ Delete Purchase/ On-Hand Schedule. |
No |
Each row depends on Assignment Status. |
Each row depends on Assignment Status. |
Depends on prior status. |
No |
No |
No |
No |
Modify Distribution. |
No |
Depends on assignments existing on Schedule rows. |
Depends on assignments existing on Schedule rows. |
Depends on prior status. |
No |
No |
No |
No |
Modify Project Information. |
No |
Depends on assignments existing on Schedule rows. |
Depends on assignments existing on Schedule rows. |
Depends on prior status. |
No |
No |
No |
No |
Modify Asset BU and Asset ID. |
No |
No |
Yes |
Depends on prior status. |
No |
No |
No |
No |
Allow further status change. |
Yes |
Yes |
Yes |
Only to prior status or Initial if the user saved the task originally as On Hold. |
Yes |
Yes, depending on user preferences security feature that would allow users to set the status to complete or to manually close the task. |
Yes, only to a Complete Internal Status. This must be a manual close and depends on security setup. |
No |
Update task level scheduled start and end dates. |
No |
Yes |
Yes |
Depends on prior status. |
No |
No |
No |
No |
Record Actuals. |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes for everything but Inventory Issues, POs and Requisitions. |
No |
No |
Add task note. |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
No |
Modify task note. |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
No |
Delete task note. |
No |
No |
No |
No |
No |
No |
No |
No |
Add task instruction. |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
No |
No |
Modify task instructions. |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
No |
No |
Delete task instruction. |
No |
Yes |
Yes |
Depends on prior status. |
No |
No |
No |
No |
Add checklist. |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
No |
No |
Modify checklist. |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
No |
No |
Delete checklist. |
No |
Yes |
Yes |
Yes |
No |
No |
No |
No |
Add attachment. |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
No |
Modify attachment. |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
No |
Delete attachment. |
No |
Yes |
Yes |
Depends on prior status. |
No |
No |
No |
No |
Delete task. |
No |
Depends on Assignments existing on Schedule rows. |
Depends on Assignments existing on Schedule rows. |
No |
No |
No |
No |
No |
Assign task templates. |
No |
Yes |
Yes |
Depends on prior status. |
No |
No |
No |
No |
Add Warranty Claim. |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
Modify/ Delete Warranty claim. |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
Task table continued.
Workflow Approval Status = Initial, Canceled, or Denied |
|||
Task Activity / Internal Task Status |
(3) Open |
(4) On Hold |
(8) Canceled |
Modify Labor Requirements. |
Yes |
Depends on Open status. |
No |
Modify Inventory Requirements. |
Yes |
Depends on Open status. |
No |
Modify Tools Requirements. |
Yes |
Depends on Open status. |
No |
Modify Purchase/ On-Hand Requirements. |
Yes |
Depends on Open status. |
No |
Modify Labor Schedule |
Not available. |
Not available. |
No |
Modify Tool Schedule |
Not available. |
Not available. |
No |
Modify Inventory Schedule |
Not available. |
Not available. |
No |
Modify Purchase/ On-Hand Schedule |
Not available. |
Not available. |
No |
Modify Accounting. Template |
Not available. |
Not available. |
No |
Modify Project Information |
Yes |
Depends on Open status. |
No |
Modify Asset BU and Asset ID. |
Yes |
Depends on Open status. |
No |
Allow further status change. |
Only the ones listed here. |
Depends on Open status. |
No |
Record Actuals. |
No |
Depends on Open status. |
No |
Modify task note. |
Yes |
Depends on Open status. |
No |
Modify task instruction. |
Yes |
Depends on Open status. |
No |
Modify check list. |
Yes |
Depends on Open status. |
No |
Modify attachment. |
Yes |
Depends on Open status. |
No |
Cancel task. |
Yes |
Depends on Open status. |
No |
Delete task. |
Yes |
Depends on Open status. |
No |
Add Warranty Claim. |
Yes |
Yes |
No |
Modify/ Delete Warranty Claim. |
Yes |
Yes |
No |
Task statuses continued.
Workflow Approval Status = Pending Approval |
||
Task Activity / Internal Task Status |
(3) Open |
(4) On Hold |
Modify Labor Requirement. |
No |
Depends on Open status. |
Modify Inventory Requirement. |
No |
Depends on Open status. |
Modify Tools Requirement. |
No |
Depends on Open status. |
Modify Purchase/ On-Hand Requirement. |
No |
Depends on Open status. |
Modify Labor Schedule. |
Not available. |
Not available. |
Modify Tool Schedule. |
Not available. |
Not available. |
Modify Inventory Schedule. |
Not available. |
Not available. |
Modify Purchase/ On-Hand Schedule. |
Not available. |
Not available. |
Modify Accounting. Template. |
No |
Not available. |
Modify Project Information. |
No |
Depends on Open status. |
Modify Asset BU and Asset ID. |
No |
Depends on Open status. |
Allow further status change. |
No |
Depends on Open status. |
Update task level scheduled start and end dates. |
Not available. |
Depends on Open status. |
Record Actuals. |
No |
Depends on Open status. |
Modify task note. |
Yes |
Depends on Open status. |
Modify task instructions. |
Yes |
Depends on Open status. |
Modify check list. |
Yes |
Depends on Open status. |
Modify attachment. |
Yes |
Depends on Open status. |
Cancel task. |
No |
Depends on Open status. |
Delete task. |
No |
Depends on Open status. |
Add Warranty Claim. |
Yes |
Yes |
Modify/Delete Warranty Claim. |
Yes |
Yes |
Task statuses continued.
Once a work order with workflow approval is approved, users cannot add tasks or enter requirements. However they can enter schedule rows to existing tasks, always depending on the current status of the task.
Workflow Status = Approved |
||||||||
Task Activity / Internal Task Status |
(1) Work in Progress |
(2) Awaiting Schedule |
(3) Open |
(4) On Hold |
(5) Scheduled |
(6) Complete |
(7) Closed |
(8) Canceled |
Modify Labor Requirement. |
No |
No |
No |
No |
No |
No |
No |
No |
Modify Inventory Requirement. |
No |
No |
No |
No |
No |
No |
No |
No |
Modify Tool Requirement. |
No |
No |
No |
No |
No |
No |
No |
No |
Modify Purchase/ On-Hand. |
No |
No |
No |
No |
No |
No |
No |
No |
Modify Labor Schedule. |
No |
Each row depends on Assignment status. |
Each row depends on Assignment status. |
Depends on prior status. |
No |
No |
No |
No |
Modify Tool Schedule. |
No |
Each row depends on Assignment status. |
Each row depends on Assignment status. |
Depends on prior status. |
No |
No |
No |
No |
Modify Inventory Schedule. |
No |
Each row depends on Assignment status. |
Each row depends on Assignment status. |
Depends on prior status. |
No |
No |
No |
No |
Modify Purchase/ On-Hand Schedule. |
No |
Each row depends on Assignment status. |
Each row depends on Assignment status. |
Depends on prior status. |
No |
No |
No |
No |
Modify Distribution. |
No |
Each row depends on Assignment status. |
Each row depends on Assignment status. |
Depends on prior status. |
No |
No |
No |
No |
Modify Project Information. |
No |
No |
No |
No |
No |
No |
No |
No |
Modify Asset BU and Asset ID. |
No |
No |
No |
No |
No |
No |
No |
No |
Allow further status change. |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes, depending on user preferences security setting to set status to Complete or Closed. |
Yes, depending on user preferences security setting to set status to Complete or Closed. |
No |
Update task level scheduled start and end dates. |
Yes |
Yes |
Yes |
Only to prior status or Initial if the user saved the task originally as On Hold. |
No |
No |
No |
No |
Record Actuals. |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes for everything but Inventory Issues, POs and Requisitions. |
No |
No |
Modify task note. |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
No |
Modify task instructions. |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
No |
Modify check list. |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
No |
Modify attachment. |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
No |
Cancel task. |
No |
Depends on Assignments existing on Schedule rows. |
Depends on Assignments existing on Schedule rows. |
Only to prior status or Initial if the user saved the task originally as On Hold. |
Depends on Assignments existing on Schedule rows. |
No |
No |
No |
Delete task. |
No |
No |
No |
No |
No |
No |
No |
No |
Add Warranty Claim. |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
Modify/ Delete Warranty Claim. |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
Note. The Approval Status field appears in the work order header. This field is controlled by workflow approval.
See Understanding the Work Order Approval Process.
Status Transitions
When you set up task statuses, with the exception of the closed and canceled statuses, you set up the transitions from one status to another that are allowed in the system. You cannot set up allowable status transitions for work order header statuses. Users can manually change the status based on the allowable transitions for a work order task. The work order header status is read-only.
When a work order task is created, the user selects the value in the Status field based on the allowable transitions for each status.
Note. Users can define more than one status transition based on an internal status. For example, you can set up the On Hold internal status as On Hold - Awaiting Information and On Hold - Resource shortage.
Allowable Status Transitions
The following table describes the allowable work order task status transitions based on each internal status:
From Status/To Status |
Open |
Awaiting Schedule |
Scheduled |
Work in Progress |
Complete |
Closed |
Canceled |
On Hold |
Open |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
Yes* *Before you make any assignments. |
Yes |
Awaiting Schedule |
No |
Yes |
Yes |
Yes |
Yes |
No |
Yes *Before you make any assignments. |
Yes |
Scheduled |
No |
Yes |
Yes |
Yes |
Yes |
No |
No |
Yes |
Work in Progress |
No |
No |
No |
Yes |
Yes |
No |
No |
Yes |
Complete |
No |
No |
No |
No |
No |
Yes |
No |
No |
Closed |
No |
No |
No |
No |
Yes* * Only when you close a task manually. |
No |
No |
No |
Canceled |
No |
No |
No |
No |
No |
No |
No |
No |
On Hold |
Yes* * Can only return back to a status that has the same Internal Status as the one prior to On Hold. If the previous status is On Hold, then the system retrieves the status prior to any On Hold status. |
Yes* * Can only return back to a status that has the same Internal Status as the one prior to On Hold. If the previous status is On Hold, then the system retrieves the status prior to any On Hold status. |
Yes* * Can only return back to a status that has the same Internal Status as the one prior to On Hold. If the previous status is On Hold, then the system retrieves the status prior to any On Hold status. |
Yes* * Can only return back to a status that has the same Internal Status as the one prior to On Hold. If the previous status is On Hold, then the system retrieves the status prior to any On Hold status. |
Yes* * Can only return back to a status that has the same Internal Status as the one prior to On Hold. If the previous status is On Hold, then the system retrieves the status prior to any On Hold status. |
No |
No |
Yes* * Can only return back to a status that has the same Internal Status as the one prior to On Hold. If the previous status is On Hold, then the system retrieves the status prior to any On Hold status. |
Page Name |
Object Name |
Navigation |
Usage |
WM_STATUS |
Set Up Financials/Supply Chain, Product Related, Maintenance Management, Setup, Work Order Status - Add a New Value. |
Defines work order status values specific to an organization and matches them with Maintenance Management required system-defined internal statuses. |
Access the Work Order Status Add a New Value page.
Status |
Enter a status name that identifies a phase of your organization's typical workflow and coincides with one of the Maintenance Management system-defined internal statuses listed below. For example, you might define this status as On Hold - Material on Order and map it to the system-defined internal status value, On Hold. |
Status Type |
Select one of these values:
|
Description and Short Description |
Enter a long description of this status code, and then enter a short description. |
Access the Work Order Status page.
You can set up all of the values in the fields describe previously that reside in the Work Order Status - Add a New Value page. However, you can set up the description, short description, and internal status values in this page.
Description and Short Description |
Set up these fields in the Work Order Status - Add New Value page (they are required fields) and, if desired, you can modify the fields, as well as select the Dictionary button and check the spelling for each field value in this page. |
Internal Status |
Select one of these system-defined internal statuses to apply to this user-defined status. The system-defined statuses include:
Note. You can map one internal header status to only one user-defined header status value. You can map one internal task status value to multiple user defined task statuses. |
Initial Status |
Select this check box if this status is the initial status for the work order task. Note. This check box only displays when you set up a work order task status and is only available for statuses being mapped to an Internal Status of Open. Furthermore, only one task status can be defined as the Initial Status at any given point in time. |
Header Status |
Select the status value that you want to display in the work order header when the weighting of the work order task statuses results in the task status currently being defined. For example, there are three tasks in a work order and the task statuses are On Hold - Awaiting Information (4), Scheduled (5), and Complete (6). Since On Hold has the highest weighted value, then work order header status value would be based on the internal task status of On Hold. However, when you set up the task status for the internal status of On Hold and name the task status On Hold – Awaiting Information, then you can select the Header Status value in this field that you want to display in the work order header's status field. |
Allowed Status Transitions
The allowable status transitions display for task statuses only and are based on the system defined status display rules.
See Understanding Service Request and Work Order Statuses.
Status |
Displays a list of allowed status transitions based on the internal status for the selected status that you are currently defining. The internal status values that allow transitions are:
Important! The Allowed Status Transitions grid does not display if the internal status is Canceled or Closed. Also, when you set up a user-defined task status with a specific internal status, the user-defined statuses that appear in the Allowed Status Transitions grid are dependent on the allowed internal status transitions that appear in the Allowable Status Transitions diagram or the allowable status transitions table. |
Use as Default |
Select this check box if you want this user-defined status value to display in the work order task status field as the default status value when the work order task transitions to the corresponding internal system status. |