New transaction matcher
Christian Stimming
stimming@tuhh.de
Mon, 25 Nov 2002 23:58:30 +0100
-----BEGIN PGP SIGNED MESSAGE-----
On Montag, 25. November 2002 23:08, Benoit Grégoire wrote:
> > > I honestly think you got the right basic idea for the matcher, and that
> > > it's clearly the best idea (at least for now). As you might have
> > > guessed, there's a number of things I would like to change,
> >
> > Sure, go ahead and propose improvements. Of course for me everything's
> > obvious, so your suggestions are definitely helpful.
>
> -Right now, any added split are added balanced, no matter what you select
> (that is even the case in my old matcher now I checked). This caused me
> to start hunting for bugs in the OFX module, until I realized the matcher
> added it's balancing split in the SAME account as the source account.
Really? I cannot reproduce that here, or at least not for HBCI. In HBCI, the
imported transactions without destination account show a "Unspecified" in
that column. If I just press OK, these transactions will show up in the
register with the nifty crossmarks, showing that they are not balanced.
So if you don't see this with OFX -- you might consider checking back with how
you created that transaction. It's not a bug that shows up from HBCI, so I'd
guess it doesn't belong to gnc-gen-transaction.c / Transaction-matcher.c.
> This is a bug, but illustrates a more fundamental problem: The user is now
> FORCED to use double entry.
As I already said -- from HBCI, the unbalanced transactions are left
unbalanced but clearly marked as such in the register.
> -The actions must go back to the main window.
No :-)
Seriously. I have written the message with "The Usual HBCI Scenario" to point
out that I have a bunch of assumptions that I consider to hold when users are
importing through HBCI. From that scenario, I derived the use cases which
really boil down to the fact that the [HBCI] user does not need any further
choices than the two shown in the main importer window. Therefore, if you
propose GUI changes in that respect, then I can only agree if the HBCI code
can specify configuration arguments so that the [HBCI] user won't get more
choices than he does now.
And, yes, the Matcher-popup-dialog still shows the "Action" column in the
upper listview, but as you might have realized, it doesn't do anything right
now (or at least I didn't intend it to do anything). In fact, I only left it
there because I wanted to keep compatibility to the former GUI structure and
because I was too lazy to program something different.
> The actions would now be: [...]
As long as you implement any further actions in a way so that the HBCI
protocol code can still call the GUI in its current simple form i.e. switch
them off, I'm fine with anything.
> -There must be visual feedback that the match was inconclusive.
I disagree. Right now, there are two possibilities: Either a good enough match
was found -- then it's displayed there. Or no good enough match was found --
then the "New" column is marked. If the user thinks that there should have
been a matching transaction, he should click on the "New" column and happily
find his (fuzzy-matching) transaction in the matcher-dialog. IMHO this is
just enough. Remember, in "The Usual Scenario" only 10% of the transactions
are not new. Therefore I'm pretty sure that the duplicate-matching will, in
some way or the other, be able to present enough potential duplicates to the
user. Also remember that in HBCI, the amount of duplicate transactions match
exactly in 99% of the cases. Therefore in HBCI, I really don't need much
fuzzy matching here -- the exact matching account is already a good enough
criterion.
> I suggest
> we color the row in light red (or a tiny warning flag maybe?). Also, the
> score pixmap for the top match should be included in the main window if
> action is to reconcile.
Again I disagree. I want this GUI to be f**ing simple and stupid (I think
that's known under the acronym KISS). I already argued about which choices I
think are relevant for 90% of the transactions. Any further GUI elements that
are relevant only to a minority of the transactions should absolutely be kept
*out* of the big list.
Again, if you want to implement it in a way so that for the usage from HBCI it
can be switched off / made invisible, then I'm fine with anything. Also note
that if my GUI concept just doesn't give you enough freedom to add more
features, you are absolutely free to return to your initial
Transaction-matcher GUI. Really, and that's not even too much of an effort
duplication (since the gnc-gen-transaction code already uses 90% of the
Transaction-matcher code). It would just acknowledge the fact that in HBCI, I
can use yet more assumptions to get the simplest GUI possible, whereas in
OFX, you see reasons that judge building a much more complicated and
feature-rich GUI.
Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iQCVAwUBPeKrFmXAi+BfhivFAQHoOwP9FCX6BU44Acs7DHOX943tCIrXfaJRlXCF
QzdBawbpILrkyMJqfNQHTO3WOXasTWiTx7AWSrUMyXUP96H5NTwSAWaRY5FLubLW
pMsMz3w7CTCi74md+rp1E3/Lsr8Aa/xUnUNM24SGxgQraUKX6ljhtYEkkYOCcC+m
CKEnA5TQE2M=
=zSoh
-----END PGP SIGNATURE-----