about check number heuristics

[Ethy H. Brito]

On Tue, 23 Jan 2007 09:25:01 -0500
Derek Atkins <warlord at MIT.EDU> wrote:


> >> There is not much to do on the OFX side, the check number is defined as 16 
> >> ascii characters, so 000123 is perfectly valid, and different from 123.  So 
> >> the only advice I can give your is to enter 000123 in Gnucash as well.
> >
> > I already did that. However there is a little problem: GC autoincrement
> > does not respect that and suggests "124" as the next check number instead
> > of "000124" which in turn break the importation again.
> >
> > Maybe it is a bug, isn't it?
> 
> Nope.  The autoincrement feature treats the check# as a number, not
> a string.  So I dont see the bug in the autoincrement.  Imagine, what
> should the autoincrement do if you have:   A1200?   What abnout 000A172?
> And how is this different than what you're asking for?

I learned quite some time ago first ask if something is a misbehavior and
then ask some changes if so. I am not still asking anything. Be cool man!

I was not aware how GC treats check numbers. I was in doubt about it. Now
I can see that in imports-backend.c GC compares them as strings not
numbers (in opposition of what you said above). that is why I commented
about autoincrement.

So we have two weights and two measurements: one when GC uses autoinc it
treats check numbers as "integers" and another when it matches a
transaction when importing. Is my reasoning right?

If I am right it is obvious that I cannot use autoinc the way I've been
using it. I'll have some manual work to do before inserting a check. I see
no penalty in that since I also have no effective suggestions that cover
all the cases you mentioned above (maybe some user controlled sprintf
string argument like "%06d" or "A%4d". just ideas in the wind).

> 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?

> 
> -derek

Ethy