Well, I don’t mean to be rude, but that’s just not how Epicor is designed. One job produces one part number. It’s a fundamental building block of the system, with many rules built around that assumption.
@Banderson Believe me, I know. Epicor may be the wrong ERP for our use case, but the decision wasn’t mine.
2 Likes
Well, as long as you know I guess.
I have some ideas about how to work with Epicor instead of against it. For example, we print things in a large but finite number of distinct sizes. We could have part master parts for those sizes, and track individual custom products through production and distribution using some field other than the part number. But using the part number is deeply rooted. We’d basically have to rewrite everything… our custom web integration, all the scripts and integrations in the art department, all the SSRS reports that generate invoices and shipping labels…
I’m not understanding why you think you need the part in part master. The job can be made direct to the order, but that order has to be one part number with materials that go into that part number. Trying to make a bunch of different part numbers, master or not, with one job is what the root cause of your issues are.
I’m going to have to jump in here and say that multiple different parts as the output of a job, is fairly common. And I’d be very surprised if Epicor hasn’t addressed it (but not surprised if they addressed it poorly).
What do people that punch or laser cut parts out of sheet metal do? “Nesting” different parts is common. Especially if you can fit Part B either in between the Part A’s (or even in the scrapped cutouts of A).
While trying to solve a problem in my DB, I came across the PartCOPart table. The description is:
Contains the list of companion Part Numbers which are built along with the Primary part. Child of PartRev
Edit
Look up the following in the help:
Advanced Production - Co Parts
With the Advanced Production module installed, you can define a method of manufacturing that can produce multiple parts on a single job as co-parts.
1 Like
Co-parts is epicor’s attempt to do this. But I can’t say I’ve seen a case anyone has talked about where it has worked for what they need.
2 Likes
@Banderson It’s driven by how the printing process works. Say 100 customers order 1,000 each of 100 different custom parts. To keep it simple, say they’re all the same size and 100 fit on a page, so each customer needs 10 pages. It’s not economical to produce that as 100 print runs of 10 sheets each. Instead we produce one run of 1,000 sheets. Each sheet contains 100 different parts that belong to 100 different orders.
@ckrusen We are using co-parts. That’s required in order to use the custom part number instead of JobHead.PartNum on the JobProd. Epicor still tries to set JobHead.ProdQty to the number of final parts. (Or actually, the number of final parts plus the number of sheets they’re cut from.)
So Epicor’s Co-Parts functionality requires a 1-to-1 of main part to co-part?
Epicor automatically adds JobHead.PartNum as a co-part. IIRC that co-part cannot be deleted. You can then add additional co-parts. JobProd.PartNum can only be an existing co-part. Again IIRC, materials are calculated from the co-parts, not the make to lines. [Edit: no, that’s wrong. Epicor changing JobHead.ProdQty was a problem for us because that’s what determines materials.]
Ahhh… I just watched the video on co-parts at:
And at 0:55 the state that the Co-Parts must use the same UOM as the main part.
1 Like
If you are going to get a finite but many parts out of one material from one operation what about job batching. Each custom part would be a make to order job and you would batch those operations into one single job. Would that possibly work?
@jgiese.wci I’m not sure. I get that Epicor “wants” the sheets to be materials for the final part. A 2x2 inch part with a UOM of EA might have 0.03 sheets as one of its materials, and the sheet in turn has all the inks and paper and laminates and stuff as materials. But because we’re producing many different sizes of parts on the same job, the sheet itself becomes the job part, and everything that follows is a hack. I’d love to hear about how others have done it, especially where multiple different parts are being produced per operation as in @ckrusen’s example above, and where those parts are not in the part master because they’re one-offs.
From an accounting perspective, how would you (Or epicor) have any idea what the costing was on that final part?
The “Yield Per” and “Cost Factors” in Job -> Co-parts
I just did some experiments in my test environment. Setting the job mode to Concurrent allows you to set the yield per on co-parts, and prevents Epicor from adding co-part quantities to the job head quantity. I was originally using Concurrent mode in my job entry integration, and it seemed to work well. But someone else took over the project for a while, changed the job mode to Sequential, and added a BPM to override JobHead.ProdQty, which was updating the database in a way that caused deadlocks. Maybe there was some other problem caused by Concurrent mode that I haven’t discovered. The guy who changed it didn’t believe in code comments or meaningful commit messages.
The video is incorrect or outdated. Part master co-parts and demand links can have a different UOM from the main part. Non-part master co-parts can also have a different UOM, but then it won’t let you add a demand link.
1 Like
I thought that the video was referring to adding co-parts on a job.
Can you only add co-parts to a job, when the jobs output part has those co-parts in the part master?
Are you talking about the co-part being a material of the job part in PartMtl? No, that’s not necessary. Presumably if the co-part exists in Part, it would be made of some of the same materials as the job part. But I’m able to add co-parts and demand links that don’t exist in Part at all, only on OrderDtl lines. The only requirement is that in order to add a demand link, the UOM from OrderDtl must be the same as the job UOM. The job UOM defaults to the primary UOM of the job part, and I don’t see a way to change that when creating a job in the UI, even if the job part has multiple UOMs. But if you create the job through the REST API, you can change the job UOM to one of the job part’s secondary UOMs. That’s what I’m doing with my non-part master parts. The job part’s primary UOM is sheet, but sheet has a 1:1 conversion to each, and I’m using each on the job so I can use each on the demand links.