Currencies / the accounting equation.

[Bill Gribble]

On Sun, Oct 01, 2000 at 07:22:31PM -0700, Dave Peticolas wrote:
> I think this is where our understanding differs. I have never
> understood the 'value' as something being exchanged. It's the value of
> the 'damount' being exchanged in whatever currency you are doing your
> accounting for that account. What you exchanged for that quantity is
> in the 'damount's of the other split(s).

I am willing to accept that point of view, though I somewhat stick to
my original position... consider a stock purchase (100 shrs @ $10)
with a commission of $50.  bank CR $1050, stock DR 100 shrs/$1000,
commissions DR $50.  The exchange of dollars for shares is of 100
shares for 1000 dollars IMO.  However, I don't think we are losing
anything significant by using the semantics you suggest, and it's
probably more correct overall.

> Right now, it seems like we have multiple interpretations for the
> same transaction and that makes me uneasy.

I agree.  We need to fix a single way of dealing with this that
addresses all of the concerns.  Maybe we should list the
problems/requirements to make sure we are talking about the same
thing.  I know I've repeated several times that I believe the
"eliminate Currency accounts" problem-set is separable from the
"global A=L+E" problem-set; I'll list them all together here, because
I think it's just a "feature" of some particular solutions that they
are separable.

  - we want to eliminate the need for currency trading accounts.  From
    a user interaction perspective, this means we need to allow
    transfers directly between accounts denominated in different
    commodities.
  - we want transactions to have clear and unambiguous balancing
    semantics.
  - we want to store the actual amounts of commodities involved 
    transactions rather than price and quantity.
  - we want to be able to globally check and display the terms of the
    accounting equation (and all account balances) in a
    user-selectable functional currency.

I think the following bits will address the first three issues above.
Basically I'm just agreeing with your last suggestion, Dave; Rob and I
hammered on it on a white board and weren't able to poke any holes.

  - Eliminate the 'currency' from the Account structure.  Add a
    'currency' to the Transaction structure.  Each transaction's
    'currency' is by definition the balancing common currency for the
    splits in that transaction.

  - Eliminate the 'share price' field from the Split structure and
    replace it with a 'value' field.  The 'value' is a translation of
    the Split's 'damount' (which is the amount of the Account's
    security involved) into the Transaction's balancing currency.

The balancing semantics of this approach are unambiguous, no existing
balanced gnucash transactions would be disallowed (the transaction's
common currency just gets saved in a pointer) and the fuzzy
distinction between the account's currency, security, damount, value
is cleared up.

About the last point, the global accounting equation.  Evaluating this
equation requires the computation of current asset values and
unrealized gains/losses.  I believe this is possible in a
straightforward way using the reporting framework, a user-selectable
functional currency, accepted accounting policies, and a historical
price database.  There has been discussion about moving to a
report-based main window; if that were to be the case, we could make
the accounting equation readily visible to the user.

Thoughts? 
b.g.