We run 20ish hours a day in some of our plants which means our second shift often goes past midnight. We have found that if someone clocks in / out of a job at exactly Midnight 00:00 Epicor will automatically assign them 24 hours of Labor (and Burden if setup). We have tried every BPM in the history of BPMs to get around this to no avail.
There is a little internal method that re-calculates ClockOutTime automatically inside the BO and even if you mess with it via a BPM it gets over-ridden in this internal function
At the moment we have no work around, the one thing I did eventually do is check if the transaction is going to happen exactly at midnight I now force the employees to sit on their hands for a minute
This is a weird issue that mostly probably applies to us because we report labor quite frequently often seconds apart from one to another. But it is extremely annoying since we have COS/WIP running automatically which cements the problem and throws our costs into disarray.
Not looking for solutions just whining about the absurd logic at play here. It is specifically accounted for in the code that if ClockoutTime =0 then it tries to subtract from 24 hours
Epicor is not very good at maths⌠I still donât understand why they donât just capture ClockIn Time Stamp, Clockout TimeStamp and then do a Diff⌠This whole ClockInMinute since the year of the plague (10/30/1953⌠because arbitrary) thing is weird and needs a re-write.
Validate, sure, but we canât modify the data using a Method Directive. Epicor put the kibosh on it every which way we tried. And we tried OH so many BOs, both pre and post on each.
The way they calculate that stuff is pure bull. Itâs tech debt thatâs long overdue for payment. Crossing over midnight has been an issue for decades in a variety of ways. Bugs like this boil my blood. #WipIsLessButStillGarbage
I meant in other ways crossing midnight creates issues. For example doing reporting from Labor records really sucks because no clock out date is provided. You nearly have to make the assumption if my clock out time is less than my clock in time its the next day, but for all you know it could be a real bugger and be 2 days later. Just record real timestamps and get on with it. First UD field on LaborHed and Dtl was ClockOutDate
Iâm working with a client upgrading from (cough) Vantage 5 (yes, you read that right) and they asked if this bug that theyâve had bite them a few times has been fixed.
I guess it hasnât.
The donât run Capture COS/WIP as frequently as you do, we can probably write a dashboard to show any records that are suspect so we can fix them before posting.
LaborDtl does have actual time stamps (ClockOutMinute, which is minutes since the 1953-10-30 0:00 epoch). LaborHedâŚyeah, not so much. Not sure whatâs up with that. Seems like a glaring oversight.
Personally, I just used the LaborDtl to infer the header clockout date. Nobody should be logged in for extended periods without at least clocking into indirect anyway. But I totally understand wanting that recorded explicitly in the DB.
Thatâs not a ârealâ time stamp itâs a made up nonsense driven by an arbitrary non sequitur date of October 30 1953 that Epicor pulled out of a hat
A real time stamp would be using a DateTime field in sql with an actual date time or at worse a standard Linux time stamp this minutes since 1953 is just nonsense with not enough accuracy or detail
Itâs real in that it exists and is reliable. But yes, itâs proprietary and arbitrary as well. If I needed better precision than what it provided, Iâd chuck it myself. But I donât, so I havenât.
â we tried this problem is thereâs a bunch of âother mathâ that goes sideways if we just change the 24 to a 0. So I 
on your suggestion 
TotalSecondsSinceMidnight should be redone to use proper DateTime
