CORE POS - IS4C
The CORE POS front end
Public Member Functions | Static Public Member Functions | Public Attributes | Static Public Attributes | List of all members
UPC Class Reference
Inheritance diagram for UPC:
Parser

Public Member Functions

 check ($str)
 
 parse ($str)
 
 upcscanned ($entered)
 
 fixGS1 ($str)
 
 doc ()
 
- Public Member Functions inherited from Parser
 check ($str)
 
 parse ($str)
 
 default_json ()
 
 isLast ()
 
 isFirst ()
 
 doc ()
 

Static Public Member Functions

static requestInfoCallback ($info)
 
static requestTareCallback ($tare, $in_item)
 
- Static Public Member Functions inherited from Parser
static get_parse_chain ()
 

Public Attributes

const GENERIC_STATUS = 'NA'
 
const SCANNED_PREFIX = '0XA'
 
const SCANNED_STATUS = 'SS'
 
const MACRO_PREFIX = '0XB'
 
const MACRO_STATUS = 'KB'
 
const HID_PREFIX = '0XC'
 
const HID_STATUS = 'HI'
 

Static Public Attributes

static $requestInfoHeader = 'customer age'
 
static $requestInfoMsg = 'Type customer birthdate YYYYMMDD'
 
static $requestTareHeader = 'Enter Tare'
 
static $requestTareMsg = 'Type tare weight or eneter for default'
 

Member Function Documentation

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.

UPC::parse (   $str)

Do not apply scanned items if tare has been entered

UPC::upcscanned (   $entered)

11Sep14 Andy Disabled until keypress double form submission is fixed on paycard confirmation screen. Depending on sequence can case flag to be raised, cleared, and re-raised leading to spurrious error notifications

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.

If formatted_name is present, copy it directly over products.description. This way nothing further down the process has to worry about the distinction between two potential naming fields.

Apply special department handlers based on item's department

Detect if a by-weight item has the same weight as the last by-weight item. This can indicate a stuck scale. The giant if determines whether the item is scalable, that we know the weight, and that we know the previous weight (lastWeight)

Pre-weighed items (upc starts with 002) are ignored because they're not weighed here. Scalable items that cost one cent are ignored as a special case; they're normally entered by keying a quantity multiplier

Apply automatic tare weight

Enforce per-transaction sale limits


The documentation for this class was generated from the following file: