currencies

[Christian Stimming]

> What to Do?
> 
> Common Commodity
> 
> One solution would be to require that every GnuCash data file
> use a single user-selected commodity for valuation purposes.

This solution doesn't sound very appropriate. a) It would be tempting to
see USD 100 and DEM 100 as interchangable values with a fixed rate
between them -- which is definitely not the case. b) It isn't unusual to
have accounts and transactions dealing purely with one currency (USD)
and ones dealing purely with another ({DEM,FRF,EUR...}). A Common
Commodity would definitely not be a good model for that. Tons of
rounding errors is the first problem I could think of due to a model
mismatching like this, but there will probably be more to come.

> Currencies in Splits
> 
> If we associated currencies (values) with Splits, instead of
> Accounts, then the need for Currency accounts would disappear.
> In that case, Accounts would only have one commodity, the
> commodity being counted. 

This approach sounds much more interesting. However, I don't understand
fully what this would mean. What will have to be changed? As far as I
can see: 

a) The struct _split will probably have the components

double damount;
char * currency;

instead of currently (TransactionP.h:115)

double  damount;     /* num-shares; if > 0.0, deposit, else paymt */
double  share_price; /* the share price, ==1.0 for bank account   */

b) The function xaccSplitRebalance(Split *) will have to be changed. Now
it checks for a common currency of all splits in a transaction
(Transaction.c:1009). If this is not the case it exits the program. If
this is the case the function forces all split's values to sum up to
zero. In contrast to this: If each split may have a different currency,
then this function can only force the sum to be zero when all split's
currencies are identical. Otherwise it must not do anything but trust
the user that she entered the values right.

c) The UI for the register: The currency accounts would disappear
altogether. This means that splits with all sorts of currencies can
appear in any account's register. It will be necessary to distinguish
the different currencies. My proposal would be (although I have no idea
how to code it) that every value in the register is displayed with its
corresponding currency... Or at least those currencies different from
the account's currency. 

d) Dave's example transaction A(25USD) -> D(58DM, current rate
unfortunately) is fully described by the two different values and their
currency. However, sometimes I don't know one of the values but I only
know an estimated exchange rate. For example, I have a german credit
card with currency DEM and make a purchase in the U.S. which results in
an expense in USD. The receipt shows only the USD value and I know an
approximate exchange rate with which I can estimate the DEM value. I
will know the exact DEM value and exchange rate only about 6 weeks later
when I receive my credit card company's statement. Conclusion: I like
the "Price"-field in the currency account register and I would like to
have a means for entering an exchange rate even when the currency
accounts have disappeared. My proposal is (although I can't do it) to
incorporate something like the former "price"-field into the transaction
dialog, along with a selection list for source and destination currency.

Christian