-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris schrieb: >>>> 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. >> > 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
Are you talking about the matching rules of imported and/or downloaded transactions? OFX, QIF, HBCI or which one? In case this concerns OFX or HBCI (whereas QIF is different), do I understand correctly that you're talking about the function split_find_match() in src/import-export/import-backend.c, especially (svn-trunk) lines 659ff? Thanks, Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRbjKLGXAi+BfhivFAQL8VgQAtygRQIdIJMH3tDvaGUjTDtYb4GauG8lK /yb6QLxvswm5qB4Hz32IeTuarmfICmX9CPzO9obIde3F1PHvO7Cmcl2CvvtsZO2I VhjKcSueysUVo/sFJyjw/hXtYMs5IpCeREw+E0cU+wB+WKntiYMt0eoVfKPm1kKg D8mt7M8AIZY= =BZC1 -----END PGP SIGNATURE----- _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
