Connect currency exchange transactions and pricedb, or not?

[Christian Stimming]

-----BEGIN PGP SIGNED MESSAGE-----

Fundamental question: Should currency exchange transactions be connected with 
the pricedb, and if yes, how?

In gnucash-1.6, the currency exchange transactions (curr-exch-txns) were not 
connected at all with the price db. Instead, every curr-exch-txn was forced 
to go into or come from an account of type currency. The price and the 
from-amount and to-amount could be edited in the currency account register, 
where the shown price was updated according to the amounts and vice versa. In 
the backend, however, the price inside one of these curr-exch-txn was never 
stored explicitly; instead, the price represented through a particular 
curr-exch-txn could be computed on-the-fly simply by the ratio of the 
different amounts involved. I'd call this an "implicit price". This is used 
in the multi-currency-capable reports (balance sheet, profit and loss etc.) 
when the user chooses "Weighted Average" as price source.

In gnucash-CVS/1.8, curr-exch-txn are now allowed to go into and come from 
*any*  type of accounts. We still need to come up with a register GUI or 
dialog that will properly represent all the possible choices and values to be 
adjusted. In the register of currency/stock/mutual-fund accounts, the 
register itself is already a GUI for that case. But for all other types of 
accounts, we still need to come up with a GUI. 

During the implementation of that dialog/GUI, Derek came to the conclusion 
that the prices in a curr-exch-txn can no longer be calculated implicitly for 
the general case. Instead, in a non-balanced transaction or in a txn with 
more than two splits, the prices involved cannot be calculated on the basis 
of the amounts involved. Therefore Derek (if I understand correctly) proposes 
to store the prices of a curr-exch-txn explicitely in the pricedb.

IMHO this has major implications on the overall handling of multi-currencies. 
E.g. in my book, all 1000 curr-exch-txns are of the above sort with "implicit 
prices". There the txns are not balanced because I specified a particular 
price, but instead because I specified a from-amount and a to-amount and said 
that those two amounts make up a balanced txn. Because of the "balanced" 
constraint you were able to calculate an implicit price from that 
curr-exch-txn on the fly. Contrary to that: If we now say that the price of 
those curr-exch-txn should be stored explicitly in the pricedb, we must 
provide a connection between the originating curr-exch-txn and its price in 
the pricedb. Because when I change something in the curr-exch-txn, I expect 
the price calculated from it be changed as well. This is probably true the 
other way round as well (or maybe not?): If I edit a price in the pricedb, 
where the price originated from an existing curr-exch-txn, the amounts in the 
curr-exch-txn might need to be changed as well (or maybe not?).

This leaves us with already quite some places that need new code: 
- - The register GUI (which Derek is working on), 
- - the pricedb editor, 
- - the multi-currency code in the reports, 
- - and the code for upgrading a 1.6 data file (in Scrub.c et al)

Actually I wouldn't mind if we decide that this general case is just way to 
complicated. So instead of introducing the constraint "every curr-exch-txn 
must have a price created in the pricedb", we could introduce other 
constraints alternatively. E.g. "A curr-exch-txn is only allowed to have 
exactly two splits" or "A curr-exch-txn is only allowed to have one split in 
a foreign (i.e. non-txn) currency" or something like that. Note that this is 
still more relaxed than the 1.6 constraint, which was "The foreign split of a 
curr-exch-txn is only allowed to exist in a currency account".

Of course it's impossible to do all of this until tomorrow, 1.7.4. 
Nevertheless this feature is a *critical* feature that *has* to exist in 1.8, 
because otherwise people with a multi-currency setup cannot use Gnucash. 
Therefore I'd propose to continue working on this feature until 1.7.5 (Dec 
15), and for the rest of the release plan pick the "relaxed schedule" with 
final 1.8 version in January. (Benoit, as for Holiday -- that's pretty much 
independent of whether we come out with 1.8 or not; before the release we're 
busy with fixing bugs and after the release we're busy with fixing bugs as 
well. So that doesn't make a difference here.)

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iQCVAwUBPejP0mXAi+BfhivFAQF2fgQAupsWwlYrbVpH8qvQy6tiBvdPo0aLQuCs
RS/QneutxLaoxPDPmz0pntTmGQCvZR4mz3kWu2Bjvg4feSmQRKUiBmBHA0Lx4kO8
q+tHXgGsu+aeR3zK8DU2Xh8iuoKDhktG43A+s2IfPstNZcWBZWuaf2klaYDVDT5X
gbXAJF1vh30=
=AuU+
-----END PGP SIGNATURE-----