updated as of: April 1, 2015
last author: Andy Theuninck
The latest documentation can be found on the Project Wiki. The information below may be out of date.
This document is a work in progress; suggested practices more likely to change than in other documentation

IS4C 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 incompatibilites 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.