currencies

[Dave Peticolas]

At last a response! I was beginning to wonder if my message got through :)


Christian Stimming writes:
> 
> > 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;

It would still have damount which, as now, would represent the number
of units in the parent Account's security.

It would also have the component 'value', representing the number of
units in the Account's currency. Also, whether or not this approach is
adopted, we are switching to a fixed-integer representation for
quantities.


> 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.

I think we would still need to enforce a common currency. Otherwise,
the notion of a balanced transaction doesn't mean much. Remeber, we
can balance using either the currency or security, currenctly.


> 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. 

This approach definitely raises some UI issues. In my final example,
the transaction:

Transaction: A                 25USD (25USD)
             D  11DEM (25USD)

Could also have been:

Transaction: A                 25USD (11DEM)
             D  11DEM (11DEM)

Choosing between them would probably need to be done by the user,
though hopefully with appropriate defaults.


> 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.

We are still going to store prices, but not in Splits. We could still have
the user enter them in the register, though.

dave