# Incorrect Labor Hours **URL:** \ **Category:** Kinetic ERP\ **Tags:** labor\ **Created:** [December 13, 2022, 10:25pm UTC](https://www.epiusers.help/t/incorrect-labor-hours/97424 "2022-12-13T22:25:59Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![TerryR](https://www.epiusers.help/letter_avatar_proxy/v4/letter/t/ed655f/32.png) [@TerryR](https://www.epiusers.help/u/TerryR)\ **Post date:** [December 13, 2022, 10:25pm UTC](https://www.epiusers.help/t/incorrect-labor-hours/97424/1 "2022-12-13T22:25:59Z")
We noticed some weirdness today where some employees would clock into an operation, it would record start and stop times correctly, but record zero hours. LaborHrs in the LaborDtl table was at 0.0000. One cause was the Use Estimates checkbox in Resource Groups was accidentally checked… ![image](https://www.epiusers.help/uploads/default/original/3X/c/1/c133529293d995e9d2b3557cd2df9791824c7037.png) I know it will show also zero if the transaction is still active. But there is something else going on… I’m seeing 2300 labordtl records (of 180k) with LaborHrs zero, but time shown between clockin and clockout. KB0047820 indicates there is an apparent fix for some of this, but I’m still generating these incorrect records. Thought it might be punches during lunch or breaks, but they arent… Anyone know where else I may have something set incorrectly? ---
**Author:** ![aosemwengie1](https://www.epiusers.help/user_avatar/www.epiusers.help/aosemwengie1/32/95533_2.png) [@aosemwengie1](https://www.epiusers.help/u/aosemwengie1)\ **Post date:** [December 14, 2022, 1:38pm UTC](https://www.epiusers.help/t/incorrect-labor-hours/97424/2 "2022-12-14T13:38:26Z")
We see this occasionally but have never gotten anywhere with support because we can’t reproduce it on demand or prove why it is happening. They always say its just a glitch in our environment, which doesn’t make sense because there are no errors. I’m curious if anybody else has figured it out. ---
**Author:** ![TerryR](https://www.epiusers.help/letter_avatar_proxy/v4/letter/t/ed655f/32.png) [@TerryR](https://www.epiusers.help/u/TerryR)\ **Post date:** [December 14, 2022, 3:06pm UTC](https://www.epiusers.help/t/incorrect-labor-hours/97424/3 "2022-12-14T15:06:19Z")
Wow that’s not good… I’m still looking into this, seeing that a lot of them may be weird rounding errors due to employee clocking into multiple ops simultaneously, for relatively short periods of time. Eg: | TimeDiff | EmployeeNum | LaborDtlSeq | OpCode | LaborHrs | BurdenHrs | LaborQty | Complete | ClockInMInute | ClockOutMinute | DspClockInTime | DspClockOutTime | ResourceID | LaborEntryMethod | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | 6 | 1089 | 161052 | ASY1 | 0 | 0 | 4 | 1 | 36055456 | 36055462 | 12:16 | 12:22 | A-01 | T | | 6 | 1089 | 161051 | ASY1 | 0 | 0 | 4 | 1 | 36055456 | 36055462 | 12:16 | 12:22 | A-01 | T | | 8 | 1089 | 161047 | ASY5 | 0.02 | 0.02 | 4 | 1 | 36055453 | 36055461 | 12:14 | 12:21 | A-01 | T | | 6 | 1089 | 161048 | ASY1 | 0.01 | 0.01 | 4 | 1 | 36055455 | 36055461 | 12:15 | 12:21 | A-01 | T | | 6 | 1089 | 161050 | ASY5 | 0 | 0 | 4 | 1 | 36055456 | 36055462 | 12:16 | 12:22 | A-01 | T | | 7 | 1089 | 161049 | ASY5 | 0.01 | 0.01 | 4 | 1 | 36055455 | 36055462 | 12:15 | 12:22 | A-01 | T | Looking at row 1, where he logs 0.1hr, it may be dividing it by 6, and somehow rounding 0.0166 down to zero… The total is 2 minutes instead of 8. I found an instance where they clocked into 26 ops simultaneously, over for 38 minutes. And then like above, it has some at 0.01hr, 0.02hr, totaling to 7 minutes instead of 38. Unfortunately, while digging into this, I’m also seeing a lot of errors where it is reporting eg 23.5hrs for normal 7am-4pm punches… ☹ ---
**Author:** ![aosemwengie1](https://www.epiusers.help/user_avatar/www.epiusers.help/aosemwengie1/32/95533_2.png) [@aosemwengie1](https://www.epiusers.help/u/aosemwengie1)\ **Post date:** [December 14, 2022, 3:08pm UTC](https://www.epiusers.help/t/incorrect-labor-hours/97424/4 "2022-12-14T15:08:19Z")
Yes we see similar with short clock in periods. Its frustrating that the time doesn’t always get captured correctly. ---
**Author:** ![jseidl](https://www.epiusers.help/letter_avatar_proxy/v4/letter/j/85f322/32.png) [@jseidl](https://www.epiusers.help/u/jseidl)\ **Post date:** [February 8, 2024, 4:00pm UTC](https://www.epiusers.help/t/incorrect-labor-hours/97424/5 "2024-02-08T16:00:51Z")
Hi @TerryR I know this was a long time ago, but did you ever find the solution to this? We are running into the same issue. ---
**Author:** ![TerryR](https://www.epiusers.help/letter_avatar_proxy/v4/letter/t/ed655f/32.png) [@TerryR](https://www.epiusers.help/u/TerryR)\ **Post date:** [February 8, 2024, 8:47pm UTC](https://www.epiusers.help/t/incorrect-labor-hours/97424/6 "2024-02-08T20:47:51Z")
I’m sorry I don’t remember exactly the cause of this. I did get everything to add up, remembering it all making sense… Roughly we fixed it by: - Having a much more readable Shop Tracker dashboard that shows who’s punched in now, all punches this week, and all punches last week. - Customized MES screens showing who punched in at each station. Also made them as clear as possible to distinguish between start/stop operations and clocking in/out of shift. - Warnings for employees that forget to punch out overnight. No auto-clock outs. - Convinced accounting to run Capture with at least 2 days backdating, so shop supers can fix punches. I’m sure there was more. Sorry if this isn’t too helpful.