OFX Transaction Matching

[John P. New]

Benoit,

Didn't mean to bug you, just wanted to make sure you had received the
emails.

I did have some comments about the transaction matcher, but I didn't
want to deal with too many issues at once. Since you are working on the
transaction matcher now, here are some of my observations (although you
probably know these already):

1. When transaction matching, the transactions get imported into the
account being matched BEFORE they have been matched. This has two nasty
side effects:
	a) The 'perfect match' the matcher presents is in fact the .ofx file
transaction, not the transaction that is in the gnucash account, and
	b) If the transaction matcher operation is cancelled, the unmatched
.ofx file transactions are left in the gnucash account, having not been
matched and with no split information entered. Ugly :-(

2. In the 'Potential splits matching the selected transaction:' window
(right side window), the 'Description' column actually corresponds to
the gnucash account transaction 'Notes' field, instead of the actual
'Description' field.
	a) The 'Description' column of the 'List of downloaded transactions'
window (left side window) does not contain anything, even though the
.ofx file contains descriptions

3. When changing the selection in the 'Potential splits matching the
selected transaction:' window (right side window), the 'Action' column
of the 'List of downloaded transactions' changes from 'RECONCILE' to
'ADD', when really it should stay as 'RECONCILE'. Let the user change it
to 'ADD', since he is the one doing the matching, not gnucash (gnucash
should just present the best options).
	a) If you really think that 'RECONCILE' should change to 'ADD", then
the 'The selected downloaded transaction should' choice should change
from the 'reconcile the selected match' button to the 'be added as a new
transaction' button.

4. After the matching has been done by the user and the 'Apply' or 'OK'
has been pressed and the transaction entered, those .ofx file 
transactions marked as 'ADD' simply get dumped into the gnucash account
with no split information, which means the account has to be opened, the
new transactions found and the splits entered. See below for what my
recommendations are.

Having said all this, I don't like how the transactions are being
reconciled. I don't think there is enough information being presented
when matching to make a complete decision about the match.

Here is my take on how the process should go:

1. 'Previously Matched Transactions' dialog: Present to the user those
transactions which have been matched already from a previous matching
session. If you download .ofx files often, then there will be a mix of
new and matched transactions in every .ofx file. There should be some
way of correcting a bad match at this point: highlight a 'bad match' and
push a 'Correct Bad Match' button. This would flag this transaction as
unmatched, to be dealt with in the next step.

2. 'Unmatched Transactions' dialog: Present the user with the
transaction matching screen, where a corresponding gnucash account match
has been found (where a 'match' is considered as confidence >= 5 (4,
maybe?); however, I would redesign the dialog somewhat. I picture a
message box that says: 'Gnucash has found a transaction from your online
bank statement that has not been matched to a transaction in your
gnucash account.' and underneath displays the .ofx file transaction.
Under that, if a match is found, another message: "Gnucash has
determined the best match from your GnuCash account.'; underneath, show
the gnucash transaction offered for a match. Then there would be a
button, labelled 'Next Match', that would choose the next match GnuCash
has found, so the user can scroll through the list of matches in order
of confidence. Below this would be the four buttons that would choose
whether to ADD, RECONCILE, REPLACE or IGNORE the .ofx transaction being
matched.

As for how the transactions (both ,ofx file and proposed gnucash account
match) should be presented, I would present then the same way as they
would be in a gnucash account window, when transactions are viewed with
the 'Double Line' and 'Auto-split Ledger' options selected from the
View/Style menu, with the same the colour styles. This way there is as
much info as possible presented to the user to a) make an informed match
and b) change anything that needs to be changed in the transaction that
GnuCash/User has picked for a match. This would also mean that the user
doesn't have to learn another way to view transaction info; it will be
familiar to him.

If the user presses 'Next' (for next transaction) without entering the
split info for an ADD, RECONCILE, or REPLACE action, a warning should
come up asking for the split info.

3. 'Unmatched Transaction' dialog: Present the user with the transaction
matching screen, where a corresponding gnucash account match has NOT
been found (where a 'match' is considered as confidence < 5 (4, maybe?).
The message box says: 'Gnucash has found a transaction from your online
bank statement that has not been matched but has not found a
corresponding match in your GnuCash account.' and underneath displays
the .ofx file transaction. Below this would be two buttons that would
choose whether to ADD, or IGNORE the .ofx transaction being matched.

Present the .ofx file transaction the same way as it would be in the
gnucash account, when transactions are viewed with the 'Double Line' and
'Auto-split Ledger' options selected from the View/Style menu, with the
same the colour styles. This way the user can change anything that needs
to be changed in the .ofx file transaction before it gets dumped into
the gnucash account.

Note: Item 3. could be rolled into Item 2. if you don't like my
distinction between a 'match found' (confidence >= 5) and a 'no match
found' (confidence < 5).

4. There would have to be additional 'Next' and 'Back' buttons to go to
the next transaction or go back to the previous transaction.

Whew, what an email! I wasn't going to present this until the other
issues had been dealt with, but here we are.

Remember, you did ask for comments! :-)

John P. New
London, Ontario, Canada