tutorial on multi-currency accounting

[Peter Selinger]

Derek Atkins wrote:
> 
> Quoting Mike Alexander <mta at umich.edu>:
> 
> > I attached a new patch to 131623.  As I said in the comments on the
> > attachment, it also includes an option to turn off computation of
> > unrealized gains entirely.  This is needed with the changes to use
> > commodity trading accounts since those accounts record unrealized gains
> > and the balance sheet report shouldn't compute them if trading accounts
> > are being used.  Having the option in without trading account support
> > may be a bit confusing but shouldn't hurt anything and this way I know
> > the patch works.
> 
> I'm really not sure I agree with the concept of trading accounts.
> I think it just confuses the issue even more.   How about "hidden"
> equivalences?  Instead of balancing it in a Split, per se, we balance
> it in a KVP?  That way:
> 
> 1) it's not visible
> 2) you always know which pseudo-split is the auto-balance split
> 3) you dont add additional accounts
> 4) did I say "it's not visible" yet?
> 5) it doesn't add additional splits to the transaction that could just
>    confuse the user.
> 
> I really think "trading accounts" is the WRONG approach for this problem.

I don't see it as a moral issue; I think it is a question of user
preference. 

As Mike already pointed out, nobody has to use these accounts unless
they want to. However, I think there is evidence that properly working
trading accounts would be useful to a number of users (I have already
heard from several of them). Such users make more than casual use of
foreign currencies and would like their currency support to be
transparent (i.e., visible and verifiable).  This includes small
business users such as myself, who need this feature for tax purposes.

Your argument is a bit akin to arguing that double-entry accounting is
confusing to users and should be hidden away from the user, with the
software pretending to do single-entry accounting (and doing the
double-entry stuff automatically in the background, or worse, in the
report system). This works only for very simple applications.

Essentially Gnucash currently uses double-entry accounting for
single-currency stuff, but a glorified version of single-entry
accounting for multi-currency stuff. This may be adequate for many
users, but it is a definite limitation for others. 

The feature that Mike is implementing is non-disruptive: it simply
allows users, at their choice, to "turn on" double-entry accounting
for multiple currencies, and provides some (optional) UI support for
editing multi-currency transactions. 

-- Peter