problem with edit exchange rate
Peter Selinger
selinger at mathstat.dal.ca
Sat Apr 14 08:34:20 EDT 2007
Peter Selinger wrote:
>
> Probably the best remedy would be to simply disallow exchange rates of
> 0.0 in the engine (negative exchange rates are already prohibited
> anyway). This would solve problem (2), and would force the UI to deal
> with (1).
I have done some further testing and isolated some further problems
with exchange rates in the engine.
First, I believe I see the reason why an exchange rate of 0.0 (i.e., a
quantity of 0 with a non-zero value) has been allowed in the engine.
Suppose I enter a simple transaction between two accounts with
different currencies.
(x) Suppose I enter 0.01 as the amount. The currency dialog pops up,
and I enter 0.3681 as the exchange rate. Then the "To Amount" in the
dialog is rounded to the closest penny, i.e., 0.00 (the dialog does
not actually like this, so you have to enter it twice to get it
accepted). The engine, however, does not record the exchange rate that
I entered; instead, it records 0.01/0.00 (or 1/0) in the
pricedb. Later, this transaction will be uneditable from certain
account views.
(y) Suppose you enter 0.01 as the amount, but 1.5781 as the exchange
rate, so the "To Amount" is 0.02. What gets added to the PriceDB is
2.0000, and not the 1.5781 you entered. Later, when you go to "edit
exchange rate", you are presented with 2.0000 as the default rate, and
not the 1.5781 you entered (this info apparently is not taken from
the PriceDB, but from the transaction itself by dividing 0.02/0.01).
Situation (x) shows that it sometimes makes sense to have a "quantity"
of 0, so unlike what I suggested before, this should not be disallowed
by the engine. However, situations (x) and (y) also show that it would
be better if the engine stored the "intended" exchange rate (i.e., the
one the user entered) along with "value" and "quantity", so that, when
prompted for further rates, this value can be used as a default
(rather than taking the actual ration value/quantity or
quantity/value, which can lead to division by 0, and which gives
wildly inaccurate answers in any case).
-- Peter
More information about the gnucash-devel
mailing list