Currencies / the accounting equation.

[Bill Gribble]

More thoughts about the currency stuff.  I think there are at least
two issues here which keep getting conflated, but it's hard to keep
them apart.  Sorry about the rambly length.  I'd appreciate any
thoughts.

About the global A = L + E problem and accounting currency:
-----------------------------------------------------------

For commodity holdings, right now we are accumulating the current
value of the asset as the account balance.  That means that when the
price of your stocks go up, the "A" term in the global "A = L + E"
increases.  To balance this out, you have to increase the Equity by
adding an unrealized profit/loss term.

We don't ATM have any mechanism for computing/including the unrealized
gain/loss (current value - cost basis).  It doesn't really even show
up in the reports; I can't find a report or display that vaguely
resembles A = L + E.  The "balance sheet" report doesn't show anything
of the sort (I'm looking in 1.4 reports; I've broken 1.5 reports in my
development tree).  It's my opinion that we should be doing this on a
more-or-less continuous basis in the main window.  We want A=L+E to
always be true and visible, meaning we need to include the unrealized
stuff as a visible Equity account line (maybe it's not a real account,
though).

So the other problem (the one Dave originally raised) is that we can't
even add A = L + E up because of currency issues.  Accounts in
different currencies, etc.  From the accounting standards perspective,
we *must* have a "functional currency" to do the balance sheet in.
The various FASB standards describe how to value foreign-currency
transactions in the functional currency.  FASB is mainly US, but there
are equivalents for everyplace else.  I think FASB 52 is really enough
to solve our problem (my intl accounting book has a better summary
than the one on the web page).  For each type of account, you use
either current, historical, or average exchange rate, depending on
what a table tells you to do, to translate amounts to the functional
currency.

Combining this approach with an "unrealized gain/loss" account will
make it possible to sensibly calculate and display the accounting
equation, I believe.

Removing the Account's currency pointer.
----------------------------------------

taking the functional currency/reporting/unrealized stuff into
account, I'm leaning more to remove the "account currency".  The
account security is the widget type that you are accounting for, and
each exchange split has a commodity * for the "currency used to buy".

We would have to have historical and current prices for every stock
and currency you have accounts in, as a direct quote from the
functional currency; but the accounting equation problem is less
nasty, and the main-window display becomes a little nicer; the
"balance" of the account is the number of shares/widgets/etc, but the
display shows a nice tabulation of functional-currency translations in
the next column.  This also makes the Euro-patch display problem go
away; if Euro is the functional currency, all account balances would
get translated and displayed along side their "native" (FRF, GPB, etc)
balance.

Problems remain. There are 3 ways to note a simple exchange
transaction:
	
	With EUR as the common currency:

	Acct		DR			CR
	bank (USD)	                        USD 100 (EUR 105)
	cash (EUR)	EUR 105 (EUR 105)

	With USD as the common currency:

	bank (USD)				USD 100 (USD 100)
	cash (EUR)	EUR 105 (USD 100)

	With both as the common currency:

	bank (USD)				USD 100 (EUR 105)
	cash (EUR)	EUR 105 (USD 100)

If there's a commission split, it has to be in the common currency, or
else we have to choose the Both option, and the UI would have to have
some way of saying "I want to make the other currency common so I can
put the commission in the other currency".

However, if we choose Both, what happens if we get :

	bank (USD)				USD 100 (EUR 100)
	cash (EUR)	EUR 105 (USD 100)

This would be very unnatural, but could happen.  There's an imbalance
of EUR 5, so I suppose that means a rebalancing split (under the
proposed new rebalancing strategy); but even then we have choices (I'm
assuming that the rebalance split will go into some account but I'm
not sure which):

Rebalance and keep both currencies common:

	bank (USD)				USD 100 (EUR 100)
	cash (EUR)	EUR 105 (USD 100)
	REBALANCE acct?                         USD 0 (EUR 5)

Rebalance, avoiding the weird USD 0 == EUR 5 split; but if we do this,
then suddenly EUR is the only common currency. Not catastrophic but
does change the transaction:

	bank (USD)				USD 100 (EUR 100)
	cash (EUR)	EUR 105 (USD 100)
	REBALANCE acct?                         EUR 5 (EUR 5)
        
Don't add the rebalance split to an account, so that it doesn't have a
security, and just put the currency pointing to the unbalanced
currency:

	bank (USD)				USD 100 (EUR 100)
	cash (EUR)	EUR 105 (USD 100)
		                                0 (EUR 5)
        (the 0 with no currency meaning there's no account pointer 
	in the split).

The GUI could enforce this not happening... I think...  In any case,
the "transfer to" account picker would now show all accounts, and
would have to pop up a dialog if the securities were different to ask
what the amount in the remote account is.  This could address the
problem of the "price == 1" in the stock register if you enter the
purchase from the bank side.  It would be nice to auto-popup a
question "How many shares are you buying?" when you credit the bank
account and select the stock a acct in transfer-to.  There's already a
string in the commodity definition that stores the plural name of the
commodity (shares, dollars, etc).

Register issues: in the above example, directly transferring 100 USD
to a EUR cash account.  Since we don't show the split affecting "this"
account, from the USD end you will see a withdrawal of EUR 105 from a
USD-security bank acct, and from the EUR end you will see a USD 100
deposit, unless you pick the "both common currencies" approach and the
register is smart about which number it picks.  You still have the
problem of showing the commission split in the register that's not
showing the currency of the commission.

Other unresolved issues: where do the historical prices go?  Which one
you use is a function of which standard you want (i.e.
time-of-transaction or time-of-report); maybe it should be dynamic,
meaning that the price doesn't get stored with the split.
Ramifications for re-generating reports?  Linas suggests that we might
just "freeze" the historical database when books are closed.  How do
you compute the basis of your holdings in a stock if all the
purchase/sell splits aren't in a common currency?  Does that mean you
have to use the reporting currency?

b.g.