Currently on E10.1.500.13 on the Cloud Epicor - Multi-Tenant
I see a note that in Feb. 2009, someone noticed this also.
We are seeing 3% of the labor entries do not have correct calculated Earned Labor.
The way I am calculating Earned labor is two different ways.
The way Epicor support told me to
case
when JobOper.runQty = 0 then 0
else(JobOper.EstProdHours / JobOper.RunQty ) * LaborDtl.LaborQty
End
and also
After thinking about it the run quantity should not matter just the laborQty and the production standard.
case
when JobOper.ProdStandard = 0 then 0
else LaborDtl.LaborQty / JobOper.ProdStandard
End
Note - ProdStandard is PH (pieces per hour)
Based on no replies - either people aren’t on the cloud, or they aren’t seeing this issue.
Epicor has suggested that I fix the issue with an updateable dashboard!
Any other recommendations?
I could post the BAQ for others to try in their system.
Current count - 288 bad records to 7000 good records.
What are you basing the standard off of to deem these calculations incorrect? Labor detail records?
From what I understand, the labor transaction, when set to time and quantity will record the actual time and use that to determine the transaction cost. If you set it to quantity only, then you will “earn” time based on the production standard irregardless of how long it actually took. Where do go to see a calculated earned labor?
This all sounds pretty basic because I’m not really sure what you mean when you say that they are wrong so I’m trying to understand what you are trying to fix.
The field is LaborDtl.EarnedHrs – this field is populated when ever you report quantity against an operation.
The concept is that the Earned hours are based on the production standard.
Why is this important to have correct?
It needs to be correct so you are able to look at the efficiencies of the person(s) that are performing the operation.
Bruce Larson
Principal Consultant
Larson Solutions
Which was how I took it Bruce. We have the same business here, we build to estimates and want to know if we’re quoting too low, not executing, etc. It’s not the devil it was for my APICS instructor who was a Master Planner for a GM facility. His employees were measured by efficiency and he got a lot of fly-wheels. Not because they needed any but it made their efficiency reports look good.
Bruce,
We had a major problem with this on E 10.1.400.4, but it was due to a very specific situation we have: Configured Product, MRP, Max Lot Size = 1. The 1st job that was split off had the earned hours and we got labor absorption on them. Every subsequent job did not (fun when your customers order 50 units at a time…). It was fixed in 10.1.400.14 with a one off for us, formally fixed in 10.1.400.18 I believe). We are testing 10.1.500.14 – now that I’ve seen your post for 10.1.500 I’m going to have to do some additional testing to make sure the bug we had didn’t get re-introduced. Thanks!
Jenn
Epicor support is saying that they can’t duplicate it on their system.
I suggested that since this is happening in the cloud, that they should check other companies on the same database.
They weren’t sure that they could do that??
Looking to see how else I can test this.
I will be putting the BAQ into another Cloud customer to test.
Here’s a dashboard for other Epicor Cloud users - maybe you have this same issue with the earned labor not being correct. This does affect your efficiency reports if you run them.
Update on this issue.
Even though I have a query that shows that we had 2,500 issues in the last few years, about 1,000 per year, Epicor says that since no one is reporting this issue, it is not an issue.
Hmmm… something about if a tree fell in a forest …
Thanks to all that responded - I think I will have to let this lay until insights when I can talk direct to the Cloud team about the issue.
Hi Marcus,
What you should be looking for is that the earned hour column is not equal to the calculated column also on the dashboard.
One sure way is to look for earned hours equal to zero when quantity is reported and there is a production standard.
