jralls at ceridwen.us
Thu Dec 5 10:31:03 EST 2013
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.
More information about the gnucash-devel