🚀 go-pugleaf

First Star wrote in message <67bn4b$ch02@forums.borland.com>...
>My boss has asked me to convert a formula contained within an old .prg file
>into a mathematical formula.  This dBase program was written back in 1990
by
>an ex-employee who we cannot get in touch with, and no one in our office
>knows anything about dBase.  I've read a little about dBase IV, but I still
>have some questions.
>
>This program is supposed to check the "check digit" for our keypunch
>department.  It uses the order number (morder)  to determine the proper
>value for this digit.  "morder" is a six digit number, the first digit from
>the left being the check digit, the next five being the actual order
number.
>Here is the program:
>-------------------------------------------
>PUBLIC wrong, mcalc
>wrong=0
>@ 23, 0
>mcheck = VAL (SUBS(morder,1,1))
>ma=3 * VAL(SUBS(morder,2,1) + SUBS (morder,4,1) + SUBS (morder,6,1))
>ma = VAL(SUBS(STR(ma,3),1,1) + VAL(SUBS(STR(ma,3),2,1)) +
>VAL(SUBS(STR(ma,3),3,1))
>mb=VAL(SUBS(morder,3,1) + VAL(SUBS(morder,5,1))
>mb=VAL(SUBS(STR(mb,2),2,1))
>mcalc = 10 - VAL(SUBS(STR(ma+mb,2),2,1))
>mcalc = IIF(mcalc = 10,0,mcalc)
>IF mcheck <> mcalc
>     wrong = 1
>     ? CHR(7)
>     SET COLOR TO GR+
>     @ 23, 18 SAY "Order Number is Incorrect. Please re-enter."
>ENDIF
>
>RETURN
>----------------------------
>From what I can tell, the program takes the 2nd digit, multiplies it by 3,
>then adds the value of the 4th and 6th digit to the result.  It then
appears
>that the total of this function (ma) should be a 3 digit number, but what
if
>it's not?  I'm having the same problem understanding the computation of the
>"mb" variable.


STR(ma, 3) converts ma to a length three character string, so there's no
problem in then extracting each of the digits of ma with the substring
function. If ma is just  '  9' or ' 33', substr(ma, 1, 1) will return a
blank space, and val(ma) = 0.

Hope this helps, if you need more help just ask!

Don

Kevin,
> From what I can tell, the program takes the 2nd digit, multiplies it by 3,
> then adds the value of the 4th and 6th digit to the result.

Not quite.<g> Let's assume the invoice number is x30303. The first ma
computation line extracts the 2nd, 4th, and 6th digits and concatanates
them as the character value "333", converts it to the numeric value 333,
and then multiplies that by 3, resulting in 999. Mathematically, it
would look like:

3 * 333 = 999

The second ma computation line then simply takes the 3 digits and adds
them together. Using the same invoice number of x30303, this results in:

9 + 9 + 9 = 27

> It then appears that the total of this function (ma) should be a 3 digit
> number, but what if it's not?

No, the result of the first ma computation line can be a 4-digit number,
and therein lies the problem that I suspect that you and your boss are
trying to understand. The second ma computation line assumes that the
result of the first line will be a maximum of 3 digits.

Let's assume an invoice number of x30304 (the lowest number which will
result in a problem with generating a correct check digit).

The first ma computation line results in:

3 * 334 = 1002

This is where the problem comes in. The STR() function expressions in
the second ma computation line will return three asterisks (***) because
an overflow condition has been passed to the function by passing a
4-digit number as the first parameter and being told to return 3 digits
as the second parameter. Because an asterisk has no value, zero will be
returned for all 3 digits from the Val() test, so the result of the
second ma computation line is in effect:

0 + 0 + 0 = 0

which would be an invalid computation.

The result of this will be for invoice numbers above x30303, you will
have groups of contiguous invoice numbers with the same invalid check
digit, followed by a group with valid check digits, and this will
deteriorate as the invoice number gets larger such that a larger
percentage will have invalid check digits.

How you would correct this depends on a number of factors such as
whether the original invoice number is generated using the same dBASE
code, how many invoices have been cut with invalid invoice check digits,
whether the invalid invoices can be recut, etc.

> I'm having the same problem understanding the computation of the
> "mb" variable.

The mb computation works a little differently. The first mb computation
line adds the numeric values of the 3rd and 5th digits. Assuming x30303:

0 + 0 = 0

The second mb computation line then extracts the numeric value of the
last digit only, which in our sample case is 0.

The 2 mcalc computation lines simply add ma and mb, and subtracts the
last digit of the result from 10. If the result is 10 (10 - 0), then a
value of 0 is assumed. This ensures that the resultant check digit is
always a single digit. So, using our example of x30303, the computation
of mcalc would be represented as:

27 + 0 = 27
10 - 7 = 3

or:

10 - Mod(27 + 0, 10) = 3

> Thank you in advance for your help,

My pleasure. Shout back if you need additional assistance.

> Kevin Facko
> First Star
> 248-475-4388

I see you are in the Pontiac area (or close)? I'm in Milford. Just
curious, what is First Star?
-
Jim Sare - TeamB

"First Star" <firstar@tir.com> wrote:
>mb=VAL(SUBS(morder,3,1) + VAL(SUBS(morder,5,1))
>mb=VAL(SUBS(STR(mb,2),2,1))
> I'm having the same problem understanding the computation of the
>"mb" variable.
The 3rd digit was added to the 5th digit
This sum could have 1 or 2 digits, eg 1 or 11
Mb is the right most digit of the the sum of
the 3rd and 5th digit, eg
  3rd = 1 and 5th = 1 Mb = 2, subs("02",2,1)
  3rd = 7 and 5th = 5 Mb = 1, subs("12",2,1)
Ususally, the result of a CHEKSUM is divisible by
10 (eg right most digit will be "0")
T


--