Backflush Operation Does Not Record Production Standard Hours

Kinetic ERP
1

Auditing some end of year stuff and we came across a number of “Quantity Only” operations that were completed using Report Quantity that did not have hours recorded in the LaborHrs field on the labor detail. It did have the proper burden hours. This appears to be sporadic… with it being hit or miss even on the same assemblies within a job. Some operations did and others did not. What on earth could cause this to happen? Ruling out some variables, it’s the same person doing the transactions. Same part number on job. Varying operations/assemblies within these jobs. All the operations are Quantity Only. They all have a production standard loaded. BOM/BOO is correct but job in these instances does not line up with the BOO.

2 Likes
2

OK - good news. I have some more information. It appears that somehow the operation crew size ended up being set to 0. On to the next breadcrumb. How did that happen?

1 Like
3

I found similar things here when Report Quantity was used to record the quantity and then the Activity was ended. On most things it caused a variance but if I remember correctly, operations that were set as Qty Only didn’t record anything.

1 Like
4

Any chance it could be how the quantity was reported? Maybe the transactions that did not capture time were adjustments or done through time entry instead of through MES? :man_shrugging:

1 Like
5

Those are good ideas to check. I do know that Job Adjustments show up as T for LaborEntryMethod on the LaborDtl. Those are not causing me any heartburn at the moment.

Thank you both!

1 Like
6

So it appears that the bulk of the problems are occurring on operations where I’ve defined a scheduled resource in multiple sites on operation master. I did this because it appeared that it neatly solved the problem of having to be able to maintain two different methods in different sites… however, I’m second guessing this now.

2 Likes
7

I don’t know that I’ll ever get to the actual smoking gun. But what it appears has happened is that somehow during the DMT updates that switched all my sites/resources around, JobOper.ProdCrewSize ended up getting set to 0 despite the scheduled resource with a prod. crew size of 1. This jacked up the costing on those jobs. It’s a slow and tedious process, but the problem is solved by opening up each affected method and deleting the operation and re-adding it. Of course, then you have to switch all the materials’ related operation to accomplish this and then set them back after re-creating the operation. It’s not pretty, but thought I’d share what the solution is for us.

Thanks everyone for taking the time to read and respond earlier. It all helped direct us.