The cXML specification requires that the UnitOfMeasure element contain a code from ISO Recommendation 20. When this is mapped into ANSI X12, it must therefore be translated to ANSI's code list for DE0355.
As long as a proper ISO code is used in the UnitOfMeasure element, the translation works quite well.
The most common problem I found there was that a customer's back-end system might have used ANSI Units of Measure, and when Ariba Buyer was installed, they did not translate their code to the ISO code required by cXML. In these cases, the cXML data contained an ANSI code that would be interpreted as ISO and then mistranslated.
But the most laughable case I ever saw, which was escalated from the support team, had the customer sending Unit of Measure code DOL. The code DOL does not exist in the ISO R20 table.
Due to a defect in the translation code at the time, if the ISO table lookup failed, the cXML UofM was simply written to the DE0355 element "as is", and truncated if necessary, to which it became code DO.
Now it just happens that code DO in ANSI represents "Dollars (US)".
I was mystified as to where this code DOL came from and what it was meant to represent.
The customer was using this code DOL to mean Dollars, hence they were happy that it came over as code DO in ANSI. One had to wonder how they were buying Dollars? Who was the supplier, I thought, the treasury? The mint?
No. The customer was actually buying "consulting services". So I said to them, Why don't you buy in units of time, like Man Hours? They wanted to buy in units of budget. And after pressing the customer with the what and why questions that we Systems Analysts always ask, I managed to get them to admit that they had created this non-standard Unit of Measure Code DOL to mean Dollars.
The problem was that while the process just happened to truncate the L, and render code DO to the 850, the supplier's invoice could not translate code DO back to DOL.
There is no code in ISO R20 that corresponds to "Dollars (US)", and so DO is one of a handful of unsupported codes. And DOL, being homegrown, does not exist in the ISO R20 code list.
Tsk tsk; have you ever had to tell folks to not use their homegrown codes in this industry?
The solution I recommended to the customer was to use code M4 for Monetary Units. This code happens to be the same in both ISO and ANSI which worked both ways and was perfectly acceptable by the supplier.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment