-----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----- _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
