Connect currency exchange transactions and pricedb, or not?

[Derek Atkins]

Christian,

You unfortunately did not understand my intentions and you
misrepresented my views.  While your history of "how it's done in 1.6"
is correct, you clearly have not looked at the issues involved here or
listened to what I'm trying to do:

1) When viewing an account in auto-split or ledger mode, the "amount"
   displayed in the register is the value in the transaction currency,
   not the account currency.  This means that if the currencies do not
   match (because you're viewing the transaction from another
   account), the value "looks wrong" (because it is not the account
   currency).  This was bug #99083.

   The way to fix this is to always display the amounts in the account
   currency.  The problem is that while you can compute this IFF the
   transaction is balanced with exactly two splits, that is not
   generic.  The only generic way to compute the exchange rate is to
   store it elsewhere -- hense the plan to use the pricedb.  (Note
   that I did re-open 99083 do deal with the "balanced, 2 split txn"
   case).

   Note that if there is no pricedb entry, then it will display
   "incorrectly" just how it is currently displayed incorrectly --
   meaning there is no change from the status-quo if there are no
   pricedb entries.  (also note that once I fix the above issue, old
   txns should be fine iff they are balanced and only contain
   2-splits).

2) The plan to use the pricedb is to store _one exchange rate per
   commodity-pair per day_.  In other words, it is _NOT_
   per-transaction.  Similarly, the pricedb entries are only used for
   display purposes..  The transactions will still contain the exact
   same information they do today.  In particular, each Split will
   still contain the "amount" (in its account currency) and the
   "value" (in the transaction currency).

3) The other reason to use the pricedb is to help user entry.  If a
   user is entering a lot of transactions between different
   currencies, it would be nice to remember the exchange rate so it
   can be re-used.  If it's stored in the pricedb, then we can just
   pull it out from the db and use it -- saving the user some time.
   (this is part of bug #97690).

If you can come up with another way to deal with imbalanced,
multi-split, multi-currency transactions, I'm all ears.  I couldn't
think of any way to deal with them other than using the pricedb.
Similarly, if you can come up with a decent way to "remember" the
exchange rates from day to day for multiple inputs, again I'm all
ears.

-derek

Christian Stimming <stimming@tuhh.de> writes:

> 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
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available