Last Updated on October 29, 2023 by maximosecrets

This article will first look at recording time against the Service Request. However, you can also record time against the activities of a ticket, therefore we will follow with recording time against an Incident. The Incidents application has an Activities tab, the Service Requests application while supporting activities, does not have an Activities tab. 

Time Tracking on Service Requests

I have created a new Service Request 1316 and scrolled down to the bottom of the main tab where there is a Time Tracking table window with two buttons, New Row and Select Labor. You can record time spent on a Service Request, or other ticket, in a similar manner to how you report time on a work order.

I am logged on as AJE – Andrew Jeffery. In the Common Actions section of the application menu there are two actions Start Timer and Stop Timer. When I press Start Timer, I receive the error message “BMXAA2540E – No labor found for user AJE.” As you might have guessed the tracking of time uses the same Labor Reporting capability as you see in the Work Order Tracking application and hence a Labor Code will be required for your Service Desk staff or other staff where you wish to record time spent against tickets. 

Incidentally, the Start Timer and Stop Timer functionality is also available for work orders, you see it in the Activities and Tasks application, there is no action menu items for the Work Order Tracking application.

I will log out and log back in as WILSON – Mike Wilson.

This time, logged in as WILSON, when the Start Timer action is used a Time Tracking record is created with a Start Date/Time but no End Date/Time or regular hours. Notice that the GL Debit and Credit Accounts have been filled-in, I’ll return to the defaulting rules for this at the end of the article.

The Craft is ELECT with a Skill Level of FIRSTCLASS, this being Mike Wilson’s default craft. The rate of $22.00 is also derived from Mike’s Craft record. The default actual labor transaction type is WORK.

This is a convenient time to have lunch.

When you use the Stop Timer action a Confirm Timer dialog may open, and this gives you the ability to adjust the start and end date and times. There is a check box at the bottom, Complete Work Order. This is a generic dialog used across tickets, activities and work orders, so when it says Complete Work Order it would complete the Activity, but it does not mean that it will complete the ticket. The Hours is calculated as the difference between the Start Time and Finish Time, at 1:05.

After pressing OK, the Time Tracking record is updated, the Line Cost calculated from the Rate and Regular Hours, and the record is marked as Approved, as that is the setting for internal labor hours.

If you were claiming overtime hours you would need to select the Premium Pay Code on the Time Tracking record immediately after starting the timer, or before using the Stop Timer action, as the Confirm Timer dialog doesn’t allow you to do this. The Confirm Timer dialog is actually based on the non-persistent object CONFIRMLABTRANS and not LABTRANS. If the period of time overlaps into an overtime period, then in the Confirm Timer dialog modify the Finish Time attribute to be the end of normal time and then use the New Row button on the Time Tracking table to add in the overtime period.

Actual labor hours is recorded in the LABTRANS object/table, which is defined at the SITE level. If the site on the Service Request has not been set then the SiteA structural element of a Maximo database that is used for data separation. More field will be set to the user’s default insert site of the first person to use the Start Timer button, BEDFORD, in this case. Your Service Request processes may need to consider the setting of this field prior to being able to use the Start Timer action.

If you used the New Row button on the Time Tracking table window and there was no value for the Site field, then the Default Insert Site of the person recording the actual time would be used as the Site for the LABTRANS record. There is no setting of the Site field on the Service Request in this case.

When you start the timer, a record is created in the LABTRANS object/table and the attribute TIMERSTATUS is set to ACTIVE. When you stop the timer, the record in LABTRANS is updated and the attribute TIMERSTATUS is set to COMPLETE. If you use the Stop Timer button on a record where the Start Timer has not been used, you will receive the error message “BMXAA2554E – Timer not started.”. If you tried to start the timer a second time the error message “BMXAA2553E – Timer already started.” is displayed.

The Service Request is still at NEW status, and we have entered actual labor. That is one difference with a work order where actual labor cannot be reported at the initial status of WAPPR – Waiting to be Approved. The entering of actual time does not change status or set any of the Actual Dates.

The View Costs action shows on the left panel the hours and costs of the ticket and its activities. The time was 1:05, one hour and five minutes, or 1.08 when represented as a decimal. There were no activities on this Service Request and so the cost of $23.83 is WILSON’s time at the rate of $22.00/hour.

The right-hand side panel of the View Costs dialog shows the hierarchy hours and costs which includes the time for the Service Request. Some people think that an activity cannot have children because it is a task, I have heard people refer to activities as ticket tasks. Neither is true, activities and tasks are different records they happen to be displayed in the same application called Activities and Tasks. You can apply a Job Plan to an Activity in the Plans tab of the Activities and Tasks application, and hence a work order hierarchy is created. If you are viewing a task record the Plans tab is not displayed, and hence you could easily think that there could not be a hierarchy. You should consider an Activity much more like a child work order rather than a task.

You can start the timer and then complete the Time Tracking record manually. In this example we took the opportunity to record the 15 minutes between end of shift at 15:00 and end of the time record at 15:15 as 0:15 of Premium Pay Hours with a Premium Pay Code of OT1, time and a half, Premium Pay Rate is 1.50. Manually finishing the time record will set the Timer Status to COMPLETE, in this case there is no Confirm Timer dialog.

Maximo has a future date tolerance which stops you from entering time which is in the future by a tolerance amount more than time now. If the time you are entering is in the future, you may get the error message “BMXAA2641E – You cannot enter actual labor with future dates and times.”.

Organization – System Settings

In the OrganizationsA structural element of a Maximo database which is used for data sharing and is often aligned to a legal entity of an organisation. More application and under System Settings is a section called Timer with three check boxes:

• Automatically change work order status to INPRG when a user starts a labor timer (it is checked)
• By default, change the work order status to COMP when a user stops a labor timer (it is unchecked)
• Confirm Time Calculated by Timer (it is checked).

We have already seen the Confirm Timer dialog earlier. When we started the timer there was no change to the ticket status, and so we should check the other two settings with an Activity that is a child of an Incident.

Time Tracking on Incidents

I’ve created a new Incident 1264 and used the Apply Incident Template and will select 1006 – Suspicious Email – Virus Symptoms.

After pressing OK, the Ticket Template is applied and on the Activities tab you can see that the Incident has created four activities T1255, T1256, T1257 and T1258. Each of these has its own status, and WAPPR would be an indication to many that an Activity is a class of Work Order. Each of these activities has an Owner Group and its own Classification. This is enough for it to appear on the queue of the owner group waiting for someone to take ownership of that Incident’s Activity. The queue would normally be represented by a Result Set portlet on a user’s Start Center.

Below the Activities tab is the Time Tracking table with New Row and Select Labor buttons that we saw with the Service Request, in the Incidents and Problems application it does not appear at the bottom of the main tab. You can also see the two actions Start Timer and Stop Timer in the Common Actions part of the application menu.

A few minutes ago, I used the Start Timer action, and now I have used the Stop Timer action and the Confirm Timer dialog opens. The use of the timer only allows you to record time against the main record of the application, Incident in this case. There is no ability to record time against one of the activities using the timer, not unless you are in the Activities and Tasks application. 

The detail layout for the Time Tracking table in the Incidents application is a little different from that in the Service Requests application. In the Details section it shows the Timer Status as COMPLETE. Three minutes of time was recorded against the Incident.

I’ve used the Start Timer action again and this time I want to record time against one of the activities, T1255. The Start Timer action creates a Time Tracking record with a Timer Status of ACTIVE. The Activity Select Value allows you to select the activity. However, I received the error message “BMXAA4558E – Work order Activity T1255 is not a valid approved work order. The work order must have a status of Approved.” Unlike a Service Request or other Ticket which allow you to create time records when the status is NEW, the initial state, you need to have at least changed status to APPR or beyond on a work order or activity before being able to enter actual time.

The Incidents application gives you the ability to change status on the Activities table window by using the traffic light button at the end of the row. I’ve changed activity T1255 to Approved (APPR).

This then allowed me to select activity T1255 for the existing Time Tracking record started by the Start Timer action. I have entered an End Time and 4 minutes has been added, but the time is against the activity and not the Incident record. On save the Timer Status is set to COMPLETE and the time record against an internal labor record is automatically Approved and it becomes read-only.

There is a View Costs action in the Incidents application. In the left-hand Totals panel, you can see 3 minutes (decimal 0.05) recorded against the Incident, and 4 minutes (decimal 0.07) recorded against the Activity. In the right-hand panel, Hierarchy Grand Totals, the totals are for both the Incident and Activities, 7 minutes (decimal 0.12). This would show hours and costs from descendants of the activities, for example if a Job Plan with Tasks was applied to the activity. 

Estimates are only on Activities and not on Tickets.

I’ve navigated from the Incidents application to the Activities and Tasks application for Activity T1255 which has already got 4 minutes of actual time. I’ve used the Start Timer action.

The Activity has changed status to INPRG. This was because in the Organizations application and System Settings the option “Automatically change work order status to INPRG when a user starts a labor timer” was checked. Notice the Status Date is 17^th November 2021 at 10:08.

Further down the Activities and Tasks application in the Scheduling Information section this created an Actual Start, 17^th November 21 09:08. The time element is out by an hour, I don’t know why because WILSON is set to use GMT time zone and as you saw by the status date it is an hour later, there is no daylight savings now we are in the winter months. I did check this out on two other systems, one hosted by IBM and everything worked perfectly, but I thought I would mention it.

Before stopping the timer, I will go and change the Organizations – System Setting for “By default, change the work order status to COMP when a user stops a labor timer” so that it is checked.

When I use the Stop Timer action on an Activity the Complete Work Order checkbox is now checked, this is because of the Organization – System Setting change I just made. The System Setting is acting as a default for the Confirm Timer dialog.

After pressing OK, the status is changed to COMP at 17^th November 2021 10:54.

The Scheduling Information section shows an actual date one minute earlier at 10:53. 

But this corresponds with the End Time of the Labor Transaction where the Stop Timer action was last used, and if you look back a few screen shots to the Confirm Timer dialog that also had an End Time of 10:53. The difference of a minute was down to me pausing to take screenshots of the Confirm Timer dialog before pressing the OK button. The status change is made after the OK button is pressed and the function to change status to COMP is activated.

The last test I wanted to do was see what would happen if I had started the timer on both the Incident and an Activity and then tried to Resolve and Close the Incident.

The top two Time Tracking records have 0:00 hours and the top one has no activity and is because I used the Start Timer on the Incident. The second record down was when I used the Start Timer action in the Activities and Tasks application for Activity T1257.

When changing the Incident to a status of RESOLVED there is no change to the Time Tracking records with a Timer Status of ACTIVE. All of the Activities are now at COMP status, the status at RESOLVED and CLOSED is rolled-down to activities, this was discussed in my last article on Status Inheritance on Tickets which you can find here: http://maximosecrets.com/2021/11/16/status-inheritance-on-tickets/

When trying to change status on the Incident to CLOSED you will receive the error messages “BMXAA4295E – Could not change ticket 1264 status to CLOSED.”, “BMXAA7333E – You cannot close the ticket because there are still unapproved labor transactions on this ticket.”.

I’ve used the Stop Timer on the Incident, but not the Activity. The Confirm Timer dialog did not show a check box for Complete Work Order, as it is a ticket.

Now I have managed to change status on the Incident to CLOSED and it has rolled-down the status to the child activities, all except for activity T1257 which has the open labor transaction. You cannot assume that when the Incident is closed that its activities are also closed, not when using the Timer, you do not get a warning message, which would have been useful. 

I have stopped the timer on activity T1257 and then manually changed its status to CLOSE.

Ticket GL Transactions

If GL Validation is turned on for your organization, you may receive the error “BMXAA2530E – Not a valid labor transaction GL account ????-???-300. Either the required components are not filled, or the component values are not valid.”

The GL Debit and Credit Account are set when you use Start Timer, a labor transaction is being created.

I’ve opened-up the three GL fields on the LABORCRAFTRATE table.

With no locationA physical place where assets exist and where work can be performed. More, asset or GL Account referenced on the Incident record, the GL Debit Account was 6820-400-300. It is derived from the GLACCOUNT field on the LABORCRAFTRATE table, ????-???-300 in our example, and if this is a partial GL then the Global Ticket Account found in Organization Default Accounts provides the other segments, this was 6820-400-000 for EAGLENA.

With a location and/or asset their GL Accounts are merged onto the Incident GL Account and this account is then merged with the GLACCOUNT field on the LABORCRAFTRATE table.

The GL Credit Account on the time record for the Incident was 6810-700-300 and this also comes from the Labor-Craft record for WILSON but the Control Account.

The Default Ticket GL Account is not used, and I don’t know where it would be used, if not in the scenario of adding time to a ticket when there is no location or asset. I did try modifying the second segment, but it looks as if it doesn’t get used.

You can get more information on the financial processes for work orders, the merging processes are the same for labor on tickets. How the three fields on the LABORCRAFTRATE table are derived is explained in the section called GL defaulting on the Labor Craft Rates record. The article can be found here: http://maximosecrets.com/2020/05/11/financial-processes-on-work-orders-1-of-3/

In most cases a ticket will reference a location and/or asset and this provides a partial GL Account on the Ticket record. This is then merged with the GL Account from the Labor Craft Rate table. The derivation of the GL Account only gets a bit interesting when there is no GL Account on the Ticket, consequently, try to avoid starting the timer too early while you are still filling out the Service Request. As most Incidents are created from a Service Request then you’ll be pleased to hear that the GL Account is copied when the Incident is created, therefore you can start the timer on an Incident or its Activities as soon as you receive them.