A while ago, I successfully did a UOM conversion (including changing the UOM Class) on a new part that had just a handful of transactions.
Trying to do that again and running into problems.
As I recall, the new Class UOM must contain a conversion for every UOM the old Class has. What I did before was to make a conversion of ever UOM in the Old Class, in the new Class. For example
Class COUNT has UOMs: EA*, BX100, BX200
Class LENGTH has UOMs: FT*, IN, YD
the default UOM for the class
The part was incorrect set to COUNT and EA, when it should have been LENGTH and FT.
I thought i just added UOM conversions for the UOMs in class LENGTH to class COUNT
COUNT conversions:
1 FT x 1.00000 = 1 EA
1 IN x 12.00000 = 1 EA
1 YD / 3.0000 = 1 EA
But now I canât seem to add conversions to the new Class. I get
I thought maybe I had it backwards and needed to add the UOMs of the Old Class to the New Class, but that gives the same result.
Seems that some of the UOMs in other Classes can be added.
The screen shot below shows adding a new UOM Conversion to Class LENGTH.
Notice that UOM âQTâ is available, even though it is already used in class LIQUID VOLUME, while LT and OZ are not.
I think I found the problem. (It was spelled out right in the error message)
LENGTH and COUNT are âStandardâ Class types.
The time I was successful must have been to/from a class type of âOtherâ
(I made separate classes for Liquid volume and Solid Volume, and one of them must have been used)
Are you saying that the way to is UOM is not to use Standard UOM classes for parts but rather just is Others with the non-applicable UOMs set to inactive?
I have a new company that I will try this out on as this has been a very long problem for many.
If you have a document that you would be able to share, great.
UOM has been a pain in our butts. Trying to do a UOM conversion is practically impossible. Weâve almost given up on doing them, and create a new P/N instead
Users constantly forget to set the Class and UOM when making a new part. The wrong UOM isnt too bad, but a wrong class is a death sentence.
Weâve had people create p/nâs for cable (which should use class LENGTH) as class COUNT. This required us to make a UOM for COUNT of type EAFTâŚ
I think the real solution is to make a non-standard Class OTHER, that has the UOMs for both the Class youâre changing from, and the one youâre changing to.
First convert form old class to OTHER, then from OTHER to the new class.
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
etcâŚ
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?
Annoyed ainât the half of it! The Feds might also consider this a change in the valuation basis, which makes them quite testy, as well. Do this at your own perilâŚ
