CORE-POS/IS4C

View on GitHub
documentation/IS4C/developer/howto-gs1.html

Summary

Maintainability
Test Coverage
<html>
<head>
    <title>GS1 Databar</title>
</head>
<body>
    <div style="text-align:center;margin-bottom:10px;font-size:80%;">
    updated as of: April 1, 2015<br />
    last author: Andy Theuninck
    </div>
    <div style="border: solid 1px black; font-size: 115%; padding: 1em;">
    The latest documentation can be found on the <a href="https://github.com/CORE-POS/IS4C/wiki/POS-Pages">Project Wiki</a>.
    The information below may be out of date. 
    </div>
<i>This document is a work in progress; suggested practices more likely to
change than in other documentation</i>
<p />
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.
<h3>Scale Drivers</h3>
When scale drivers read a GS1 barcode, they should affix a prefix to
the barcode digits consisting of: <b>GS1~</b> plus a two character code
denoting the databar's type. Current codes are <b>R4</b> for regular
databars and <b>RX</b> for extended databars.
<p />
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.
<p />
<i>This idea is based on the Wedge's suggestion and may be revised
if I misunderstood their prefixing</i>
<h3>Data Storage</h3>
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 <i>Application Identifiers</i> is likely
the best solution.
<p />
The application identifier <b>01</b> denotes a GTIN-14 product identifier.
GTIN-14 is analogous to UPC or EAN but 14 digits. In this case, discard the
prefix <b>01</b> 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.
<p />
The application identifier <b>8110</b> 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.
</body>
</html>