Anthony D. Smith wrote:
Re: programming requirements, to my knowledge with regard to barcode specs,
etc., it is the scanner device that undertakes the decoding and the
programmer is not involved with the esoteric barcode issues other than
providing a field for at least 16 chars. Barcode input should look like
plain keyboard entry to the app, with CR at the end. I too am considering
development of a POS application but would rather buy one if I could find
one to my liking.
Because scan error can and does occur, you should still check the digits
and legitimacy of the codes. This is especially true when you allow
manual entry when the scanner does not work -- people get digits wrong
when entering data into inventory or at the POS end. Some stores enter
items into orders and receiving from paper copies of invoices, with the
actual items and barcodes not immediately on hand. We scan the input in
the inventory screen just for this reason; we found users resorted to
hand-entry from bills of lading and shipping manifests within their
comfy offices when adding items to inventory.
You need to verify the type of code, length, checksum, and sometimes you
can extract the manufacturer, model, and pricing data from the code.
There are some Web pages out there that provide "lookup" index databases
for all such codes, and some subscription services for the manufacturer
data codes.
Codes with special indicator digits require manual data entry or entry
from another device. A scanner alone, without checking the data type,
will not know you need to pause for additional data. UPC/EAN standards
call for a pause after items with a 2, 3, or 5, I think. The 2 = weight
required, 3 = drug (HIPA regulations require the pause), and 5 =
variable or manufacturer coupon. You have to reserve 4 for internal use,
and then you definitely need to know the rules for generating a code
with a checksum.
Having co-owned and manged two retail operations, I can tell you that
scanners are not 100 percent. Some are better than others, so I would
always suggest the "laser" handhelds over simple CCD style scanners. I
would also suggest one that lets you program how it reacts (tab versus
enter versus return -- which are different on the Mac, Linux, and PC).
The more programmable, the better. You don't want to assume the scanner
tabs or sends an enter because each brand differs in default settings.
(Why enter? I haven't a clue what someone thought enter was a good end
code.)
Just my two-cents from working, owning, and programming for retail and
wholesale operations. CAM Commerce (MicroBiz and Retail ICE) eventually
added UPC checks, making my life a lot easier. Then, I migrated to OS X
and had to dump my Delphi code and Retail ICE... hence, I started over
from scratch. After that hassle, I decided any system should meet every
single regulation and accounting rule I could research in the US and
California. Might as well make it as close to perfect as possible.
Some of what I've learned, I've used at the university where I work,
too. Trust me, you learn a lot dealing with high-school aged clerks in
retail and then student work-study employees. Neither group is careful
when running a register or stock room.
The scanners we had the worst luck with were Wasp's cheap units. The
best were from Metrologic and Symbol. Still, all the scanners tested did
have occasional errors.
We have found some older scanners cannot deal with the new GTIN and CSC
codes properly because they are longer than the UPC/EAN codes. Check to
make sure you can handle the new lengths and checksum-neutral codes.
If you assume the "scanner does it all" you will end up with more human
errors. Having a simple "check barcode" function that returns
"true/false" is a very good design requirement. I've had to hand-edit
inventory data when a program didn't check hand input and it was a pain.
Looking for just a few errors took a lot of time. I ended up creating a
simple QuickBasic program to verify the data back then.
- Scott
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|