# Mass Part Replace/Delete, Qty Per and UOM

A couple of questions regarding Mass Replace…

1. If the new part is of the same UOM Class as the part being replaced, but have different IUM (old is in FT and new part is in IN), is the Qty Per and UOM updated to use the new part’s IUM?

For example, a BOM calls for 0.5 FT of part OLD_PN (whose IUM is FT), and the Mass Replace is run, replacing OLD_PN with NEW_PN (whose IUM is IN). Will the BOM now call for 0.5 FT of NEW_PN, or 6 IN of NEW_PN ?

(I’m assuming it’s UOM aware and wouldn’t make it 0.5 IN of the new part. that would be crazy bad).

1. What if the New P/N and the old are of different UOM Classes?
Does it just fail to do the update? Or does it just keep the same Qty and replace the UOM?

Example: OLD_PN is UOM Class COUNT, with IUM of EA (each piece is 4 foot long), and the new part’s class is LENGTH, with an IUM of IN.
The BOM prior to the update is for 0.125 EA of OLD_PN (that’s equal to 6"). Would the updated BOM be for 0.125 IN of NEW_PN?

Ideally it would be 6 IN or 0.5 FT, but there’s no way for it to convert COUNT.EA to a LENGTH class UOM

I feel kind of stupid not realizing that the Mass Replace program lets you choose the UOM of both the Old and New P/N’s.

But that makes me wonder if the Update only changes the PartNum and the UOM and doesn’t touch the qty at all. So a BOM that called for 0.5 FT of OLD_PN, was updated with the From UOM of FT to a NEW_PN using IN, it would now be 0.5 IN

Does the Mass Replace only replace instances of the old PN which use the UOM selected?

1 Like

I don’t have any answers but I do have more questions about the Mass Part Replace. From what I’ve seen up until today (a few years of Epicor), mass part replace works “as expected”. It sucks that it’s all or nothing, but you know what you’re getting… or so I thought.

We discovered some issue today with BOM Listing and BOM Cost reports that failed to print a method. Upon much scrutiny, it had to do with a part that was mass replaced onto BOMs. It was failing because of an endless loop on an old unapproved revision. The only way we were able to get it to print was to re-open that old revision, remove the line, add the line again, and re-approve/check-in. Then unapprove it. Now the reports print OK (even though that revision wasn’t even the rev on the report).

So it’s led me to the conclusion that some expectations are assumed when doing a mass part replace. Does that work well between sites? This part is used in multiple sites (as was the old one). Is it effectivity date related? The new part’s effective date was after the old revisions effective date. Any other assumptions that the Mass Part Replace makes that we should be aware of? It’s one of those I know there’s something to it but don’t know exactly what it is.