At least, not in the way the writer of a much-publicized article in the August 13, 2002, edition of the New York Times would have people believe.
The writer, Kate Murphy, likened the expansion of the standard 12-digit UPC code to 13 digits on January 1, 2005, to the Y2K issue, and seemed to promise near chaos with the potential of supermarket scanners “seizing” and computer systems “crashing.”
She also states that “scanners and other hardware bought more than three years ago will not read longer codes and will have to be replaced. Software more than five years old will have to be scrapped.”
Guess she hasn’t been to a supermarket lately and noticed all the scanners reading the coupon code (which is a UCC/EAN-128 symbol). Any system capable of reading coupon codes will likely have been prepared for the 13-digit EAN number and possibly even the 14-digit “Global Trade Identification Number” (GTIN).
And perhaps she was not aware of the fact that the symbology used to represent both the 12- and 13-digit versions is the same. I can’t think of any scanner made in the past 10 years (or more) that couldn’t recognize both UPC and EAN symbols — even EAN-8, which is a special case. One has to wonder whether she got her scanning knowledge from a former president.
EAN’s leading (13th) digit is not encoded directly but is generated from the parity patterns in the first (left) half of the symbol. There are two valid ways to encode each digit in the left half of the symbol: one with odd parity and the other with even parity. Following the proper encoding algorithm, the 13th digit is generated as the result of these parity patterns. UPC symbols, by default, have a leading zero for the “13th” digit.
It is true that many companies that implemented scanning in the 1980s often set aside only a 10-digit field for the product code (stripping off the initial zero and the check digit); these systems will have to be updated. And companies have instituted 12-digit product ID fields (even though the Uniform Code Council has been advocating larger ones for years). So, yes, there are some database issues with some companies — particularly point-of-sale databases. But scanner issues? I don’t think so.
True, there are a limited number of available UPC numbers and the Uniform Code Council will run out if they’re forced to continue assigning numbers to non-U.S. companies. But then, that’s why EAN was created. EAN was originally designed with an extra digit in the company identifier to allow for a “country code” that greatly expanded the systems’ capacity and that allowed for national assignment of company codes.
One note of caution, however. Today, EAN company codes are not always seven digits long (some are longer), so both EAN and UCC recommend using the entire 13-digit code for product identification.
Of course, all of this will be a moot issue to anyone on the material handling side who’s currently scanning shipping containers since they’re already using the full GTIN: the 13-digit code plus the Packaging Indicator (PI). The PI is an arbitrary number assigned by the manufacturer or packager that indicates the level of packaging — that is, whether it’s the unit of use/sale, an inner pack, an outer pack, etc. The PI equates directly to a specific quantity recorded in the database (except for variable content packs). The PI greatly improves product visibility at the receiving dock and in inventory.
Okay, if you’re not prepared to accept a 13-digit product code, you are going to be in trouble unless your suppliers are exclusively U.S. or Canadian manufacturers. But, just as many IT departments leveraged Y2K issues to finally dump their legacy systems, the sunrise date for “13-digit UPC” is the perfect reason to update your systems to the full 14-digit GTIN.
Using the GTIN will not only give you the ability to recognize any product code from any manufacturer, anywhere in the world, you’ll have the PI that can tell you quantity as well.
After all, what good is knowing what you have if you don’t know how much of it there is?
Bert Moore, contributing editor, [email protected]
