On Sunday 09 August 2015 19:29:51 Mike Alexander wrote: > --On August 9, 2015 at 8:35:04 PM +0100 John Ralls > <[email protected]> > wrote: > > A recent IRC conversation and a discussion (face to face!) with a > > user got me thinking about the prices entered from the transfer > > dialog into the price db. The current situation is that when the > > user > > creates a transaction between accounts with differing currencies and > > commodities, the transfer dialog comes up to get either a price or > > the value in the “other” currency. The user duly enters a number > > and GC does the appropriate calculation, rounding the value to the > > max denominator for the “other” account’s currency/commodity, > > then recalculating the “true” price without the rounding and > > saves the result in the price db. The user could do several entries > > with the same nominal exchange rate and get a different exact > > fraction for each because of the rounding of the value. > > > > Does that really make sense? Should we round the price we store in > > the price db to some reasonable fraction? What fraction? The > > smallest > > commodity unit (scu) of the “value” currency/commodity seems > > reasonable to me. For example, if the entry is of how many US > > Dollars buys a Euro or a share of Ford stock, the price should be > > rounded to the scu of US Dollars, i.e. cents. OTOH some mutual funds > > price in mils ($.0001), so perhaps we should round the price db > > entries to > > No, that doesn't make sense. I've been bothered by this for some > time. > > However, I don't think rounding to the SCU of either commodity is > correct. Suppose the SCU of A and B is 2 and the official exchange > rate from A to B is 1.500555 (my bank quotes rates to 6 decimal places > when I buy foreign currency). If I first convert 2.00 A to 3.00 B by > entering this exchange rate in the transfer dialog it would record an > exchange rate of 1.50. Later a value of 2000 A would be converted by > default to 3000 B, not 3001.11. I think you need to record more > digits than the SCU. Ideally you should record exactly what is > entered in the transfer dialog if the user enters a price rather than > a destination value. If they enter a destination value then you > probably should record at least 6 places after the decimal point. > > Things get tricky if the ratio is very small. The current rate for > USD per Sao Tomean Dobra per USD is 0.0000444615. if you rounded > this to 0.000044, you lose a lot of precision. If someone enters a > transaction of 1000 Dobra to USD .04 (unlikely, but valid) then the > recorded rate to 2 places would be zero which is clearly a bad idea. > I seem to remember that banks here use 6 significant digits in exchange rates, which is not quite the same as 6 places after the decimal point. Your USD-Sao Tomean Dobra illustrates this: due to the extreme value difference between the two you need 10 digits after the decimal point, but only 6 of them are significant (ie not a leading zero).
Is this something our gnc_numeric code supports and can be used by the price db ? Geert _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
