NOW we're getting somewhere!
I also came across the idea that the barcode scanner may be able to
insert a "post" scan character...perhaps a null character at the end of
the string.
If they scan to Notepad, the null character does not show.
If they scan to my app, all is well.
If they type in a valid number, rejected.
That's getting really close to a solution.
Now I can hear them screaming "But the barcode is in a hard to reach
place!!!"
Well, who put the label there?
Thanks Koen!
Mike
Koen Piller wrote:
Hi
You could consider to include in the serial# a control bit that way your
people are free to scan or type the serial# if the number keyed in does not
pass the controlebit validation it will not be accepted.
An easy way would be: ( 1ste bit x 7) + ( 2nd bit x 7-1) etc till 7th bit
that Sum diveded by 8 the 8th bit would make the Sum to a mod(Sum,8) = 0
No typing errors anymore.
Koen
Send from my iPhone
Op donderdag 2 oktober 2014 heeft Mike Copeland <[email protected]> het
volgende geschreven:
Dan,
I would agree that it would be good to reevaluate the workflow. It's a
long story, but the current 'solution' is the result of several approaches
which were developed following analysis and interviews. What has helped in
the past was to work with individuals and show them the bigger picture that
they were a part of...how it causes problems for a lot of people when they
don't do their job 'right.' That usually helps, but the turnover and growth
of the company is putting a strain on the processes.
Mike
Dan Covill wrote:
I think Virgil's on to something here. If their 'macro' work flow is
better when they move the stuff around first, then do the computer work,
find a way to help with that scenario instead of forcing a different one.
Why not try automating the Notepad - let them scan (n) boxes into a list,
then in your app pick from the list. At least it won't be full of typo's.
Dan Covill
From: [email protected]
Subject: Re: square peg - square hole
Date: Wed, 1 Oct 2014 17:18:51 -0500
To: [email protected]
Juan had a case study about a similar problem in the 80's
Sounds to me like the solution is a portable scanner with a pick list
program
Sent from my iPhone
On Oct 1, 2014, at 5:11 PM, Mike Copeland <[email protected]> wrote:
Yep, tried that first thing, along with frank discussions with the
users asking "why?" This has been a problem for years now, and the issue
comes and goes as new employees cycle through. Management even installed
wireless rechargeable hand-held scanners on multiple workstations that are
located near the work/processing area...there's no reason anyone in
management can come up with. They even tried moving a VP of operations to
the warehouse processing office for a couple of months last summer to watch
(from 8 to 5 at least) and see what was "really" happening.
The only thing that makes sense, in the end-user's defense, is that
they prefer to move boxes around for all their orders that need to be
processed, then when the boxes are stacked up they go and do all their
computer work for all their orders that need to be processed (instead of
processing one order from pulling boxes to paper work to completion of
order.) But we're talking personal preference here...the distance from the
computer to the box staging area is about 12 feet.
Thanks, Virgil.
Mike
Virgil Bierschwale wrote:
Must be a process flow problem if they're going to that much trouble
Grab you a chair and watch their frustration with the process for a
week or month until you understand why they are going to that much effort
Sent from my iPhone
On Oct 1, 2014, at 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.
