Rounding in the price db.

Geert Janssens geert.gnucash at kobaltwit.be
Thu Aug 13 03:22:08 EDT 2015


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 ?

Geert


More information about the gnucash-devel mailing list