tutorial on multi-currency accounting
mta at umich.edu
Tue Mar 6 15:54:05 EST 2007
--On March 5, 2007 11:26:57 AM -0500 Chris Shoemaker
<c.shoemaker at cox.net> wrote:
> Mike, Peter, et al.,
> I should have spoken up eariler, but have been pretty busy. I just
> now skimmed Peter's reports, and wanted to comment.
> First off, Peter's assessment of GnuCash's flaws are fundamentally
> I went through a similar process of research and conclusion about a
> year ago, when I started the register-rewrite branch. It turned out
> to be a lot more work than I expected, because I hadn't yet realized
> _why_ multi-currency didn't work in the existing register. Relative
> to GnuCash, my conclusion was that the existing register design is
> fundamentally incapable of being used to "do multi-currency"
> correctly. This is the cause of many of the very long-standing open
> bugs regarding multi-currency support.
> So, when figuring out how to make it work correctly, I found that I
> had to not only re-implement, but also re-design the register and many
> of the functions that ensure balanced transaction entry. The good
> news is that I believe that GnuCash's foundational Transaction and
> Split data structures can accomodate the "right way".
> Mathematically, the contraints and relationships in a multi-currency
> transaction are exactly the same as in a "stock" transaction, with
> capital gains/losses.
> Peter's recommendation that the register show the currency in each
> split is essential to any sort of reasonable interface to accurate
> While the use of full-blown trading accounts has some nice properties,
> there are also some smaller changes that would still be an
> improvement, even if it still meant calculating exchange gains/losses
> at report-time. Those changes would allow someone who wanted to use
> trading accounts manually to do so correctly.
> Fundamentally, I see this as a UI issue, and I believe that I've
> designed the new register in such a way as to support multi-currency
> transactions correctly, albeit still with report-time calculation of
> Mike, if you're up for it, I encourage you to take a look at the
> register-rewrite, and see if it supports multi-currency transactions
> correctly. Even if you're not, I'd be interested to hear more
> specifically which improvements you're working on. (BTW, I know you
> have outstanding patches filed in BZ that might relate to this
> functionality. I feel bad that they've been neglected, but the fact
> is, everybody's understandably shy to touch some of that messy code.)
> Just a status note about register-rewrite: It should be completely
> functional, just not very polished and not yet convenient to use. For
> evaluation, I like opening a new register and an old register
> side-by-side in adjacent tabs. (You can do this by double-clicking
> accounts in a budget, which still opens the old register.)
I'm glad we all mostly agree about what needs to be changed. I agree
that the current register code is a bit of a mess and doesn't support
this sort of change well. I'll take a look at the register rewrite,
but I think I've managed to make some changes that improve things with
the current register code and which hopefully will port to the new
register code without too much trouble.
Here's a brief summary of what I've done so far (all of these changes
are under control of a new preference and things work as before if it
- Changed xaccTransGetImbalance to return a list of all the imbalances
in the transaction. The list will contain an entry for each commodity
that is not balanced or for the transaction value if the new preference
is off and it is unbalanced. This required adding a new data type (or
at least I couldn't find an existing data type for it) similar to the
commodity-collector used in Scheme code. The old version is now called
xaccTransGetImbalanceValue and is still used in a few places.
- xaccTransScrubImbalance now scrubs the transaction two ways. It
makes sure the value is balanced, and it makes sure that the amounts
balance separately for each commodity in the transaction. This makes
capital gain splits as created by scrubbing lots unnecessary, although
existing capital gains splits won't hurt anything.
- gnc_split_register_get_debcred_entry shows the split amount instead
of the split value. It also shows the commodity symbol unless the
commodity is the register's commodity or the split has the focus.
- The balance sheet report (as patched for bug 131623) is changed to
not compute unrealized gains if the new preference is on since they
will already be accounted for if all transactions are balanced.
The main thing I haven't done yet (other than more testing) is to
change gnc_split_register_save_amount_values to be compatible with the
change to gnc_split_register_get_debcred_entry.
With these changes things seem to work more nearly the way they should.
It may be better to wait for the register rewrite to finish this, but I
think it is a step in the right direction. Let me know what you think.
Mike Alexander mta at umich.edu
Ann Arbor, MI PGP key ID: BEA343A6
More information about the gnucash-devel