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 

Related but somewhat separate, does it make sense to record more than one price 
per day in the price db? If so, should we suppress saving the price if it’s 
unchanged, perhaps within some tolerance, of the previous entry on the same 
day? If not, do we keep the first entry or overwrite every entry so that we end 
up with the last (entered) entry for a particular day?

The point would be to not store a bunch of data that we don’t use and to 
present users with more useful defaults in the transfer dialog when they’re 
entering a bunch of transactions for the same day and the same 
currencies/commodities. What are the possible bad impacts, particularly in 
reports, especially the Advanced Portfolio Report?

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Reply via email to