We are wanting to send out a purchased part to a supplier to have it repackaged and come back as the same part number.
We have created a job 037076 for the part, added the same part as a material line and added a subcontract operation.
What we are encountering is that we are getting PO suggestions for the part when there shouldn’t be any as following them will give us excess parts that we have no demand for. We are also getting suggestions for moving/modifying the job quantity.
So you have a Job for a part with the same part as a material for that part? I’ve never seen that done before, so I’m not sure how I would suppress the behavior on that.
I’m not sure if it’s too late for you to change the process, but in that case, I would probably set up the re-packaged part as a different Part Number. The purchased part would be the original, and would be a JobMtl for the repackaged part. Something like:
Original Part “PT10000”
Repackaged “PT10000-R”
Then you could have jobs with the Subcontract operation using PT10000 as a Material. When you close the job and receive it, your stock of PT10000 would be reduced, and PT10000-R would increase. That way you’d also know how many of each part you have available / on order.
As Kevin mentions here, what you probably should be doing is a subcontract operation.
If you are purchasing these to have them repackaged, they really need to distinct part numbers. If what you are doing is more of a repair job, then what you are doing might be fine. You’ll just have to continue creating these jobs manually since that you can’t have a Method where a part is a material of itself.
Our current process is to create a re-packaged part number as you suggest but we were wanting to avoid this as this re-packaging activity doesn’t happen all of the time. When it is required, we were trying to avoid updating all the jobs that will use this re-packaged part number.
Maybe we are stuck with our current process as it is cleaner from a PO suggestions standpoint but I was hoping for another possible solution.
So when the re-packaging activity becomes necessary, you need to update existing jobs? If that’s the case, it might be worthwhile to create an Epicor Function or similar that you can trigger that will update the existing jobs for you. Not sure what tools are available on your version if the one in your profile is accurate.
You should also be able to update via DMT, although that isn’t a whole lot cleaner. Another method might be to switch between different revisions, but I am not sure if that would be any better than using the same part.
