I said "enter". We were discussing data entry. You are moving the
goalposts.
One possibility would be to use a date picker.
How would a date picker prevent entering a date value into a
currency field?
Now who's moving the goalposts? *chuckles* You're losing track of the
conversation, as I did.
The whole point of computerizing the collection of data is to save time
and improve accuracy. If a computerized system for collecting data
permits simple-to-prevent data entry errors, regardless of whether better
users could also prevent them, it has failed in its mission.
Oh, nonsense!
Any DE system will permit errors. If it is already known exactly
what has to be entered, there would be no need to have DE. If not, then
there are at least two alternatives. If the operator enters the wrong
alternative, how do you propose that this would be caught by the program?
Here is an example:
An accounting system allows for the entry of G/L debit and
credits. Jo(e) Bookkeeper enters:
DR Bank Account $100.00
CR Cash Sales $100.00
Should the system allow this?
I said, "If a computerized system for collecting data permits
simple-to-prevent data entry errors, regardless of whether better users
could also prevent them, it has failed in its mission."
"simple-to-prevent". That was the crux of the matter and the whole point of
my original post, despite whatever detours it has since taken.
The user entered a date value into a co-pay field. The value entered had to
consist of at least 6 digits (My error; a strict-date value requires 8, not
10, digits:
01012013 (yes, the zeros are required to avoid ambiguity in the USA because
we do MM/DD/YYYY here).
and a date value using two-digit years needs 6 digits.
There is no way that a medical-service co-payment amount in the USA in US
currency requires more than 5 digits, and that's IF two post-decimal digits
are required (not typical for co-pay values though sometimes occurs), and
IF a co-payment can be more than $99.99 (not only not typical; I haven't
encountered a single example, but I am being generous).
If the data-entry control for this co-pay amount had been
limited/masked/formatted, etc. to permit no more than three pre-decimal
digits and two post-decimal digits, the error reported could not have been
made. Alternately, if business-object logic had compared the entered value
with an acceptable range for co-pay values, or if instead of letting the
user free-enter digits, the system had instead provided a picklist of
acceptable values (not hard to do for medical co-pay amounts) the error
could not have occurred.
This was a simple-to-prevent error at the point of data-entry. Subsequent
discussion also implicates the software that received the bill submitted by
the software where the data was entered, but it doesn't invalidate my
points about proper interface design or data validation.
Again, it's about picking the low-hanging fruit. This particular issue
isn't rocket science. There is no need to invoke other examples involving
more ambiguous situations. This was a very simple situation involving very
little ambiguity. It was easy to prevent, yet it wasn't prevented.
Ken Dibble
www.stic-cil.org
_______________________________________________
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.
