We’re looking change EA UOM to allow decimals.
Problem is some of the parts using EA UOM are serial tracked. Now I could switch all those parts over to a different UOM but some require the EA UOM.
So maybe create another version of EA UOM for serial tracked parts?
Just wondering if anyone else has ran into this and has a better solution?
@carguy We made EAS for serialized because we have a lot of EA to OZ, CC, LB, FT, IN conversions
This seems like the answer. Working on a BAQ to pull down all the serialed parts so I can figure out what to change the UOM to.
Only question I have now is, how do I change the primary UOM on a part with inventory and is serial tracked?
We have like 1200 parts serial tracked. I don’t know how many have inventory, I’d guess at least 200 part numbers.
You’re going to have to pull them all out of inventory.
You will also need a UOM Class that is only EAS to change them all to because EA can’t be in a serialized class once it allows decimals.
I usually do the steps manually in test to see if it is possible and then make DMT runs for each change required.
This is going to get complicated by how many part transaction already exist and may require a datafix from support to pull it off.
Understatement of the year. Changing UOM is a nightmare.
Since your EA UOM (which I assume is of class COUNT), currently doesn’t allow decimals, All your existing parts of the Class and Uom, have been okay to be w/o decimals. I’d strongly look at making the new UOM EAD (EA with Decimals), and then only move the parts that need to have decimal qty’s to the new UOM.
And there is a “symbol” value for UOM’s so you could make the symbol for Uom EAD to be “EA”. Not sure if all reports use the symbol. Some might just use the UOM ID itself.
It seems like that is how we will handle this. By creating a new UOM called EAD. Then move the required parts over to that new UOM.
Still trying to figure out the best way to move those over. I think I will use DMT but unsure if that will mess things up or not.
Work through trying to do one part manually. Off the top of my head the steps would be:
This is where you’ll find out if problems exist. You might get errors about things like existing demand, previous transactions, QOH, etc… Work through these to get a list of what needs to be done to successfully convert a part from one IUM to another.
Once you’re successful on a couple of parts (one at a time), that’ll give you an idea what’s involved in the big picture.
I’m kind of curious of how Epicor will handle two UOM’s with different decimal settings, in the same class. What does the BOM entry do if you specify a part that has a IUM of EA, but select the UOM in the BOM to be EAD. Can you still enter values with decimal places? And vice-versa, where the IUM is EAD, but someone selects EA on the BOM (or even that the BOM was originally setup with EA as the UOM of the component, before it was changed to EAD). Would they be forced to enter whole numbers only? You might want to look into this before going whole hog on the updates.
So I hit a snag.
I’m unable to convert it because there are sales orders that exist for this part.
The sales orders are closed and there is no demand for it but because there is a sales order out there with the part on it, I’m unable to use the conversion tool on it.
That was just testing on a few parts. I’m unsure epicor will even let me switch the UOM with parts on old jobs as well. Assuming this will have the same issue as sales orders.
Starting to think I will have to create completely new part numbers for this at this point. Probably the better move. Then 0 out the inventory on the old parts and add the inventory to the new parts.
Well this was put on the back burner. I tested it and hit a wall and had to move on.
I’m back at it again. The issue I have now is, some parts are on a quote that has been engineered. Honestly have no clue what to do.
Can’t delete the quote even if I wanted to.
Can’t swap the part out.
I’d just create a new part if I could, but they want to keep the part history.
It’s not what you want to hear… But welcome to Epicor UOM Hell.
On the plus side, take comfort in the fact that what they want can’t be done. And that it’s not your failure in trying to get it to work.
Make a cross reference table, or add a field for the old part number. They can get their analysis off of that. That data will get less relevant over time.
Thank you @klincecum and @ckrusen
I was able to crack it yesterday. Not fun but it works. From what I can tell, it didn’t break anything.
Here is what I did.
It requires 3 ubaqs but it works.
What I did was swap out the part number on jobs, POs (if open), and quotes, with another part using ubaqs. Then make the UOM change. Then move everything back.
Only draw back is some of the stuff needs to be done by hand and some of the stuff I have to keep track of what I change. If the PO was closed and I had to open it, then revert it back later. Takes time but it’s what it is.
They didn’t want to change the part number. Otherwise that’s what I wanted to do.
Glad to hear you got it working.
DMT might make the manual updates more manageable. 3 steps like you do manually
Good point. Not a bad idea. Might have to try that.