From Bill Gribble grib@.email@example.com@firstname.lastname@example.org@m.om 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.
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.
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.