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.
Ignore the app, he’s just showing his corny error message.
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.
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
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?
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