Rounding in the price db.

John Ralls jralls at ceridwen.us
Thu Aug 13 05:06:09 EDT 2015


> On Aug 13, 2015, at 8:22 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> On Thursday 13 August 2015 00:55:49 Mike Alexander wrote:
>> --On August 12, 2015 at 10:23:09 AM +0200 Geert Janssens
>> 
>> <geert.gnucash at kobaltwit.be> wrote:
>>> I'm not really sure about the price entered vs F::Q price. I would
>>> imagine that if you are tracking stock, you would be interested in
>>> the  exact real price you bought/sold it, which is not necessarily
>>> exactly  the price you get from F::Q. Wouldn't that mean that the
>>> price entered  should be preferred over F::Q prices at least in some
>>> cases ?
>> 
>> I was thinking about multiple currency transactions when I said I
>> would prefer F::Q prices to transaction prices in the price DB.  For
>> stock, etc., transactions your point makes sense.  In that case the
>> price implied by a buy or sell is more likely to be a "real" price
>> that should be recorded in the price DB.  On the other hand, my
>> experience is that the transaction price is more likely to match the
>> F::Q price for stock transactions so it matters less which you use. 
>> Considering all this, I guess I still prefer to use F::Q prices over
>> transaction prices in the price DB if both exist.
>> 
>> To address another point, the Advanced Portfolio report only uses the
>> price DB to calculate the current value of the commodity (and other
>> things derived from current value such as unrealized gain).  Basis and
>> realized gain are always calculated from actual transactions and
>> their implied prices.  I'm not sure about other reports.
>> 
>>            Mike
> 
> What the Advanced Porfolio does looks like the right way to do it. If 
> other reports don't, they need an update.
> 
> Well, I certainly learned a lot in this thread. From what I understand 
> now:
> - The price db is only intended to calculate the value of a 
> stock/foreign currency at any point in time different from the buying or 
> selling transaction (or values derived from this like unrealized gains).
> 
> - In situations where the exact buy or sell price is needed it can 
> simply be calculated from the transaction itself.
> 
> - The prices of these two moments are added to the price db 
> automatically to enable reports and the account hierarchy overview to 
> work by default on foreign currencies/stocks.
> 
> I apologize I had all of you make such a big detour getting this clear 
> just to be back at the original point: how to deal with multiple prices 
> in one day ?
> 
> For my proposal I'm starting from these assumptions we all seem to agree 
> upon:
> 
> 1. Prices in the price db should only be used for "current" value 
> calculations and are irrelevant for buy/sell transactions themselves.
> 
> 2. Since we don't track time on transactions, only one price per day 
> makes sense in the price db.
> 
> 
> With that in mind I agree with Mike that the F::Q should probably be 
> preferred at all times. Only if no F::Q price is available the user 
> entered prices (be it via price or via amount) come into play.
> 
> Then back to the question as to what should happen if the user enters 
> more amount based prices in one given day ?
> - if it's the first price for that day, just add it
> - if an F::Q based price for the day is already in the db don't add a 
> transaction calculated price at all. We clearly prefer F::Q prices for 
> current value calculations.
> - if there are already (non-F::Q) prices for that day, compare them to 
> the calculated new price. If they would result in the same conversion 
> (so difference is less than 1 SCU), don't add it. Otherwise ask the user 
> which price to keep for that day as only one price per day makes sense. 
> In the other case I don't think we can come up with a sensible algorithm 
> to make a computed decision on which price to keep. So we either keep 
> two prices or ask the user which one to keep.
> 
> Is that reasonable ?

I think so, mostly.

First, there’s one other use for the price db: It provides the default price to the transfer dialog (gnc_xfer_dialog_update_price()). The current behavior aggravates some people because every entry tweaks the amount slightly so the user has to keep editing the value in the transfer dialog. As you can imagine this is irritating. For an extreme case see the thread in the user list (http://lists.gnucash.org/pipermail/gnucash-user/2015-August/061581.html) from a user in the Cayman Islands, which has its own currency but which has pegged it to the USD. 

In examining the transfer dialog price-update code I noticed that there’s an exception for the currencies that have been absorbed into the Euro. The case of our user from the Cayman Islands and the possibility of Grexit makes me wonder if we should have a different way of dealing with that. Those currencies’ prices are never updated, but that might change for the Drachma, and while the Cayman Islands fellow was arguing for similar treatment for his currency it’s entirely possible that the Cayman Islands might change the rate from time to time just as the Chinese government changes the rate on the Yuan/RMB.

It’s obviously my hope that the 1 scu rule will prevent any jitter, but we should be prepared to adjust it if necessary. Mike proposed early on that we treat differently prices that are entered vs. those that are calculated so that they’re not subjected to jitter, but that makes me a bit nervous. We’d obviously have to tag them differently in the pricedb and it would create a new precedence: F::Q, user-direct, user-calc or some such. Is that worth considering?

Another related thought: Answering a dialog box every time one enters a two-currency transaction is going to annoy anyone who has to enter a bunch of such transactions. I can think of several ways of dealing with that, in order of my preference: A radio button on the transfer dialog whose last value is retained, an “always do this” checkbox on the what to do with the rate dialog, or a preference setting. Which do you prefer (ignore the problem is another option)?

Regards,
John Ralls




More information about the gnucash-devel mailing list