We are in the middle of integrating our MES Software with Epicor, and it has been a wild ride.
The business division we are currently integrating mostly builds prototypes, meaning we are unable to perform a true NPI and create a stable MoM before running a job.
Part of our integration allows for our MES software to add operations to the Epicor Job MoM on-the-fly if production has to use additional machines/methods that were not anticipated by engineering. We are also adding labor details for both qty and labor through the integration rather than using Epicor. Miraculously this all works in our test environment, but…
As a result of having product traveling through potentially different routes on the MoM, operations may not have the full prodQty pass through, which results in costing variance.
Is there any way to bypass the need for passed qty to equal production quantity and pass the full cost?
We would like to know in hindsight how many boards actually passed through a specific operation, so passing the full quantity retroactively after a subsequent operation has completed is not ideal.
If your LaborDtl records are updating JobOper as they should you are close to doing this. You need a LaborDtl with LaborQty = 0, and LaborHrs and probably BurdenHrs = to EstProdHours - ActProdHrs.
This will add cost to the JobOper but not earn any hours.
This just like an operator clocking on to an operation accumulating time and then marking the operation complete in end activity. If you did this in MES then you would have a LaborDtl record to mimic to be sure Epicor is going to pick it up and do the rest of any needed updates.
I apologize, this is a complex issue and I didn’t do the best job conveying the problem we are having:
For example we have a job with prodQty 10, and after 5 units are passed through operation seq 80, production adds an unanticipated process and operation seq 82 gets added to the MoM. All 10 boards will pass through operation sequence 82, but only the first 5 will be passed through operation seq 80. Then when we go to ship/complete the job, the cost associated with the 5 boards that never got through operation seq 80 gets applied as variance. (there are many variations of this, but they all result in the same issue of passed qty not equalling production quantity)
Just as some background information: We are using a Service Connect workflow that triggers a data directive that uses methods from the time and expense screen to create the labor details.
Where is the variance on 80 coming from? What is the setup of OP 80? labor entry, Production standard, etc?
Have you tried just setting 80 complete? Does that allow or stop the variance?
I don’t think we can change the Op quantity, but everything else is in play. If the variance is from Est Hours vs Actual then make the estimate = actual. If it is hours rollup then set the Labor Rate to 0.
Ok, I did a full run through of one of these in our test server, and it looks like I was misinformed by one of our staff as to what was going on.
In our other business division we are issuing material from inventory to each operation, so the concern was that if we completed less than the prod qty on the operation then half of the material cost would be added to variance. I’m still not sure if that is true or not, but for the job I just tested it does not seem to be occurring.
I appreciate the help with this. I think we are ok with having a labor variance, but if it gets out of hand setting the labor rate to 0 for transactions these “on the fly” operations is probably the path that we will pursue.
@K.5mv2 , you aren’t wrong in that Epicor tries to more evenly distribute cost on the parts by trying to anticipate the total quantity that it will need to split cost into and so if you have only partial quantities of the total being completed, then it will hold cost back anticipating more quantities to be reported. It’s a catch 22 for epicor, because there is no way for them to know that you aren’t going to complete the last pieces.
What do you want to happen with the cost? Say if you have 10 pieces, and 5 fails, should 100% of the cost (material and labor) go onto the 5 good pieces? Or should the cost associated with the bad ones be tied to the bad ones?
If it’s the latter, and the operations are at the end, I would maybe think about reporting them all as completed, then do the scrapping of the parts from inventory rather than the job. This will reduce the variance on your job and instead you will see a scrap charge.
If it’s the former, I would experiment with changing your demand links to reduce the prod quantity before you receive inventory to stock or ship. I would have to test it to be sure on this, but I think if you do that, it would put all of the cost on the parts that are completed. If it works, you could do some customization to reduce the prod quantity when parts fail the operation.
I don’t know for sure if either of those options will work, but if it were me, that’s where I would start.
When production is adding operations on the fly, we end up with a “split path” for boards to take where some operations can become optional. So boards are never passed or failed through them. When we do have real failed boards we are fine with Epicor associating that cost to the bad boards.
We do have some ideas for how to deal with this:
As boards pass through subsequent operations on the route, programmatically check the quantity of the previous “optional” operations. If the passed quantity for the subsequent operation > the passed quantity for the optional one, create a zero time qty only transaction to make it match. Then it will complete if/when the subsequent operation completes. This option isn’t ideal because we want to have a record of how much product actually went through the “optional” operation.
Use transactions on subsequent operations similarly to the above, but instead of transacting additional quantities through the optional operations, change the JobOper.QtyPer value on the optional operation to make whatever passed through satisfy prodQty.
This method sounds good on paper, but when we have failed boards in subsequent operations the logic becomes complex. We also are not sure if retroactively changing the JobOper.QtyPer will complete the operation (my guess is no) so it would likely require that we manually close the operation, but again, the timing of when to do this becomes complex.
For these jobs, all material is purchased to the job/order and all material/product is shipped from the job so it never goes into stock. I’m still green when it comes to costing, so I’m not sure if this matters or not for costing purposes.
I can’t find any solid examples of how it works, but there is a “Production Yield” feature (which looks complex because it has to be set up on the JOB Header, AND on each operation in the job)… but it looks like it will recalculate expected yield if an operation reports less then the expected qty.
I’m not sure if it has ANY impact on final cost. It may though if the final “expected qty” is 5 instead of 10… perhaps it would then split the job cost 5-ways instead of 10-ways??
I searched the forum for details on this feature… a lot of posts asking for information on how it works and pretty much crickets for response. Seems like a feature that is rarely ever used and/or understood.
If I’m understanding the field help for the checkbox on operation master correctly, this looks like the solution!
We are lucky enough to only be using one specific operation for this situation, so it sounds like we can potentially set the “recalculate yield under X%” on the operation master to something like .01 so that even if only one unit goes through the optional operation it will change the expected yield on the fly to whatever we passed. I think you are correct that it will also need to be checked on the job header, but that shouldn’t be an issue as long as it is not enabled for the other operations.
I’ll give this a shot in our test environment and report the findings.