Following the UOM ANSI Standard

There is a ANSI UOM Standard and there is also EDI Standards that usually have specific UOMs they consider valid.

Has anyone ever been bitten in the cheek for using let’s say “SQFT” instead of “SF” (which is from ANSI Std) - or - “M” for meter instead of “MR”?

Epicor does list the ANSI UOM Standards in their UOM TechRef Guide, I assume for a reason.

1 Like

Im working through a similar issue. Im recommending we use ANSI here (I have been using that same document that you attached).
We plan to use EDI and i want to make sure that we dont have any trouble in the future. Epicor UOMs are too difficult to change once you have a part tran record.

2 Likes

We haven’t been bitten by it (yet), but ‘M’ is common in the UK to mean 1000 counted items.

1 Like

So far I only have seen that EDI may be affected. I am curious if other things like Configurator or other Modules could be affected.

Even Labels in the AIAG Standard recommend ANSI, because General Motors, FORD etc… Scan them. Sometimes they have a PDF Barcode (QR type) which embeds the UOM with the Qty.

I dont think Epicor modules would be effected. When we built a configuration in the past, parts were using IUMs associated with that part and that are in the UOM tables.

Definitely could impact some things that commerce connect uses though.

Another one I can probably think of is Insite Manifest… After all it communicates with Shipping API’s. Fedex, UPS, USPS… I assume they have some requirements for UOMs, especially if one ever ships Hazmat then UOM is Required (per ANSI Std)

Yes ECC as well.

I would push for ANSI just to be safe.

1 Like

We are working on implementing ANSI. Better now than Later. Its definitely a tricky decision with ISO Standards etc…

The best option is to follow ANSI and I am sure for anyone who has plans to do EDI, Epicor has ANSI to Non-ANSI (ISO…) Converters easily available.

Funny how Epicor suggest ANSI, yet in many examples they don’t follow their advice.
2019-04-01_0014