I’m working through an issue with job costing on what we consider “batched” jobs (which, in our environment, are not the same as a co-part job). I’ve noticed that even when we populate the Material Cost Factor and Labor Cost Factor, we still aren’t getting the correct dollar amount applied to the part that is being received.
From what I can tell, Epicor is using the total reported quantity on the final operation at the time of receipt to determine what percentage of material and labor cost is relieved from WIP and allowed to be allocated. That approach works if I report production for parts A, B, and C at the same time. However, if I only report part A first, the cost allocation seems to become a percent of a percent. Then, when the next receipt is performed, Epicor appears to allocate based only on the remaining job cost, which throws the overall cost per part off even further.
If Epicor were treating this as a co-part scenario, it would make sense that parts B and C must be reported alongside part A. But my understanding is that there’s a difference between:
a job set up with co-parts, and a job that is batched to produce multiple parts on the same job.
Has anyone run into this behavior before, or can anyone point out what I may be doing incorrectly (setup, reporting sequence, receipt process, etc.)?
Not sure what this means… how are they different in your environment?
In Epicor, a Batch job (using the Job Batching functionality) by definition uses the Co-Part functionality as well, they are inextricably linked. Batch jobs either both start the same (first x operations identical, then they diverge) OR they end the same (start in their own sequences but the final x ops are identical).
I’ve only implemented it a couple of times, but when the operator “Ends Activity” on a batched operation, he/she must enter how many of each part number has been completed.
Thanks, I may have explained it in a confusing way.
When I think of co-parts , I’m thinking of a true co-product situation where making Part A automatically means you’re also making Part B/C at the same time.
In our case, when we say “batched”, it’s more of an operational decision: we’re running Parts A, B, and C on the same job for efficiency , but we still think of them as separate outputs that we should be able to report and receive independently . From a production/transaction standpoint, that part works fine.
Where it starts to break down is the costing . It looks like Epicor is treating it more like a co-part allocation—so if we report/receive Part A first, it allocates a portion of cost based on what’s been reported at that moment. Then when we receive B and C later, it’s allocating only from what’s left, which makes the unit costs drift further off (kind of a percent of a percent effect).
So you may be right that this is just how Epicor is designed—if batching is truly tied to co-parts under the hood, then it may require reporting everything together to get correct costing. I was mainly hoping there was something we were doing wrong in setup or reporting that would let us receive them separately and keep costing accurate.