A vendor of ours is thinking of going to Epicor. One of the employees asks me about warnings or pitfalls. Immediately I think of UOMs and start twitching.
Having said that, is it really worth having separate UOM classes? I.e.
Or would you say don’t bother, and populate only one class?
The only strange one was the ounce.
One US Gallon = 128 fluid ounces.
One US Pound = 16 dry ounces.
And we have at least one dairy user (@markdamen) where raw milk is delivered in pounds (at least it was in Wisconsin when I worked on a dairy farm) and that converts to volume.
So I’d keep them separate…
Abso-friggin-lutely
@Mark_Wonsil Humor me - how do classes help that situation? How do you convert across classes? Or does the part number change in the conversion also?
@ckrusen When I searched UOM on this site, your name came up a LOT. I knew you would be a yea vote.
I will say, though, once we knew what we were doing, we have never made a UOM mistake in the last two years.
Any high school science student has learned that mass is totally independent of any other parameter, and is a direct measure of “amount of stuff”. Mass should be our base unit of measure for most things.
And that would save us from hearing the the conspiracy nuts go on about how you’re getting ripped of in the summer because gasoline expands as it gets warmer, thus giving you less gas in a volume.
Unfortunately, when it comes to UOM’s in my company, I’m the only one that knows what they’re doing.
At least once a month (often more), someone makes a new part with the wrong UOM Class. 
And the issue doesn’t show until after they’ve applied transactions to it
So in the UK we’re obviously metric. We have some weird customs and practise:
Cream traded in kilograms (kg)
Milk traded in litres (l)
Skim traded in litres (l)
Skim Conc traded in kilograms (kg)
For milk and skim, we have to convert to/from kg (weighbridge) to litres using a standard density.
Within a class, you have to enter a conversion factor for every UOM within the UOM Class to the base UOM. If you don’t mind coming up with some strange conversions (meters to liters, etc.) then you could conceivably do it all in one Class. I don’t think it buys much improvement though…
What WOULD be nice is a utility to help fix mistakes when the wrong UOM or Class is chosen…
And I know there is a utility but I’m aiming higher! 
Only utility for that is SSMS… 
FTR - I’d be less irritated by UOM’s if the ability to change them wasn’t so constrained.
Our biggest issue is people using the default Class and UOM (COUNT.EA), for things that should be LENGTH and FT. So much so, that I had to make a UM called EAFT (with symbol FT) so these parts can continue to be used.
@Mark_Wonsil - besides common UOM names (like the liq OZ and wt OZ), we have some items that cross Classes too. Like lengths of pipe specified by their whole length.
For a certain partnum that specifies a 10 FT length, and you need 5 of them, you can either:
A. sell 5 EA (count class) of 10 foot lengths
or
B. sell 50 FT (length class)So how do you convert–how is that set up? One class or different part numbers or something else?
Well for the milk example - PO will be in LITRES, when the tanker arrives onsite it goes over the weighbridge and weight is stored in KG. After unloading, the tanker goes back on the weighbridge and gets a 2nd weight stored in KG. The weighbridge software calcs the NET WEIGHT in KG and stores it in its SQL DB, which has lots of hashing and CRC type checks to ensure that you can’t just update the values in the DB - if you do, when loading a record to the screen or printing a ticket it shows up as invalid.
When the operator then does the PO receipt in E10, I’ve added a button to the Receipt Entry screen. They key the correct PO/Line/Rel then press the “Get Weight from Weighbridge” button. It pulls the net weight value, and then multiples or divides by the configured density (which is 1.031 or something from memory) - it plonks the figure into the Received Qty field.
When I was just a wee lad in elementary school, we had composition books that had a “Useful Information” on the back. Anyone else have these in school?
That’s not the exact one, as I clearly remember ours having the conversions from Bushels to Pecks (I think it was 4 to 1, not sure the direction)
I think that weighbridge would make a nice IoT project…
So you purchase in LITERS (or LITRES as you say), “count” the received qty in KG, and then receive it in LITERS.
Does the the supplier invoice in LITERS?
We use a yarn for wrapping cable harnesses, and use it by the FOOT. The supplier sells it by the pound. So we have a UOM (of class LENGTH) named LBFT1, Desc: LB (8250FT), Symbol 'LB`
With a conversion of 1 LBFT1 = 8250 FT.
Yes LITRES (correct spelling )
Yes it’s traded in litres, but the accurate method of checking the quantity is weight on the weighbridge. Our supplier will be putting in over their weighbridge, we do the same. If the 2 figures don’t match exactly, then what we do is split the difference between the 2 figures. It’s normally within 20kgs on 25,000kgs, which is the accuracy of the weighbridge itself.
