One approach I have seen for UOM Classes that works well:
create a new “Other” class for each type of part number (sort of like PartClass)… Example: Cable Class, Hardware Class, Epoxy Class, Wire Class, etc.
Apply all the UOMs that are used in that class (Epoxy stored by Gallon, but purchased by Pound… Cable stocked by Spool, purchased by Pound, used by the inch… and so on).
NOW, when your engineer creates a new part, they simply choose the correct UOM class by the type of product.
This is easier to figure out based on the type of product rather than the type of UOM… people just don’t seem to think that Wire, Cables, and sticks of wood need three different types of UOMs, but if you call the class by that name, it is easier.
But we run into problems where some times pipe is used by the foot, and and other times it’s used a a single 10 FT piece.
So we’d make a UOM class named ‘Pipe Class’, with the following UOM’s…
FT (the base unit)
IN (inch, where: 12 IN = 1 FT)
[ all the other std lengths like YD, M, CM, etc… ]
EA10 (a 10 foot length, 1 EA10 = 10 FT)
EA20 (a 20 foot length, 1 EA20 = 20 FT)
What are your thoughts on having UOM Symbols differing from the UOM Code?
Like setting the Symbol for EA10 to be 10' PC
UOMs with values in them is done quite often for specialty industries, especially when lengths or sheets are involved. But application of a “Pipe” class is exactly what I am suggesting… that way, you already have all the special conversions.
Another example is “Extrusions” where the extrusion length is variable. you can specify “Stick5”, “Stick10” and “Stick15” as the 5, 10 and 15 foot versions, but also have a “Stick” that is part specific, and also “FT” and “IN” as well as “LB” for pounds so that you can have the pounds per foot calculations.
Watch out for feet and inch conversions though. It’s all set up to work right except If you inventory in ft and try to issue by the inch, rounding goes through a loophole when you divide by 12 and you end up with problems with too many decimals in your transactions.
We have an issue with a UOM that has a VERY large conversion factor.
We use polyester thread to wrap some of our cable assemblies. We stock and issue the thread by the foot. Problem arises due to the fact that the supplier sells it by the pound. The conversion is something like 1800 yds/pound, which is 5400 FT/LB. Since it’s only around $2.00 pound, that makes the unit cost (in IUM) to be $0.00037/FT
years ago I worked with a customer who had ultra small UOMs for the plastic insulation for Wire… they had all their engineering by the inch, which made costs so small, they either rounded down to zero, or rounded up to a number larger than desired… the result was that their standard costing was a mess.
My suggested solution was to revise their engineering. I asked one simple question. “What is the smallest jobsize for manufacturing wire?”… their answer: "OH… we never make less than 1000 feet.
SO… we did a quick test, revising the BOM to be for 1000 feet instead of one inch… costing was perfect “to the penny”. This solution actually turned into a big win because everything was easier for them in the long run with using whole numbers instead of lots of decimal values.
So, yes… sometimes rounding and small uoms can get you in trouble. but sometimes it might take some rethinking.
When should one go all the way to a part specific UOM?
We use several epoxies, which we purchase by the LB, and issue by the OZ (measured into marked mixing cup). Using a part class “EPOXY PART” wouldn’t work because the different epoxy components have different densities.
Resin X is 100 OZ / LB, Hardener for X is 90 OZ / LB
Resin Y is 80 OZ / LB, Hardener for Y is 77 OZ / LB
I was burned by poor UOM choices when I setup E10, so I think long and hard before jumping into something new when it comes to them.
Most of us here are Operations or Technical types, but it pays to keep in mind that any ERP system is, at the end of the day (or more appropriately the end of the Fiscal Period), a hi-falutin’ accounting program.
And changing a UOM Conversion after transactions have taken place is an Inventory Valuation problem. In extreme cases, it can require restatement of prior periods, which makes the finance folks, well, annoyed.
@thager, remember the fun we had with this back in the day?