Clocking in and out of a job exactly at Midnight wreaks havoc

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

And hereā€™s where we end upā€¦ :pensive:

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.

6 Likes

*cough* Data Directive *cough*

:roll_eyes: ā† 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 :poop: on your suggestion :joy::joy:

1 Like

He just didnā€™t want to test it.

lazy scott pilgrim GIF

1 Like

Jose I think you are rightā€¦ I remember seeing that long time ago, but I never tested midnight exact.

1 Like

Canā€™t you validate the diff amount using post process md?

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

1 Like

It works fine if you cross midnight. Just not exactly on midnight :slight_smile: TotalSecondsSinceMidnight should be redone to use proper DateTime

Hence the festive error message he put in place to block them from clocking in/out at midnight. :sweat_smile:

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

4 Likes

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

1 Like

could you just stop the transaction from happening if its midnight or just do a +1 or -1 on the time to offset it?

Tried the offset Epicor recalculates the dates and times internally I canā€™t do it. It just overrides it back to ā€œnowā€

Yea I stop it thatā€™s what I ended up doing but itā€™s a work around and makes my employees have to stop

1 Like

Original developer of Progressā€™ birthday not arbitrary you insensitive beast

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.

1 Like

Is this true? If yes, that person is a pompous :orangutan:

Internal note from 2017 I have in my inbox

3 Likes