tutorial on multi-currency accounting

[Mike Alexander]

--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
> correct.
>
> 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
> transactions.
>
> 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
> gains/losses.
>
> 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 
is off):

- 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