CORE POS - IS4C
The CORE POS front end
|
Public Member Functions | |
check ($str) | |
parse ($str) | |
fixGS1 ($str) | |
expandUPCE ($entered) | |
sanitizeUPC ($entered) | |
doc () | |
Public Member Functions inherited from COREPOS\pos\parser\Parser | |
check ($str) | |
parse ($str) | |
default_json () | |
isLast () | |
isFirst () | |
doc () | |
Static Public Member Functions | |
static | requestInfoCallback ($info) |
Static Public Member Functions inherited from COREPOS\pos\parser\Parser | |
static | get_parse_chain ($type='COREPOS\\pos\\parser\\Parser') |
Static Public Attributes | |
static | $requestInfoHeader = 'customer age' |
static | $requestInfoMsg = 'Type customer birthdate YYYYMMDD' |
COREPOS\pos\parser\parse\UPC::check | ( | $str | ) |
The default case is pretty simple. A numeric string is checked as a UPC.
The 0XA prefix indicates a scanned value from the scale. This prefix was selected because PHP's validation still considers the whole string a [hex] number. That helps with overall input validation. A complex entry like: 5*0XA001234567890 Is handled correctly because there's a "number" on both sides of asterisk. The prefix is then stripped off by this parser to get the actual UPC value.
The GS1~ prefix is an old artificat of wedge compatibility. Using something like 0XB instead would probably be an improvement.
COREPOS\pos\parser\parse\UPC::parse | ( | $str | ) |
Do not apply scanned items if tare has been entered
COREPOS\pos\parser\parse\UPC::sanitizeUPC | ( | $entered | ) |
If EANs do not include check digits, the value is 13 digits long, and the value does not begin with a zero, it most likely represented a hand-keyed EAN13 value w/ check digit. In this configuration it's probably a miskey so trim the last digit.