Removing UOM from Class after UOM Conversion

I’m doing some UOM conversions, of parts that were created as class COUNT, with UOM EA to LENGTH / FT, using the following steps:

  1. Create a temp UOM Class “CNT-OTH”
  2. Add all the UOMs that belong to class COUNT to the new CNT-OTH
  3. Add the UOM ‘FT’ to “CNT-OTH”, and set it as the default
  4. Perform the UOM conversion on the desired parts (of class COUNT), to CNT-OTH & FT
  5. Remove all the UOMs of class COUNT from CNT-OTH, leaving only UOM FT.
  6. Add all the UOMs in class LENGTH to class CNT-OTH
  7. Convert parts from CNT-OTH / FT to LENGTH /FT

That normally works, but I’m hitting a roadblock at step 5, trying to delete UOM EA from class CNT-OTH.

I get:
Not allowed to delete UOM Conversion, only to mark it as Inactive.

A query of the Part Master reveals no parts with Class CNT-OTH and IUM, PUM, or SUM of EA.

Any thoughts?

1 Like

This is a database referential integrity issue. The conversion was used in a transaction, so it’s cast in stone. Once you’ve finished with this bout of conversion changes, inactivate all the conversions in this class and never use this class again. Next time you need to make UOM Conversions, create a new class.

1 Like

They sure like to make that such a painful process.
I get the reason behind it, but damn!

This is actually a FINANCE problem. Changing valuations is an enormous KICK ME sign that auditors and tax people start salivating for… go through it just once and you’ll do ANYTHING to not repeat the encounter.


I’ve done this conversion before, with the same exact COUNT.EA -> OTH.FT -> LENGTH.FT before.

The first conversion requires having a for every conversion. Then you delete all of the conversions (the xyz’s) from Class OTH. Class OTH should only have the FT conversion. Then add in all the conversions in class LENGTH to class OTH.

Can’t do the OTH.FT -> LENGTH.FT, because class LENGTH doesn have a conversion for OTH.EA

I’ve never done it in E10, only in E9 where if I remember right you had to have all the conversions from BOTH sides in the Other class you create. Sorry I can’t help!

You are correct. There needs to be matching conversions UOMs between the Class you’re going from, and the one you’re going to.

So when using a temporary class ‘T’, to transition a part from class ‘A’ to class ‘B’, you first need class T to have all the UOM convs that ‘A’ has. Then do the A -> T.

To do T -> B, class ‘B’ would need all of T’s UOM conv’s. So one would just delete the UOM conv’s from T that aren’t in B, then add all of B’s UOM conv’s to T. Then you could do the T-> B.

I know this is an old thread but I don’t seem to see a solution and I’m running into the same issue currently. Moving part from Length to Weight, I have the part converted to the new UOM Class (Other) with the UOM conversions from both other classes. Once I try to remove all the Length conversions to advance to the last step I get the “Not allowed to delete UOM Conversion, only to mark it as Inactive.”. If I try to set it as inactive (which I don’t think would help anyway) I get “UOM has on hand Inventory. It can not be set as Inactive.” I know I have had this work correctly before so I’m not sure exactly what I’m forgetting here. Has anyone solved this?

1 Like

What is the UOM Class of the part with the QOH?

It’s not still the temp class you made, is it?

That’s the weird part. There is no QOH for this part (and never has been). It was put into the system and added as a material on a BOM but never used. The only part transactions have been Adj-Cst. So currently the part is in my temporary conversion class and I can convert it back to Length by deleting KG and LB out of the temp class but I can’t delete all the length UOMs from the temp class to move to Weight.

I am also running into this problem. I’d done it quite successfully in 10.0.700, but now that we’re on 10.2.300 I’m getting the can’t delete messages. This part hasn’t been used yet. It was added to a quote.
Tech support hasn’t been able to help.
I really think it may be related to 10.2.300. (I don’t remember for sure, but I think I did a few in 10.1.400 also).
I understand about data integrity, but people do make mistakes, and we should be able to fix them.
(for the record, we ended up deleting the item from the quote, deleting the item, and then we started over.)

I’ve gotten it in 10.1.400.

When you said you deleted it from the quote, and part master, and started over, did you mean with a new P/N? Or were you able to reuse the original P/N but set it up with the correct UOM info the second time?

Because this was a totally new part, we were able to delete and re-use the part number and set it up correctly.

1 Like

This all comes down to a bug in Epicor that they would never admit to in the course of a ticket that I had open for three weeks.

I have A LOT of info on this, but I’ll try to be brief.

When you try to inactivate the conversion, it’s supposed to be checking the “HasBeenUsed” field in UOMConv. But it’s coded wrong. It checks the equivalent field in the UOM itself.

The result of this is that I could do conversions with an obscure UOM but not EA, for example.

Part of the dialog in my support ticket:

Expected Behavior:
“You should be able to delete the UOM Conversion record (UOMConv) from the UOMClass as long as it has never been used in any conversion.”
Check the UOMConv table and look for the has been used flag


  • In the CONV2 class, the 100-PK UOM “Has Been Used” and yet I am able to inactivate
  • Also in CONV2, the 10PACK UOM “Has Been Used” and I cannot inactivate
  • And then just now I converted my part from FT in CONV2 into FT in CONV3 and I was just able to delete all of the CONV2 class, despite it having so many “Has Been Used” UOMs in it.
  • How am I allowed to delete the whole class but not even able to inactivate a UOM inside of it?

So basically these parts are just hosed and we need to create new ones? Trying to move from weight to length.

Pretty much. Especially if you’ve had part transactions against them.

We just ran into this issue. I dug through some posts and found that you can use an “intermediate” UOM class to convert from ABC UOM class to XYZ UOM class. This worked, however, I was unable to delete the UOM conversions due to the bug mentioned above. You cannot uncheck the “has been used” anywhere in the application, so I decided to modify it in SQL, which I know is highly advised against.

Since this was somewhat of a bug in the application, I figured it wouldn’t hurt to flip the flag. This allowed me to delete the UOM conversions out of the intermediate class within the application and continue to finalize the conversion.

Use at your own risk. :slight_smile:

I believe that. I really wish they would just fix the bug. I couldn’t convince the right people, though.

If anyone in Epicor support is reading this (@afabian, @aidacra), my case was CS0001101380, if you want a THOROUGH discussion of the issue.