transaction match problem/misbehavior

[Benoit Grégoire]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 31 August 2004 09:26 am, Ethy H. Brito wrote:
> Hi people.
>
> I'm a home user of gnucash 1.8.9 for about a month. Used to run Quicken
> before. First of all I'd like to say I am not comfort with accounting
> jargon in english, second sorry if I may sound confuse. That's because I
> realy am.
>
> I have this problem when matching transactions with the OFX data I download
> from my bank every week.
>
> There is this every friday government tax called CPMF in my country.
> The CPMF was shown as new unmatched transaction at the first time I did the
> matching two weeks ago. The problem is GC does not show it at transaction
> match window as a new one anymore despite the fact I can see it inside the
> OFX file with differents number and value from last week. I think GC is
> confusing the new CPMF with the old one (already reconciled). I now always
> have to insert it manually at account register window. Is that correct?
> Can't it  be done semi automaticaly anymore like the first time transaction
> match window saw CPMF ? Or even better: what am I doing wrong?

If you don't even see it in the match window (and you neither imported as new 
or reconciled that specific transaction before) it means that the unique id 
of the transaction is the same, implying a bug in your bank's software.
 
> What is the logic GC uses to match a transaction? I mean does it first
> compares 'Description' fields and then values and then 'Number' or does it
> use another logic?

It does seval different matches.  A full answer would take several pages (It's 
in the mailing list archives however), but here is a summary:

Step 1:  Check if transaction was already imported.  If a transaction with the 
same unique id (this is NOT the check number) exists in the source account, 
skip the entire transaction.

Step 2:  Check for a matching transaction in the source account.  This uses 
heuristics using the description, memo, date, amount and check number, each 
of which increases or deacreses the "score" depending if the field matches, 
matches partially our doesn't match.  The total "score" is represented by the 
colored bars you see when you reconcile the transaction is the result of 
those heuristics.

Step 3:  Pick a target account for new transactions.  This is a Bayesian 
filter which uses your historical choice of account to pick a default 
destination account.  It gets better over time.

> Another question is why GC does not show the transacion number at
> transaction matching window? Some times GC mismatch transactions of the
> same value and I can only see that (with some luck) at register window. For
> example I have this 50 bucks withdrawal and a check of the same value. GC
> took the withdrawal from OFX value and marked the check as 'm'! I have to
> say I forgot to register the withdrawal (that would have been shown as a
> new unmatched transaction. Wouldn't it?).

The answer to your first  question is that that that column isn't0 shown 
because that window is already very large we can't really add too much 
without exceding the screen space of some people.  I chose not to display the 
check number because it will normally always pick the right transaction for a 
check, except in some corner cases, and you just hit one.  

The algorithm can probably be tweaked to fix it (by giving large negative 
score to a check number mismatch).  I'll try to do it before the next 
release.  I DO suggest that you open a bug report on that, make sure the 
words: "ofx" "check" and "number" are in the title of the report.

- -- 
Benoit Grégoire, http://benoitg.coeus.ca/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBNISpmZ6zzPlLuwMRAoHGAKCtC5MTnn0Wl4a9qEQwczQe3uS5lQCgxDci
pXwK2hU6osiqK0uJvlskkkQ=
=EVDk
-----END PGP SIGNATURE-----