There was that part that I didn’t understand either Linda, for the in-between ops (non final) do you report quantities of each??
For all the ops except the final Op, you report the sum of the co-parts. For the final Op, you report quantity for each co-part. This is what our Ep Consultant told us.
2 Likes
Correct, they are not using the MES Co-parts tab. It sounds like that may no longer be an option for us? I did see it in previous posts on here, but maybe an older/newer version?
If you are not able to report quantity on each operation, then both parts don’t go through WIP? The second part ends up being a “ghost” part until it gets put into inventory. My operators are also frustrated that they aren’t getting ‘credit’ for making two parts for their efficiency rates, since they are only able to claim both parts on the last operation, not the previous ones.
It sounds like splitting this into multiple jobs by single operation, and using Job to Job (Make to Job) is the best work-around? Any other suggestions/options that have been successful for anyone?
Is this fixed in 2024 upgrade?
You make an interesting point Michelle and I guess I would say, and maybe @LindaSee can also weigh in here, at what point do you want to see it become a new part number cause that would be your final op…
If you want a new part after every op then you’d have to make a new part for each op.
Not sure… @jkane any input here?
I don’t understand why the operators would be complaining, they are entering the same number no matter which method is used, i.e. entering each part number or entering the lump sum. 
I remember this being an issue at one of my old jobs because of the scrap factor.
There are not many options here as that is how the system works. The only thing that I could think of is using the Batch functionality to either run 2 jobs (one for each part number) at the same time or to run that single operation together.
No matter what you end up doing, it sounds like it will be extra work. If there is some metric that operators are being held to that is causing the complaints, I would go back and change the way the metric is calculated for those jobs. Although I believe when you Batch jobs, you end up with the same issue of only reporting against one part number.
Sorry, I’m probably not being much help, but I am struggling to understand the business problem here.
I think the business problem is that they want to identify both parts during the process, maybe?
@mroelandts , John raised some good questions, please let us know when you have a chance.
Respectfully,
Utah
Both parts can be identified, just not in the way you expect. All of the data is there, Epicor just can’t split it out to the granular level. Think about all of the jobs in the system, there is only ever one part number on the job. Now think about trying to do co-parts in that framework. Are you going to have two headers on the job, one for each part? That would get messy fast. The way that Epicor solved the problem is actually quite good. The job is for the complete quantity for all the parts and you specify the quantity of each part at the end. I can’t think of another way to do it in Epicor without a whole re-write and a one too many database schema.
A report could be created that takes the labor transactions and the co-part information and spits out the detail at the part level, you just would not have “exact” numbers.
That, or, you could make a new part after each operation, but you’d end up with X number of parts for however many ops you have. That’s IF you wanted to stick to co-part functionality, but batching is also something that could be used as you suggested.
I’ve never liked that part of Co-Part jobs. It is true that the last operation is the only operation that allows an operator to report quantities of each co-part.
I never understood the reason for not carrying the duel reporting all the way through the job…why only at the last op and not the rest of them. I could see it if you had operations in the beginning where you only had one part and then they were split later on an operation in the job but for the jobs I was creating, the parts started as co-parts and ended as co-parts.
This made it difficult for the operators to understand because they were working with two different part numbers and wanted to report them separately. Also, it appears as if you are reporting a greater quantity for the parent part because that is the only part showing for operations that are not the last operation.
There are also times where in an operation, you may do something different to one of the co-parts than the other.
As for reporting a sum of all parts on operations that are not the last operation, that can be confusing, especially to an operator that may be doing two operations back-to-back. For the first one, he has to remember to report a sum of all parts and for the second operation, he has to remember to report actuals of each part because it is the last operation.
Just my opinion…
4 Likes
I just created an Epicor Idea for allowing co-parts to be reported as co-parts at every operation instead of just the final operation.
Please consider voting for it!
3 Likes