New transaction matcher

[Christian Stimming]

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