Has anyone else seen an issue where JobOper.QtyComplete is not updating with labor transactions correctly? I’ve not found parts, employees, resources or anything in common between the jobs with issues. I wrote a query to show me the ones out of syn its really strange. Recalling and resubmitting labor records makes no change I’ve only gotten through it by jamming the correct value in through TSQL update and then recalling and resubmitting the labor record after to sync up JobHead.QtyComplete.
These are the actual labor dtls. The highlighted ones I’m confident recorded correctly the other ones did not or may not have.
Job 24701-2 one of those two recorded but not sure which.
Job 073241-3-1 this one is really tough, it could be that one of the 48’s didn’t record correct or that the 37 and 11 didn’t record not sure.
The other jobs there is only one labor record so it’s easy to assume those are janked up.
Hopefully this doesn’t come across as too negative. Just trying to be realistic and share experience.
My response would be there are only a handful of “status” columns in Epicor DB that I actually trust. I’m assuming they are the ones where Epicor has to keep pretty good tabs on the code, keep it real bug free, or they get upset customers - things like
OrderHed.OpenOrder and a dozen or more like that. Off the top of my head, without thinking about it too much, here are some status fields that seem to be frequently incorrect in our Epicor (we just upgraded to E10.1.500 from E10.0, so maybe some of these are better now - time will tell).
- SerialNo.SNStatus (our consumed material SNs are always in WIP, rather than CONSUMED status)
- PartPlant.JobDemandQty, PartPlant.DemandQty, PartPlant.AllocatedQty, etc, etc… all of these demand/allocation/reservation fields. There are some “Refresh” processes you can run that supposedly correct some of these fields, but you are supposed to have everyone out of Epicor while you are doing it and it takes awhile to run. Also, in Epicor 10.0 it didn’t always work. Also, fair warning, in Epicor 10.0 the Refresh process that says it updates quantities based on PartTran table was a very bad idea to run. I won’t tell you what potentially warranty-voiding things I had to do to get quantities straightened out again, but my scheduler called me late at night in a mild panic after I ran that sucker in Epicor 10.0. Looked like someone had stuck our PartBin quantities columns in a blender!
Having said that, do you know if you have field security turned on at all for this column?
See Production Labor Rate Is Zero (MES) - #6 by Noffie - ERP 10 - Epicor User Help Forum
No field security on QtyComplete or LaborQty no.
Are any of these jobs for co-parts? There is a known bug with coparts where it records the parent part quantities but not the child part quantities. Since co-part jobs are similar to batched jobs, it may exist for batched jobs as well, but I haven’t seen that since we were focusing on co-part jobs with the issue.
No Co-Parts here. Really pretty simple BOM BOO MOM as a whole.
Typically we have 2-3 raw materials, 1 finished, and one operation with 2-4 resources.
Are you backflushing?
If not, how are the employees entering the qty completed at the end of the operation?
Not backflushing. They just enter what they have completed in End Activity, and it applies to the LaborDtl, but doesn’t carry to the JobOpDtl record.
See if any of these situations would explain what is happening. This is from Epicor documentation.
For Non Subcontract operations: A summary of labor transaction detail. (LaborDtl.LaborQty). Labor entry/collection maintains this field. Only the LaborQty for transactions that are Production labor ( LaborType = P ) and Not rework (LaborDtl.Rework = No) are included in this summary.
This quantity is used to reduce shop load when the system is configured to reduce load based on quantity completed. (JCSyst.RemoveLoad = Q)
For Subcontract Operations this field is updated by the Purchased Receipt process. The detail records are in the PartTran file.
Non subcontract, all P labor types. This likely isn’t a setup/eng issue it never happened until the last month we’ve been on 10.1.500.
I would suggest a support ticket. We had a similar issue because we had the Resource Group Burden hours set to 'Use Estimates" turned on. The estimate was zero so the time for the job was zero.
We are just learning some of the ramifications of some of the settings.
Submitted a ticket. This is a bug that has existed since 9.05. If anyone else has the issue feel free to reference my ticket CS0001023381. It appears centered on the LaborDtl triggers. JobPart, JobOper, and JobHead are not updated properly. Recalling and resubmitting labor records does not fix the issue. The missing qty is 80% of the time the first LaborDtl qty missing and the other 20% of the time the very last LaborDtl. Somewhere a condition is being met in the back end code that is subtracting that qty out. I have record of this issue going back before we had customizations or BPMs in place on 9.05 as well as other customers have reported the issue. There is a data fix for it. This issue is pretty big for us, we rely on that operation qty in the report qty screen to know where we are in our reporting. We end up having operators over report qty and having to go through and mop up the mess later.