updated as of: April 1, 2015
last author: Andy Theuninck
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.
The latest documentation can be found on the Project Wiki
The information below may be out of date.
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
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.