tutorial on multi-currency accounting

[Chris Shoemaker]

On Tue, Mar 06, 2007 at 03:54:05PM -0500, Mike Alexander wrote:
> --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.

I assume this is done by auto-creating currency-accounts?

> - 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.

I think it's likely that users will want to see both in some cases.
This is one of the things that is much easier with the register
rewrite.

> - 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.

I don't know if this will work as a preference in the long-term.
Being a preference means you might have some transactions created
while it's on and some while it's off.  Unless that preference is
recorded in each Transaction, it might be better to leave the
calculation of unrealized gains in the report.  (Of course, it would
still need to be fixed up in that case.)

> 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.

Brave, brave man.  Good luck.

-chris

> 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