We use MES and have a very strange situation. A user back on Dec 7th was entering time throughout the day and in the afternoon he noticed that he had been automatically clocked out (his LaborHed.ActualClockOutTime was set to the shift EndTime, 2:30PM).
While this was strange, it turns out that all of his LaborDtl.ClockInTimes and LaborDtl.ClockOutTimes were also changed, all being set to 2:30PM (I assume from either from the LaborHed.ActualClockOutTime or the shift EndTime).
Back in December this was manually fixed and not looked into further, but then it happened again two days ago on Feb 20… Same user, same auto-clockout and changing to all of the labordtl times.
I’m not even sure what to ask. We are not aware of any customizations that would cause anything remotely close to this, and it has been months since it last happened.
Well, the only customization that I see is one on LaborDtl that rounds time to the 1/4 hour, which has been in the system for well over 5 years. Other than that, I don’t see any other DataDirectives or any MethodDirectives that reference Labor.
Okay, well I also am not exactly sure it would help.
But I would maybe see what options there are in the app server logging (that don’t impact performance), trace flags included, and see if that’s something that could help you track this down.
But given the action has come and gone and rarely repeats, I don’t know how useful it would be right now.
Thanks. Yeah, the “rarely repeats” nature is what is the challenge.
I’ve reviewed the existing datadirective, but I don’t see any issues (it only tweaks the LaborHed.ClockIn or LaborHed.ClockOut to round to the 1/4 hour)…
Adam, I am not telling you to turn on trace flags or modify your app server logging.
I don’t know all the implications of it, but I know* someone from Epicor support or another power user here could help answer what tracing affects performance and which traces don’t. I know I have been verbally told this info several times, but I never retained it.
If I were you, I would play around with it on a test app server (if you have one). See what happens when that BPM runs, see if the app server logs anything useful. Maybe it could help you get to the bottom of it the next time it happens.
Major correction: I just spoke to the employee (Dave). He and another employee both clocked in using the same computer. The other employee, thinking the active screen was his, accidentally clocked Dave out, then logged in as himself to clock himself out.
The problem, however, is that Dave’s LaborDtl ClockIn/ClockOut times all changed. The first entry changed to the shift (6:00-2:30), and the remaining entries all changed to 2:30/2:30 (in/out).
Not that this helps too much, but at least no one is getting automatically clocked out.