GS1 Databar Support

Current Status

As far as I know, no one is actively using GS1 databar scanning.

Plan

CORE eventually needs to handle GS1 Databar barcodes. This affects a couple parts of the POS: scale drivers and data storage. I'm suggesting some best practices to avoid unnecessary incompatibilities in implementation.

• Scale Drivers
  • When scale drivers read a GS1 barcode, they should affix a prefix to the barcode digits consisting of: GS1~ plus a two character code denoting the databar's type. Current codes are R4 for regular databars and RX for extended databars.
  • These code values are derived from the Magellan scale's default behavior. This implementation does not actually use the two character codes for anything, but drivers should still provide them in case other co-ops' parsing relies on them.
  • This idea is based on the Wedge's suggestion and may be revised if I misunderstood their prefixing
• Data Storage
  • When parsing input on the PHP side, GS1 databars can be identified by the prefix assigned above above. Some databars may contain more than 13 digits - in fact, many more than 13 digits - which makes storing them in existing UPC fields problematic. Different handling for different databar Application Identifiers is likely the best solution.
  • The application identifier 01 denotes a GTIN-14 product identifier. GTIN-14 is analogous to UPC or EAN but 14 digits. In this case, discard the prefix 01 and the 14th digit of the GTIN-14 (a check digit) to get a 13 digit product identifier. This value will map cleanly into the UPC fields and no real information has been lost.
  • The application identifier 8110 denotes a coupon. Coupon barcodes are always much more than 13 digits. Each coupon does contain a 6 to 12 digit manufacturer prefix just like traditional UPC and EAN coupons. To simplify scanning, this prefix should be stored in the transaction table's UPC column such that the prefix "lines up" with the UPCs for matching products. Storing all coupon information will require additional table(s) and/or field(s). Those have not yet been decided on.

Implementation

The NewMagellan driver will prefix GS1~ to databar scans as described. GS1 scanning has to be specifically enabled on the scanner-scale; it's turned off by default.

The UPC parser does handle the GS1~ prefix. The DatabarCoupon SpecialUPC handler included in version 2.6 or higher has been used in production and works for at least the commonly encountered coupons. I think there's at least sixteen thousand permutations that these style coupons can use so it's possible there are some configurations that aren't handled correctly. At this point bug reports would be helpful. The number of variants actually used in practice is probably significantly smaller than the theoretical number of variants and focusing attention on the practical use cases seems most efficient.