mirror of
https://github.com/Gnucash/gnucash.git
synced 2024-11-29 20:24:25 -06:00
83d14e1c1c
It is split into - /libgnucash (for the non-gui bits) - /gnucash (for the gui) - /common (misc source files used by both) - /bindings (currently only holds python bindings) This is the first step in restructuring the code. It will need much more fine tuning later on.
59 lines
2.6 KiB
Plaintext
59 lines
2.6 KiB
Plaintext
/** \page currencies Currency Issues
|
|
|
|
API: \ref Commodity
|
|
|
|
From Bill Gribble <grib@billgribble.com>
|
|
Tue, 3 Oct 2000 11:09:54 -0500
|
|
|
|
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.
|
|
|
|
*/
|