Using Escalations to Close Completed Work Orders

Technote (FAQ)


Question

Is it possible to somehow close completed work orders automatically?

Answer

Yes. You can create an escalation that queries for work orders that have a specific status and in combination with an action, change the work order's status. To build this escalation you will first need to create an action that changes the work order status.

The action that you create should be for the WORKORDER object and the type should be "Change Status".




The value for the action should be CLOSE.





Once the action has been created, you can create your new escalation. The object should again be pointing to WORKORDER and the condition that will be queried for should look like the one in the screen shot below. This condition will query for all work orders that have a status of COMP. The escalation point can be a date value pulled from the WORKORDER object. In this case STATUSDATE. If you are currently using a synonym for COMP you will need to change the condition to an IN statement rather than an equals statement and list the possible values within the parenthesis. Keep in mind that if you later add additional synonyms for COMP you will need to also update the escalation as it will no longer work if not.





Next a schedule has to be created for the escalation to run on. In this case the escalation has been scheduled to run daily at 6PM. In addition, check the "Repeat" check-box. If you leave the box unchecked, the escalation will record every work order it finds in the ESCREPEATTRACK table and will subsequently query that table for each work order it selects. This will cause the table to grow over time and eventually slow down the performance of this escalation as well as any other escalation that queries this table. Checking the "Repeat" check-box removes the ESCSREPEATTRACK table from the equation and will keep the escalation running smoothly.





Once the escalation has been configured you can then associate your newly created action to it.






Some other considerations......

If you're currently using the MIF while integrating with some external system for work orders, such as sending in reported labor, invoices, etc. which in some way update the work orders, in most cases there is a delay between the work order being ready for closure and the external system catching up with its processing. This can cause an issue because the MIF cannot update a work order that has been closed.

A solution for this scenario is to remove the users' ability to close a work order and have the escalation do the processing instead:

- Crete a new synonym for COMP: RDY2CLOSE
- Take away most users' security permission to change a work order to the CLOSE status and instead have them use the RDY2CLOSE status.
- Set up this escalation to select RDY2CLOSE and as well as a status date more than 90 days old to cover the delay:

Oracle: status = 'RDY2CLOSE' and statusdate < (sysdate - 90)

DB2: status = 'RDY2CLOSE' and statusdate < (current date - 90 DAYS)

SQL Server: status = 'RDY2CLOSE' and statusdate < dateadd(day, -90, getdate())

Changing the status from COMP to RDY2CLOSE is faster than changing to CLOSE. This will save your users time and shifts the processing burden to an off-peak schedule time for the escalation. An administrator can adjust the statusdate comparison to increase or decrease delay time as needed.

Additionally you can create another escalation which works similarly to the one above, but uses a synonym for INPRG like RDY2COMP and has no delay, only a status check to select work orders to complete. This escalation can be set to run at night if you require same day completion, or possibly every hour if you need completion to occur faster than that.


Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

IBM Maximo Asset Management
Escalations

Software version:

6.0, 6.1, 6.2, 6.2.1, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 6.2.6, 6.2.7, 6.2.8, 7.1, 7.1.1, 7.5

Operating system(s):

AIX, HP-UX, Linux, Solaris, Windows

Reference #:

1568868

Modified date:

2013-09-19

Translate my page

Machine Translation

Content navigation