Rounding in the price db.

[John Ralls]

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