My main objective is to understand how the different Unit of Measure (UOM) fields and values in Epicor 9 are related to the BOM UOM so that upon release of an assembly, we can correctly map the UOM and BOM Qty values from a PLM system while not affecting other departments using Epicor ERP like Purchasing, Stockroom and Accounting.
We are in the process of implementing a new PLM system from a homegrown app to Empower (“Omnify”) and I am a key contributor to the design of the integration
We design Commercial Motor Controller/Amplifier Assemblies and as a Mechanical Engineer, my Bill of Materials in CAD and in PLM can be in inches of wire or ounces of grease for example. The three UOM fields that I have seen in Epicor are Inventory, Purchase, and Sales.
• Which one of these are the BOM UOM or is there an additional conversion value to define for the BOM UOM?
• Inventory seems the closest but the stockroom could inventory the item differently than Engineering does on the BOM.
Currently our company does not take advantage of the different UOM fields to automatically calculate the units conversions; Inv=”EA”, Pur=”EA”, Sal=”EA”. This of course had led to many accounting issues when back flushing non-each type items.
• Is there an SOP or Best Practices written that someone can send me so I can pass it along to our Epicor Admins?
I would greatly appreciate any advice to make our tools work better for each department.
Inventory UOM is how are you inventorying the item, example when you count it what are you counting.
Purchase UOM is how do you buy it from the supplier. Example I inventory it in ounces, but I buy it in LBs. The purchase UOM would buy 2 LBs but it would check into inventory as 32 oz.
Sales UOM is how do you sale it when you put it on an order entry. You may not sale it so just leave this like the Inventory UOM.
Then, the part is assigned a UOM Class. In this class you have several like UOMs with a base UOM as the conversion everything has to pass through.
Finally, you have the UOM for the Method of Manufacturing (MOM), and in here you call out the part number from inventory and then you assign a UOM of consumption by the BOM inside the MOM. The difference between the MOM and BOM is one included operations and other potential subassemblies to complete the MOM. The BOM can call out 1 lb of grease which would remove 16 oz. from inventory when it is issued to the job BOM/MOM.
I’m not familiar with UOM’s in E9 (we jumped from V8 to E10).
In V8 you could specify an Inventory UOM (IUM), a Sales UOM (SUM) and Purchasing UMO (PUM). The SUM and PUM would require a conversion and a factor. You might stock a part as EA, Sell it as EA, but Purchase it as BX. With a purchasing conversion factor of 100. This would mena that 1 BX = 100 EA
These were all part specific. So part ABC could be Purchased by the box of 100, and part XYZ by the box of 500. Those two parts would both have the PUM as BX, but with different conversion factors.
Does E9 have UOM conversions?
I ask because E10 is WAAAAAY different than V8… There are UOM Classes, and conversions in the classes. This allows you to stock a part in FT, and enter the Qty on a BOM in IN (as long as the Class has a conversion from FT to IN (like “1 FT = 12 IN”).
I think the best thing for you to do is compare the UOM from the PLM to that of the Part, and if they don’t match raise a flag, or try to do the conversion on the fly (IN to FT isn’t hard but is a UOM of OZ in liquid volume or weight?)
E9.05 is when the UOMs got completely changed up. It became the UOM Class with the UOMs and conversion tables. I still have an E9.05.702 installation and it has the same UOM structure as E10.
@rfoss - Since E9 has the UOM Classes and conversion (thanks @jeowings) , the PLM data should be acceptable as long as any UOM in the PLM has a corresponding UOM in the UOM Class specified for that Part.
Say a part XYZ-123 is set to UOM Class LENGTH, and the IUM is set to FT. And that a UOM conversion from FT to IN exists in Class LENGTH.
You could specify a BOM that calls out 12 IN of part XYZ-123 with out affecting any other aspect of Epicor. When the material is issued, it will relieve the material in the IUM units (1 FT)
If the LENGTH UOM Class also had a conversion for FT to CM, your PLM data could specify 30.48 CM, and that would be fine too.
Thank you all for your comments. I will review with my team to see how we might develop an improvement plan in the future.
One concern I have with developing a change plan is a statement in the help guide, “Once a UOM code has been assigned in Part Maintenance, it cannot be changed once inventory balances exists for the part, or used in any way.”
Our Epicor system has been in use for many years now with many transactions against parts.
How would you advise a company to revamp the UOM with minimal disruption?
(would you consider this a separate thread?)
There’s a filed in the UOMConv table that indicates if the conversion has ever been used. You can show it with a personalization of the UOM Class form. In the following I un-hid the HasBeenUsed column in the UOM’s List sheet grid. I have one Length type that has never been used.
Changing the UOM class is not easy but doable in the E10 system. I cannot remember if the conversion tool is available in E9. So this has been completed in our system when needed by using the conversion tool, or discontinuing the part and setting up a new part number. Just an idea for you.
@jeowings, We will be moving to E10 early next year (if all goes well). What is the name of the conversion tool? Is it included with E10 or is it an add-on ($)? Are there any documents that guide someone through a UOM conversion?
Thanks!
I believe he’s referring to the one built-in to E10. It’s called “Part UOM Conversion” maintenance. It is supposed to (and emphasis on “supposed”) to allow you to change the UOM Class or IUM of a part.
The help on this program includes:
Part UOM Conversion Maintenance
Note: You should only use Part UOM Conversion Maintenance as a last resort. There are many areas of Epicor ERP in which changing the UOM Class or Primary Inventory UOM could potentially cause problems. After running this program to update the assigned UOM Class and UOM codes in a part record, the Epicor application does not prevent users from later performing transactions that could introduce other problems.
And “doable” only happens when the planets align. " discontinuing the part and setting up a new part number." is what happens more often than not.
Pretty much the rule of thumb is, “if there have been transactions referring to this part number, then UOM Conversion won’t work”
This is true, but we have had success using it. You have to make sure there is no open transactions in the system. For instance no demands, no parts on order, not on hand inventory, etc. before this will let you even think about changing the UOM. It is a built in tool. The fewer the transactions the much better this tool is.
We also added a custom field to part maintenance stating the replacement part number to use when a part goes inactive. It allows for a quicker reference for a replacement.
