Completing work orders
The use case in this topic describes how to complete a work order.
To complete a work order, use the PUT /api/workorder/checkout method of the CorrigoPro Direct API.
WebHook notification available
For information about details of this notification, see Work order completed.
Provide geolocation information
The information about geographical location of a technician/ subcontractor at the time of the Complete operation is used for verification of work order activities by a customer.
SLA
When working on completion of a work order, make sure you stay within SLA timelines as it affects your score in a customer system. Refer to WorkOrder.SLA.
A successful API response means that the work order is completed, and its status is changed to Completed.
You can also verify that the work order status is changed by calling the GET /api/workOrder/. This method returns up-to-date work order data.
If the API returns an error, see Error Codes for troubleshooting the problem.
Before completing a work order
It is strongly recommended to check your customer settings before sending a completion request!
Your customer ID is provided as a WorkOrder.Customer.ID property obtained either via Work order received notification, or via GET /api/workOrder/ method of the CorrigoPro Direct API. Your customer settings can be retrieved by using GET /api/customerSettings method of the CorrigoPro Direct API.
Depending on your customer settings, work order completion may include the following subroutines:
- Specifying repair information
- Answering customer questions
- Filling out check list
- Specifying equipment worked on.
Completing a Request vs. Completing a PMRM when additional information is required
A work order of Type PMRM can still be completed using the PUT /api/workorder/checkout method even if the customer requires additional information (such as repair information or custom fields). The work order will be changed to the NeedsCompletionDetails status instead of CheckedOut.
A work order of Type Request must send the additional information when the work order is completed, or the PUT /api/workorder/checkout request will give an error response indicating what information is missing from the request.
Specifying repair information
A customer may require you to specify the category and subcategory (code) of a problem resolved in work order.
Available categories and codes can be retrieved by using GET /api/customerSettings method.
The data are provided in a tree-like form where root nodes are repair categories, and child nodes are repair codes.
Warning
It is forbidden to specify a repair category without a relevant repair code, if one exists. An error with code 3003 will be returned on attempt to do it.
However, if a repair category has no children (RepairCategory.Codes is null or empty), it is possible to specify only a repair category.
Answering customer questions
A customer can define up to three questions, required or optional. To answer these questions, you must fill out CustomFields property of a work order completion request.
You can retrieve questions (fields) defined by a customer by using GET /api/customerSettings method.
Each question is unique and is fully described in a corresponding CustomFieldDescriptor.
The CustomFieldDescriptor defines a value type of an answer. It can also include a list of available answers. No free text input is allowed in this case.
To map a question to an answer, you must send an ID of the corresponding descriptor within each CustomField model during work order completion.
Important
Custom field values are case-sensitive.
Filling check list
A work order may contain a list of items to be checked during or after the work is done.
For more details on how to process a check list, see Completing checklist. A check list may be included within the completion request.
Important
Currently there is no way to determine whether a check list is required, except by receiving an appropriate error during a complete work order operation.
Specifying equipment worked on
You cannot specify equipment worked on within the completion request. If your customer requires information about equipment, you must use a separate set of CorrigoPro API methods to provide it:
- POST /api/equipment/ to add a piece of equipment to a work order
- PUT /api/equipment/ to edit a piece of equipment added to a work order
- DELETE /api/equipment/ to remove a piece of equipment from a work order.
If your customer requires information about equipment, but work was not related to any equipment - add a single piece of equipment with Equipment.Type property set to Excluding.
For detailed information on how to work with equipment, see Specifying Equipment worked on.
Important
The only way to determine whether equipment information is required is by receiving an appropriate error during a complete work order operation.
Completion of PMRM work orders without check-in first
Work orders with a WorkOrderType of PMRM may be checked out from the following statuses: Accepted, CheckedIn, Paused, OnHold (only if this provider had accepted the work order before it was put on hold).
No repair information or custom fields should be set in the request body in this case.
The work order will be changed to the NeedsCompletionDetails status instead of CheckedOut.
Backdating by using ActualActionDate
The field ActualActionDate is an optional parameter that is indicating that this step has already been taken and you are providing the datetime for which it was actually performed.
If this step is being performed in real-time, you should not send this field. You may omit the field, or send a value of null.
In order to use an ActualActionDate, the customer's configuration needs to include the setting to allow backdating. If the customer's configuration does not allow for backdating then must send the request with ActualActionDate omitted or set to null.
Updated almost 5 years ago