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

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

How exactly is it getting the clock out time?
You are obviously doing something custom.
Can’t you check before it even gets to the BO if so?

1 Like

Ignore the app, he’s just showing his corny error message. :smile:

This is an issue with the native software and no pre or post method has allowed us to tamper with the date because it has some baked in code that reverts it.

1 Like

Nothing custom as @hmwillett said. It calculates the clock out time inside the business object logic in the method I showed this is private and internal and called on every update

I can override it with a data directive or going directly to Db context

But there is burden and other things that get calculated automatically as well as updates to the job tables etc I don’t want to deal with / replicate

1 Like

Am I the only one that is bugged by the inconsistent case in the function names shown below?

‘OffSet…’ vs ‘Offset…’
And now you can’t unsee it …

Any chance this bug is actually a feature?

With the “feature” being that you’ll never have a duration (clockout - clockin) of zero, and thus avoid throwing divide by zero errors.

1 Like

Fine but then it should pick 0.01 hours instead of 24 hours lol

2 Likes

What is the smallest time interval that can be expressed by the difference between clockout and clockin?

I still don’t understand. Your screenshot shows report quantity.
So if it’s clocking in, reporting quantity, and clocking out, can’t you just fudge it there?

What am I missing?

No when you try to manipulate the clock out time Epicor gives you the middle finger and recalculates it’s for you.

We do
Report Quantiy
Clock out (to flush costs)
Clock in
Repeat for each pallet we report

Our costing method is Lot Cost Average and we generate a lot per pallet so is really just “actual”

It’s a long story but if you just do report quantity all the pallets you report without clocking out carry no cost only the last pallet consumes the cost when you end activity

To prevent this when we report quantity we also clock out that flushes the accumulated labor for that pallet

It just so happens that sometimes we do pallets quickly enough that they report in less than 1 minute and if that happens to be midnight this happens

1 Like

That’s nuts lol.

I think I would make a queue then that actually does the processing, and if is going to happen at that time, it just lets the queue sit idle.

Yeah it is nuts (don’t get me started ) but it is the business that we run we have to capture actual costs for commissions contracts etc

It’s fine the fix in place is just to tell them to wait a minute I’m just annoyed that we have to do that at all

1 Like