On Thursday 13 August 2015 00:55:49 Mike Alexander wrote: > --On August 12, 2015 at 10:23:09 AM +0200 Geert Janssens > > <[email protected]> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
