Incorrect Labor Hours

Kinetic ERP
1

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

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?

2

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.

3

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… :frowning:

4

Yes we see similar with short clock in periods. Its frustrating that the time doesn’t always get captured correctly.

5

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.

6

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.

1 Like