about check number heuristics

Chris cxl000 at hotmail.com
Tue Jan 23 18:57:05 EST 2007

On Tue, 2007-01-23 at 11:32 -0500, Derek Atkins wrote:
> Quoting "Ethy H. Brito" <ethy.brito at inexo.com.br>:
> >> now, perhaps the importer could try to be more intelligent and attempt
> >> both a "string compare" and "numeric compare" against the two entries
> >> and accept it if either way matches.
> >
> > This is part of the problem as you already stated, but it is very welcome.
> >
> > I'll play with the code. May a patch be submited?
> Patches are always welcome..  (but they may or may not be applied,
> depending on the quality of the patch)  ;)
> > Ethy
> -derek
Here is a possible solution.
assumption: if the numeric part overflows then we are likely to be onto
a new cheque book and will have the manualy correct the cheque number so
it does not matter what we produce. e.g. 999 => 1000, 0A999 => 0A1000

There are 3 cases
1) the string is numeric with 0 or more leading 0's. e.g. 00123, 999
2) the string contian non numeric prefix. e.g. 0A999
3) the string is non numeric. e.g. ABC

Case 1:
     use length if cheque number string to format length of printed
     format namber with leading 0's
     increment the number
Case 2:
     extract the non numeric prefix.
     increment the number
     print the prefix followed by the number
Case 3:
     This is probably not a cheque number so search back until you find
one that meets case 1 or case 2.
     If you cant find a suitable candidate treat it as a degenerate form
of Case 2. e.g. "ABC" => "ABC" 0 => ABC1


More information about the gnucash-devel mailing list