Latest  2014  2013  2012  2011  2010  2009  2008  2007  2006  2005  2004  2003  2002  2001

This personal blog comprises whatever I feel like saying on any given day, which often involves topics like new media, journalism, Web technologies, Racket/Scheme/Lisp, Free and open source software, societal issues, cinema film, Boston, frugality, and humor. Many things noted here are solely for the benefit of future Web searchers trying to solve particular esoteric problems, and are not of general interest. This blog is largely insulated from my professional life, and vice-versa. I attempt to provide full disclosure of potential conflicts of interest. Last time I checked analytics, my site was getting over 1000 unique visitors a day.

GnuCash and Leaf Account Names

In GnuCash, I've found that changing ledger preferences to show only leaf account names is a win, but it gets problematic with all the GnuCash accounts involved in a single brokerage account, so I have a measure to mitigate that.

GnuCash accounts are organized into a tree (hierarchy), and by default, a transaction in a ledger for one account will refer to the corresponding account using a name that is an absolute path to the account in the tree. For example, "Assets:Current Assets:Bank Deposits:BofA Checking 1234". This looks ugly in the ledger, takes up lots of horizontal space or gets truncated, and is tedious to enter with text autocompletion. The leaf name "BofA Checking 1234", however, is short and unambiguous.

Fortunately, GnuCash has a user preference setting:

Edit → Preferences → Register Defaults → [X] Only display leaf account names

Enabling this is generally a win, and probably most of your account leaf names are already unique. One place where unique leaf names is problematic, however, is investment accounts. Let's say you have an IRA with Broker Investment Trust Co., with an account number ending in 2345, and the IRA is split between two investments, so the account hierarchy looks like:

Broker IRA 2345

(You include the last 4 digits of the account number in the name because you have multiple IRAs at Broker, or because you've found that over time including the number helps as accounts come and go, and when you get statements and such.)

Later, because the money in your savings account is being devalued like crazy, you open an investment account with Broker, invest in a few funds/stocks, and that hierarchy looks like:

Broker 7890
    Open Orders

Now your account names are no longer unique, and you're asking for an error, such as crediting a BRK.B purchase to the wrong brokerage account, or crediting cash to the wrong account. Which could result in expensive financial mistakes.

So, what I'm doing currently, when using leaf-names-only in ledgers, is appending the brokerage account name to the brokerage subaccounts, in square brackets:

Broker 7890
    Cash [Broker 7890]
    Open Orders [Broker 7890]
    Positions [Broker 7890]
        BRK.B [Broker 7890]
        IVV [Broker 7890]
        FCNTX [Broker 7890]

This looks ugly in the Accounts hierarchy view, but when leaf-name-only in ledgers, it's readable and unambiguous. "BRK.B [Broker 7890]" does not get confused with "BRK.B [Broker IRA 2345]".

This also works well with autocomplete. When entering the name in a ledger field, you start by typing, say, "brk" and then, when that's ambiguous, you see a list of the the options, and can pick the right one.

For reports, I'm coding to have the qualifier be hidden when appropriate, so that my hierarchy views and such don't show the qualifier at all. For example, here's a modified version of a procedure from balsheet-ng.scm:

(define (account-link account)
  (let* ((name                   (xaccAccountGetName account))
         (name-without-qualifier (cond ((string-match " *\\[.*\\]" name)
                                        => (lambda (m)
                                             (regexp-substitute #f m 'pre "" 'post)))
                                       (else name))))
    (if opt-use-links?
        (string-append "<a href=\"gnc-register:acct-guid="
                       (gncAccountGetGUID account)
                       (escape-html name-without-qualifier)
        (escape-html name-without-qualifier))))

Which means, in my report, the hierarchy looks like this (no qualifiers), but I still get the qualifiers in the GnuCash GUI when they're helpful (and sometimes when they're not):

Broker 7890
    Open Orders

Prior to delimiting in square brackets, I tried separating with an at-sign (which was too ugly), and using colon with the ancestor name in front (potentially confusing when GnuCash convention is to use colon for hierarchy paths, and ancestor-first is less readable in ledgers). The main thing I don't like about the square brackets is that some conventions use parentheses for negative values.

Other than brokerage accounts, leaf-name-only seems an obvious win so far. The workaround for brokerage accounts seems OK. Ideal would be for GnuCash to have some kind of disambiguating qualifiers be built-in, but I think that's a low priority, and probably also would be controversial.

GnuCash Balance Sheet Stock/Fund Values Bug & Fix

I mentioned this informally to some GnuCash developers, so maybe there will be a fix in GnuCash 2.6.4, but until then...

If you run a Balance Sheet report, the USD (or whatever the report currency is) values for stocks and funds will be 'wrong'. Wrong, compared to the numbers you see in the similarly tree-looking, all-important Accounts view. Wrong, by your presumable desire that the report give you a somewhat accurate indication of the value of your assets. (Well, perhaps it's actually right, for reasons only an accountant could tell us, but work with me here.)

If you want the current value of stocks and funds to be used, the fix is to go to the Report Options for the report, and change the Price Source option, under the Commodities category.

I could not find this fix through Web searching, and had to read the code.

If you happen to have made your own customized report, using GnuCash 1.6.3 file balance-sheet.scm as a starting point (and if you haven't already been reduced to tears by nonexistent API documentation and not-so-idiomatic Scheme code), the culprit is the symbol average-cost in the code:

 options pagename-commodities
 optname-price-source "b" 'average-cost)

Perhaps an accountant could tell me why average cost is the most appropriate default here. Maybe accountants account for unrealized losses/gains on stocks and mutual funds in some other GnuCash accounts, separate from the asset accounts. And maybe indicating a value derived from average cost makes sense somehow, even though stocks and mutual funds tend to be liquid and their current market values known to the minute and to a fraction of a penny. Maybe that's the standard for a balance sheet, and us non-accountants, who are just naively toying with GnuCash for personal finance, are abusing the balance sheet report to show a breakdown and summary of assets and liabilities.

That might well be the case, I don't know. But I'm making an assets&liabilities report for us personal finance toy people, and it will show current value of stocks and mutual funds. Accountants will be jealous, when they see how cool our reports are.

GnuCash for Consulting Hours Tracking and Invoicing

I'm experimentally using GnuCash accounting software for tracking consulting hours for one client. So far, this looks like it will work pretty well, although not perfectly, but should save some time and avoid some potential errors from retyping information.

The basic idea is very simple and obvious: enter the daily invoice line item into a new GnuCash invoice as you go, use the Description field for notes on what you did each day (though this might be used only as notes for a separate manually-written summary report, not be printed in the end invoice), and eventually make minor tweaks to the invoice and post it at the end of the billing period.

Some notes:

  • I upgraded from GnuCash 2.4 to 2.6 first, since 2.6 has substantial invoicing improvements. Since I use Debian GNU/Linux Stable version for this and most other purposes, and since Debian Stable is frozen at GnuCash 2.4 until the next major version of Stable, I installed GnuCash 2.6 from Debian Backports.

  • While building the invoice for time-tracking, I'm specifying the invoice number to GnuCash according to the format "new-<SYMBOLIC-CUSTOMER-CODE>-<SYMBOLIC-JOB-CODE>". For example, my invoice-in-progress for company JimCo, on the Foo job, would be numbered "new-jimco-foo". Then, immediately before posting the invoice, I change the GnuCash invoice number to the format "<YYYY><MM><DD>-<SERIAL-NUMBER-FOR-POSTING-DAY>"; for example, "20141231-1". Having all the invoice numbers of invoices-in-progress begin with "new" also means that it's easy to get a list of them in GnuCash, in the usual way of loading up an invoice, which is to search for it by partial invoice number ("new").

  • If you're tracking time in few-minute increments, such as some lawyers do, then GnuCash is not well-suited as the front-end tool for time-tracking. But if you're only working on one or two POs per day, you can have the GnuCash invoices open on another virtual desktop, and intermittently add quick notes in the Description field for the days' line items, on what you did and how long it took. At the end of the day, total the time and rewrite the quick descriptions as 1-3 sentences that could in theory be viewed and understood by the client.

  • The only big limitation I see for my needs is that sometimes I have work hours for a day that must be split across two purchase orders, when subcontracting on certain kinds of projects. My old way of tracking this split was in a bit of Racket code, which let me have a work description for a day along with the allocation for each PO right there. With GnuCash, even if it let me split invoice line items across two invoices, I think that bit of functionality would be unlikely to have been tested well, and something would break in the software. The relationships involved in GnuCash representing invoices are already hairy enough, and hard to undo errors, as it is. I'll have to see how this goes, in practice, the next time I have a day's work split across POs.

  • I now have to re-code a script to generate an invoice in the format needed by this client. I have written this invoice formatting script a couple times over the years in Racket, and now I'll do it once more, in the Guile embedded Scheme and reports API in GnuCash. The two drawbacks I see to this are: (1) GnuCash's Guile API was originally intended for end users to use for this purpose, but was never really documented, and now they're moving towards Python and less scripting; (2) it will take me substantial time but is not billable.

  • Depending on how the next invoice's line-item descriptions compare to the next manually-written summary report I write for this experimental client, I might see whether client would prefer that I just print out a report with the descriptions from an invoice. That might save work for me, and save billable hours for client.

  • Since invoices-in-progress represent substantial revenue that I wouldn't want to lose due to a software bug or system failure, a quick redundant backup is to print out the one-page invoice-in-process each day and leave it on my office printer. Using the default GnuCash invoice format will capture both the hours and the descriptions of work, which could be retyped if necessary.

I'll see how it goes, but now that I've invested a couple Sunday evening hours into this approach, it looks like it will save some time on a daily basis, and be more reliable. I still have to find non-billable discretionary time to write that custom invoice format Guile code, however.

UPDATE 2014-09-15: I made the custom invoice report, and it took way too much time.

Earlier to... 2014-09-04

© Copyright Neil Van Dyke      Contact