Solved

Actual Start Time Must Have a Value


Userlevel 1
Badge +5

Hello Dream Team,

I am going through two relatively large Maintenance Orders to experience the ELS characteristics. The two are very similar except that, for the second, I wanted to try subtasks how IFS would be like (Pics OM 1 and 2).

The repeating subtask belongs to tasks that go into the same WO. So, as an additional step, I went into MRO and Fleet Operations\Heavy Maintenance Execution\Work Order Management\Work Order Structure and used the Set WO Master/Duplicate command to optimize it (Pic 3).

I am repeating the same process to move forward quickly throughout the WO:

  1. Alocate resources.
  2. Release WO.
  3. Set technicians status to Work Started.
  4. Pick Materials.
  5. Set tecnicians status to Finished.
  6. Anotate Action Taken.
  7. Do the inspector Sign Off (Mechanic Sign Off occurs when I set the respective technician status to Finished.
  8. Set the materials as Non Invoiceable.
  9. Set the Work Task to Finished.
  10. Set the WO status to Finished.

Right on the WO for the subtasks, I have been give the msg ‘Actual Start Time Must Have a Value’ in the Step 5 (this task uses only one technician).

When I use the shortcut WT in the RMB over the WT I get to screen in of the Pic 4. Likewise, when I use the shortcut Report In in the header takes me to the Report In the WO Function, and selecting the tab Report In, I have the screen of Pic 5. I did not need to set the time in neither of these screens for any other WO I worked with for what I suppose the field had been filled automatically in all those cases. This case is not different, but I did notice they were not synchronized. I forced the synchronization but nothing changed.

icon

Best answer by Thommy 13 April 2023, 10:52

View original

2 replies

Userlevel 5
Badge +12

Hi,

Some feedback around this issue.

Me and @Leibnitz Germanio had a Teams session where we tried to figure out what was wrong.

We could conclude that the issue was that the Duplicate Work Tasks was in status “Work Started” (if the Master/Duplicate relationship was in place then that status was promoted when the Master Work Task was set to “Work Started”), but they didn’t had a value in Actual Start.

That is really strange and should not be possible - when changing the status to “Work Started” the Actual Start is automatically set and the value in this can’t be removed if the status i “Work Started”.

We couldn’t figure out why the work tasks had ended up in this situation.

We both tried this flow again (taking extra care to set the Master/Duplicate relations before starting any Work Task) - I did it with “normal” Work Order structure and manually entered Work Orders/Work Tasks and Leibnitz did it again with the Work Order structure coming from MO.

We ended up not being able to recreate the situation described in this issue and everything worked as expected.

So for now we can see this as sorted (until anyone ends up like this again and are able to recreate it).

Userlevel 1
Badge +5

@Thommy was very kind to take me out of this trap. Although I ended up on it, I do not think it will be easy to our customers to do so. The reason I saying so is I was working with two almost two twins Maintenance Orders. The difference between them was only three subtasks among nine Work Orders.

The reason I did an unusual large MO for a test was because I was experimenting with Execution Logic Structure also and I need them to be a bit large. Thus, I might have started one WO from the second MO without noticing it before shooting the duplicate command.

I do not think this is a problem we can expect to see in the field due for the unique situation I was in. If field experience proves otherwise, then we should consider adding a protection. At least, improving user awareness. My customer can increase theirs using the ‘user help feature’ as for now.

I am adding a print of the table Thommy navigated into to troubleshoot the problem. I will refrain to comment on that as I am not versed on IFS tables, but it is certainly useful for the ones who are.

Thanks again, Thommy!

Leibnitz  

Reply