Fill basket/trolley, then go to check-out (POS) to pay
POS = keyboard, display, till, scales, bar-code scanner, credit-/debit-/cheque-card scanner, printers for cheque/credit/debit & receipt.
Per item in shopping basket:
pre-packaged item: bar-code scanner reads item code
loose item(s): scales weigh item(s), enter item code by hand
-> cost -> bill
operator exceptions:
scanner can't scan: enter item code
item code not known: find & enter cost
reduced cost tag over item code:
scan cost, remove tag, scan item code
or: scan item code, enter new cost by hand
Payment etc.:
cash & coupons: change
blank cheque + cheque card: card scanned, information printed
on cheque, sign
credit/debit card: card scanned, information printed on credit
slip, sign, request electronic authorisation
print receipt
Other customer interactions:
multisave, linksave etc.
cashback
returns
price & availability queries
VAT etc.
gift certificates
foreign currency
at POS:
audit, operator log on/off, training, secure
for shop: (per department)
allocate sales commission, stock control, sales info etc.
deciding placement, promotions, advertising etc.
The 13 digits are printed as numbers: a || bcdefg || hijklm ||
and as alternating spaces (S) and bars (B) of varying widths:
sync(101) 6*(SBSB) sync(01010) 6*(BSBS) sync(101)
The synchronisation blocks are alternate bars and spaces, each of width 1. They allow the bar-code scanner to adjust for e.g. start, midpoint & end, contrast, speed, angle, etc.
a-l = region/kind+company+product
978... = ISBN 977... = ISSN (Bookland),
49... = Japan (JAN), 0... = USA (UPC)
m = check digit = (- (b+d+f+h+j+l)*3 - (a+c+e+g+i+k)) mod 10
Digits b-m are each encoded by 2 spaces and 2 bars of different widths (1, 2, 3 or 4), but the same total width (7). This gives 20 possible combinations. Left-hand digits (b-g) start with a space, right-hand digits (h-m) start with a bar. The Left-A and Right encodings have been chosen so that they cannot be confused if the barcode is scanned upside down.
Unfortunately, an extra digit (a) has had to be included since the barcode was first designed, so the Left-B encodings have been added, which can be confused with the Right encodings (they are just mirror images). The extra digit is encoded in the patterns of usage of Left-A or Left-B for the barcoded left digits (b-g). All Left-A means 0 for backward compatibility. The leftmost barcoded digit (b) and at least two other left digits use the Left-A encodings, so there is still enough information to resolve the ambiguity.
Digits b cdefg hijklm a Encoding Left-A Left-B Right First Parity Odd Even Even Space/Bar Widths S B S B S B S B B S B S c d e f g 0 3 2 1 1 0001101 0100111 1110010 AAAAA 1 2 2 2 1 0011001 0110011 1100110 ABABB 2 2 1 2 2 0010011 0011011 1101100 ABBAB 3 1 4 1 1 0111101 0100001 1000010 ABBBA 4 1 1 3 2 0100011 0011101 1011100 BAABB 5 1 2 3 1 0110001 0111001 1001110 BBAAB 6 1 1 1 4 0101111 0000101 1010000 BBBAA 7 1 3 1 2 0111011 0010001 1000100 BABAB 8 1 2 1 3 0110111 0001001 1001000 BABBA 9 3 1 1 2 0001011 0010111 1110100 BBABA
(example bar-code here)
\fBPOS\fP: a PC without a VDU - it has an O/S handling local peripherals (till, scales, scanners, printers etc.) and external communications, scheduling application programs, managing the databases etc.
\fBDB\fP: holds prices, stock levels, sales, etc.
\fBLAN\fP: connects everything within the store
\fBWAN\fP: connects store to head office, warehouses, suppliers, credit agencies, etc.
[ *-?-> = request, -> = data ]
* per item sold:
item number: scanner or keyboard -> POS
weight: scales -> POS
cost of item: POS *-?-> DB -> POS -> printer & display
sale: POS -> DB
* payment by credit card:
credit card number: scanner -> POS
check: POS *-?-> DB -> POS
authorisation: POS *-?-> credit authorisation service -> POS
number, cost, etc.: POS -> printer
*
sales info: DB -> management ->
{stock resupply: warehouse/suppliers
{how well is line doing?
The main consideration is serving customers properly
-> accuracy, reliability, speed etc
BUT cost also matters
Accuracy:
must be more accurate than humans at POS
must be 100% accurate once the transaction is in the system
OR:
must be easy, fast, (rare) for the operator to recover from errors
DB: transaction locking & commit/rollback, security, audit trail, etc. - see CS1311
Speed:
DB
& LAN: sufficient bandwidth
WAN: sufficient bandwidth
Reliability:
Graceful Degradation: as things go wrong, lose proportionate amount of
throughput etc. - don't suddenly lose whole system.
LAN: replicate as many components as possible & no one controller. POS's communications processor physically separate from POS.
POS: a serious LAN fault must not disable more than a few POS, so they must be capable of operating stand-alone (for how long?) Printout of all sales?
WAN: can we get by with replicated modems (or whatever) on the LAN, and use humans on a phone if the LAN breaks?
DB: replicate on the LAN, but how can we maintain correctness?
system resilience -> many copies of DB
speed -> local copies of most-used parts of DB (caches)
data integrity -> one copy of (writable) DB
If everything worked fast enough, most of our problems would be solved,
except:
a) system resilience
b) cost
a) To achieve system resilience, we have to have many copies of DB,
but for data integrity we must have (logically) only one DB controller.
We can get this effect by having a Master DB controller, which does any
updates, and passes the updates on to the other Slave DB controllers.
If the Master controller is lost, then one of the Slaves controllers can
take over, and (we can arrange it so that) no data will have been lost.
clients reading data: request sent to nearest copy of data
clients writing data: request sent to Master server, which distributes it to
all copies of the data (but see static & dynamic below)
Master server: e.g. ensures sequence preserved for DB update (when multiple
copies of DB) in case of system failure & subsequent roll-forward to
recover. Can be duplicated, but only one is the master at any one time.
However, this is slower than a normal DB access - each atomic action needs to include the communications with the slaves, and anyway b) we need to worry about costs, so we need another mechanism to deal with rapid changes (sales)
Need to track sales to monitor stock levels
DBs classified as static
& dynamic
static: run by Master to ensure consistent
dynamic: no Master - log information sent to several dynamic DBs. One of
these is then consolidated & used to maintain a master static DB.
Consolidation: Log split into history periods
when period closed, consolidated
normal PCs/workstations also attached to LAN as servers, for managers, stock control, etc.
levels of software:
applications (running on a POS or PC)
platform (network support)
O/S (device drivers etc. for LAN & other peripherals)
client <-RPC-> agent <--> message handler
<-LAN-> message handler <--> server
intermediate servers
message handlers have name tables linking (external) service names to LAN
addresses (& local services to e.g. local procedure calls)
add addresses when devices (& their services) log on to LAN
remove addresses if requests time out, & find alternative server
watchdogs (daemons):
power, LAN error, HD error
split network: avoid multiple servers becoming uncoupled
* Summaries of past sales
-> Predict future sales
= average + expected perturbations
Day of week
Date
Weather
Promotions
Competition
+ current stock-levels -> orders
* Individual sales
-> Target individuals
Inside shop
Outside shop
* EFTPOS: Electronic Fund Transfer at POS
* Smart trolleys
* Home shopping
* Expert systems