There are, potentially, hundreds of any one individual SKU in stock, and
since they want to be able to scan ANY SKU that would raise the total
number of possible #s presented in the drop down to above 30,000.
Doable, but the problem is that they are scanning valid #s, just not the
number on the unit that goes to the person on the order. When they
hand-key the number, the program does check the number to ensure it is a
valid, in-stock item.
Another way to describe it is that they are scanning the right number
(in a way) but then physically picking up the wrong unit. I mean, that's
not really what is happening but there's really no difference in the
outcome.
One suggestion I had, which was considered implausible, was to have a
person stationed at the "docks" who would float amongst all 7 docks,
final-checking and matching all the paperwork to the actual items on the
truck before it is allowed to drive away. Kind of a "dock master" who
would have to sign off on all the delivery crews leaving the building in
a vehicle with merchandise. I never got a clear answer as to why that
wouldn't work...
Thanks Stephen!
Mike
Stephen Russell wrote:
Why not make the control a dropdown instead? Type to jump but scan to hit
it.
On Oct 1, 2014 4:52 PM, "Mike Copeland" <[email protected]> wrote:
All,
I have a problem with end users hand-keying information that should be
scanned with a barcode scanner to improve accuracy.
Here's the gist of the issue...
Every piece of inventory has a barcode sticker on it representing a unique
serial #, always 8 characters long.
(My application offers a way to reprint the barcode label in case this
label gets torn, damaged.)
What I need to force, somehow, is that the # represented on the barcode
label MUST be scanned by a simple barcode scan gun connected to the
computer.
As ya'll know, all the scanner does is convert the barcode data into
standard keyboard keystrokes and stuff the data into the keyboard
buffer...really fast. In other words, a very fast, very accurate typist.
But most importantly, the CORRECT # is input (so that the correct inventory
item is recorded as 'processed.')
The problem is that the users hand-key the number at the prompt...and
frequently hand-key it wrong.
So, to try to stop the hand-keying I removed the human-readable text under
the barcode on the label. So now, you either scan it or you learn to read
barcode by eye. One would hope/think that this would have solved the
problem...but no.
Now (by watching security video footage) we find that they are
1. opening Notepad
2. scanning the barcodes, which enters the barcode data in human readable
form, obviously
3. then hand keying the data into my application when they should use the
scanner.
And...errors are being made regularly. And, yes, training, threats, etc.
have been tried.
From the application's viewpoint, the only difference between a barcode
scanner providing input and a human typing on a keyboard is the speed with
which the data is input.
So, my last-ditch idea to force scanning and negate hand-keying is to,
somehow, use a timer on the input. Set the timer to a short time, like 1
second, which is faster than 99% of humankind can type 8 characters. Start
the timer on the first keystroke and when the timer fires again if the
length of the input is less than 8, clear the input...because they're not
scanning.
My question, is this nuts? Is there a better way? Am I barking at the
moon? Begging for problems? Any other Ideas?
Thanks for feedback.
Mike Copeland
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
