Transaction balancing

[Derek Atkins]

I think it's a bit more subtle that that.  Each import mechanism has
different 'strings' to match on.  QIF, for example, has a PAYEE, MEMO,
DESCRIPTION, Category, and I think "Account".  OFX has different
strings to search on.  HBCI is different from both the above.

I do not think there is a one-size-fits-all system.

On #gnucash I suggested that the matching logic might be best off
being done in Scheme -- that would allow simple upgrades or
plugability of the matching algorithm.  In either case, benoit and I
agree that this is *NOT* a 1.8.0 feature (as it's not a BUG, and we
_are_ supposed to be in feature freeze at the moment).

After 1.8 is released (and we branch the sources) we can think about
adding this feature... and then _maybe_ backporting it to 1.8 once we
get it working.

-derek

Chris Morgan <cmorgan@alum.wpi.edu> writes:

> I'll see if I can come up with something.  I was going to first add a sea=
rch=20
> textbox that will select all entries with the specified text, then start =
work=20
> on the automatching.
>=20
> Chris
>=20
>=20
> On Tuesday 21 January 2003 10:29 pm, Benoit Gr=E9goire wrote:
> > On January 21, 2003 03:57 pm, Chris Morgan wrote:
> > > Does it seem that everyone agrees on the necessity to do string match=
ing
> > > on imports?  At the most basic level it would be nice to have a text =
box
> > > at the bottom of the import window that lets you enter a string to se=
arch
> > > for. You could use this string to highlight entries in the import list
> > > then the mass assign them to another account.  That would mostly solve
> > > the issues I had when I so poorly decided to start importing 3 years =
of
> > > credit card transactions.  One extra step would to be to have gnucash
> > > "learn" where transactions are assigned but this is more complex and
> > > probably not as necessary.
> >
> > It already "learns" where transactions are assigned.  The only problem =
is
> > that currently, it only uses what it has learned on the next import.  D=
erek
> > already filed a RFE on this.  I also had to import nearly a year worth =
of
> > transactions recently and ran into this annoying limitation, so you can
> > hope for this feature somewhere in the 1.8 series.
> >
> > However, I am not touching this before 1.8 is released (we are in featu=
re
> > freeze), and it will be fairly delicate to implement properly.
>=20
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

--=20
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available