Comments / Suggestions / a couple minor bugs in 1.7.5

[Brian Smith]

First, let me start by saying that GnuCash is the best 
open-source finance app out there, and I’ very 
grateful that there are folks willing to work thanklessly 
on providing it. I’m saying this because without 
this preamble, my comments below might sound like a rant.

I’ve managed to get GnuCash 1.7.5 compiled on my 
Mandrake Cooker system. I’ll start by saying that I 
had major problems at first getting all the libraries to 
install correctly - to fix it, I had to use the 
distro’s libtool instead of the one in the GnuCash 
tarball. If you guys see anyone who complains that 
’make install’ creates a bunch of 
lib<something>.so.0.0.0U files and doesn't install those 
libraries, that might be their problem as well. Anyway, on 
to the nitty gritty. Here are the problems I've run into 
so far, some of them are 1.7.5 specific, some are not.

First, the closest thing to a show-stopping bug I've found 
in 1.7.5: some of the text fields (e.g., the status bar at 
the bottom of windows, the amounts at the bottom of the 
reconcile window) are not redrawing correctly. It's like 
text is never erased from the fields before being 
repainted. It's only a cosmetic problem in most places, 
but it makes reconcile impossible to use.

Next, there are a few problems with the new loan setup 
feature. The first thing I noticed is it doesn't show you 
the calculated payment amount until almost the end. To me, 
it seems that the calculated amount should be shown at the 
very beginning. It would even be nice if you could enter 
the P+I amount and have GnuCash compute either the 
Interest Rate, Number of Payments, or Loan Amount (the 
loan wizards in 'those other programs' do that).

Another thing that was not intuitive to me was that if you 
have an escrow amount, it looks like you need to erase the 
formula from one of the screens and put the actual total 
payment number in its place. Then there's a dropdown box 
that selects additional payment to Principal, Interest, or 
Escrow. What would seem more logical on this screen is to 
have an addition chart like this (I hope this looks OK):

    LOAN PAYMENT:  P + I amount:   1197.38     <--- 
calculated by GnuCash
                   Escrow amount:  _______     <--- 
user-entered (if escrow
                                                    is 
applicable)
                   Tax amount:     _______     <--- only 
shown if tax is *not*
                                                    paid 
through escrow
                   Insurance amt:  _______     <--- ditto
                   PMI amount:     _______     <--- ditto
                   Add'l amounts:  _______     <--- this 
could open a split
                                                    window 
for extra amounts

                   Total Payment:  2105.48     <--- 
calculated by GnuCash

This would allow for folks who have escrow *and* plan to 
pay extra principal, or people who use auto-pay services 
that charge an extra per-transaction fee (Countrywide, one 
of the largest mortgage firms, has programs that do that).

The tax, insurance, and PMI amounts could then be handled 
on one screen. GnuCash already knows whether they're paid 
from escrow or as part of the payment, so all it needs to 
know are the expense accounts to debit and how to schedule 
the transactions if they're not part of the loan payment.

Finally, I'll add that unless I did something wrong, 
GnuCash never actually put the transfer to the escrow 
account in the scheduled payments. It also did the 
scheduling screwy. My first payment date was 2/1/2003, and 
I had yearly tax and insurance payments from the escrow 
account set for 11/1/2003 and 7/1/2003 respectively. 
Everything looked fine on the chart that came up before 
the finish page, but when the transactions were actually 
scheduled, the first occurences were 3/1/2003, 11/1/2004, 
and 7/1/2004. The scheduled transaction editor showed the 
correct first dates as the 'transaction last occured' 
dates, as if they had already happened.

To quote Forrest Gump, that's all I have to say about 
that. Now on to the only other area in which the 
proprietary competitors still have an edge: investments.

First, what is the correct way to account for a stock sold 
for a profit? A buy at one price and a sell at a higher 
price will increase total assets, but there is no credit 
to an income account. So the balance sheet gets 
unbalanced. Should the sale be shown at the original 
price, and an income account created to make up the 
difference so the total sale goes to the cash account? 
This keeps the accounting balanced, but if you look at 
your stock transactions the sale price isn't correct. It 
would be nice if GnuCash could handle this internally, 
displaying the real sale price but internally balancing 
the sell transaction with an income account, like the 
following example:

On 1/1/02, I buy 10 shares of XYZ at $5 each. The 
transaction credits Cash $50 and debits Stock:XYZ 10 
shares, with a $5 price.

Now on 3/1/02, I sell my 10 shares at $7. The transaction 
credits Cash $70, debits Stock:XYZ 10 shares, with a $7 
price displayed but an internal 'pretend' $5 price, and 
credits Income:Capital Gains $20.

Incidentally, it would be nice if transactions entered in 
the register would update the security's price. This isn't 
a big deal for publicly-traded securities where quotes can 
be pulled from the Internet, but many mutual funds aren't 
publicly traded, and it would be nice if you could just 
enter the transaction off the statement and the price get 
updated so that your total balances stay correct without a 
trip to the Price Editor. While I'm wishing, the Chart of 
Accounts should display two balances for stock accounts: a 
share balance, and a balance in the main currency of the 
file. Actually, this would be nice for any account which 
is not in the main currency of the file.

The other investment thing that needs a bit of work is 
dividends. There are two scenarios to deal with, dividends 
paid in cash and dividends reinvested. The reinvested 
dividends are really simple to track, I just enter a 
purchase for X shares at $Y and credit Income:Dividends. 
For dividends which pay out to cash, though, there is no 
change in share balance, just a credit to Income and a 
debit to a bank or cash account. This seems simple to 
enter, but if you just enter it in the cash account, 
there's nothing tying the income to the specific stock 
which paid the dividend. Ideally, I guess, the transaction 
would be entered from the stock account, would debit cash 
and credit income, and have no effect on the share 
balance. This is sort-of how I enter it now, but the 
dollar amount can only be seen in the cash account, not in 
the stock account.

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.

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.

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.

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.

I hope this hasn't been too long of a thing to read. I'd 
like to hear any comments or suggestions, or even 
criticism if there's something I'm obviously doing wrong 
somewhere.

Thanks,
Brian