Comments / Suggestions / a couple minor bugs in 1.7.5

[Benoit Grégoire]

> One last thing about 1.7.5: I'm not terribly fond of the
> OFX import transaction matching. Something similar to the
> way Q****en does it would be more intuitive. In case
> you're not familiar with it, the transaction matching is
> basically done in the register. Below the register is a
> scrollable list of imported transactions. AS you select an
> imported transaction, Q* selects the closest match. If
> there's not a reasonable match, it creates a transaction
> and selects it. The user can accept the match (or new
> transaction) or select a different transaction in the
> register to match, then click an Accept button to confirm
> the match. This is repeated until all the transactions are
> matched. Q* also allows this operation to be postponed and
> finished later, for instance if you can't remember what
> you bought at Wal-Mart and left the receipt at work.

The transaction import has been massively improved in 1.7.6 (unfortunately 
delayed because of a problem in a missing dependency).  Many of these 
usability issues may have been soved.  It's not really done the same way as 
Quicken however.  I would really like you to comment again once you try it.
 
> A nice side effect of the way Q* does it, is that a new
> transaction being imported can easily be edited in the
> register as it's being entered, for example a credit card
> company might have 'AMAZON-COM  1800xxxyyyy' as the payee,
> whereas I want it to just say 'Amazon.com'. What would be
> *really* cool is if the new transaction would try to
> auto-fill the payee with a close match from previously
> entered transactions instead of using the exact text from
> the imported file.

One feature still missing (but in the pipeline for 1.8.1) is manually editing 
an imported transaction in a register during import.  However, it will 
probably never change the transaction description and split memo 
automatically, as that would assume that the memo and description ARE the 
payee, and that the both don't contain usefull information.  Both can be 
false.  The new importer does however auto-select a destination account for 
new transaction based on the previous selections.

> Okay, I'm almost done (whew!). One final thing I think
> would be neat. Currently, a transaction has one payee that
> appears on every split line. It would be very cool if each
> line could have a separate payee field, so that a deposit
> could be entered which would show up as Deposit, then the
> individual checks from different entities could have
> different payee fields, so a report of income categories
> would show 'Fred Smith' and 'Joe Black' paid me money
> instead of just 'Deposit'. Currently to keep track of
> multiple payees, you need multiple transactions, but if
> you've really made one deposit at the bank this makes
> reconciliation (or OFX import) more difficult.

Assuming I understand your problem, no, you don't need multiple transactions!  
I think what you call the payee is actually the transaction's Description 
(one per transaction) and the split's Memo (one per split).  They are all 
independent.  Is because of the info your bank provide, Deposit end's up in 
every field.  However, you can change the Memo in the register (eventually 
during import also).  

> Another nice side effect - transfers between asset
> accounts could be labeled more intuitively. The debit to
> checking might say 'Transfer from Savings' and the credit
> to savings would say 'Transfer to Checking'. I realize
> each split already has a Memo line that can be used for
> this, but I think multiple payee fields would be better.
> If they're not used, the payee from the account in which
> the transaction was entered could just propagate to all
> the splits and everything would look just as it does now.

Humm, I don't understand what you mean, the splits have two descriptive 
fields.  One is the Memo, which can be freely edited, the other is the 
account, which can't.  

-- 
Benoit Grégoire
http://step.polymtl.ca/~bock/