janssens-geert at telenet.be
Thu Dec 5 10:52:57 EST 2013
On Thursday 05 December 2013 07:31:03 John Ralls wrote:
> On Dec 5, 2013, at 1:34 AM, Geert Janssens <janssens-geert at telenet.be> wrote:
> > When asking for an exchange rate, the transfer dialog looks up
> > existing exchange rates to propose the best match.
> > It looks for a match in this order:
> > from-currency -> to-currency, exact date
> > to-currency -> from-currency, exact date
> > from-currency -> to-currency, date nearest in time
> > to-currency -> from-currency, date nearest in time
> > The first search that returns a valid price is used.
> > My test data has prices in both directions and the
> > to-currency -> from-currency has prices closer to the date I'm
> > searching a price for. However with the above search order, it will
> > prefer the
> > from-currency -> to-currency rate, because that's found first.
> > Would it make sense to change the search to look for the nearest in
> > time regardless of conversion direction and use that instead ?
> I'm inclined to say that only same-direction, exact date exchange
> rates should be used, and even then only with caution. Currency
> exchange isn't free, and most US banks and CC companies charge for it
> by using a different rate in each direction (a "spread"), though some
> also impose a fee. Exchange rates also fluctuate; I think most banks
> here use the previous day's closing rate for a whole day, but some
> may update more frequently. Another problem is that prices/exchange
> rates are handled per-commodity/currency, the different spreads
> employed by different banks can't easily be handled automatically.
> The end result is that any automatic setting of a price/exchange rate
> is very likely to be wrong, at least for US users. Perhaps the rules
> in Europe are sufficiently different that it can work there, though
> it seems unlikely that a rate from a different date would be correct.
Thanks for the input. The search algorithm is only meant to propose a first exchange rate when
the dialog opens. The user is supposed to correct it. I fully agree that only a same day/same
direction rate is likely to be correct for all the reasons you mentioned. That rate is not always
available in the price database so a next best guess should be proposed.
That guess could have been any price available in the price database.
Whoever wrote the algorithm in the first place assumed that nearest in time is a better proposal
than last or first or current. And considering bug 630578 which triggered me to look into this,
other people seem to prefer nearest in time as next best guess.
But the algorithm prefers same direction of nearest in time. With my test data this is much
further off than preferring nearest in time regardless of direction. In the end it will remain a
guess in both preferences.
Question is, which guess would most users prefer?
More information about the gnucash-devel