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
number
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
Regards,
Chris
More information about the gnucash-devel
mailing list