Rounding in the price db.

[Geert Janssens]

On Wednesday 16 September 2015 06:52:14 John Ralls wrote:
> > On Sep 16, 2015, at 12:01 AM, Chris Good <chris.good at ozemail.com.au> wrote:
> >> Message: 1
> >> Date: Sat, 12 Sep 2015 12:20:46 -0700
> >> From: John Ralls <jralls at ceridwen.us>
> >> To: Geert Janssens <geert.gnucash at kobaltwit.be>
> >> Cc: gnucash-devel at gnucash.org
> >> Subject: Re: Rounding in the price db.
> >> Message-ID: <4A7C3475-9787-4346-BFD7-F086DCD7870C at ceridwen.us>
> >> Content-Type: text/plain; charset=utf-8
> > 
> > ...
> > 
> >> Rounding is now fixed and pushed.
> >> 
> >> There?s one change I?m holding back on: If I make it so that
> > 
> > Finance::Quote
> > 
> >> can?t overwrite a price added in the Price Editor (i.e. one of
> >> source
> >> user:price-editor) as David Carlson suggested last week, then the
> >> ?fetch quote? button is broken because price-quotes.scm only knows
> >> how to write the prices into the pricedb. This is a per-day
> >> effect: A user-created> 
> > quote
> > 
> >> from a different day won?t block the F::Q quote, so maybe it?s an
> > 
> > acceptable
> > 
> >> corner case that just needs to be mentioned in the docs and the
> >> button?s tooltip. Ideally the button should disable in this
> >> situation, but I?m not> 
> > sure
> > 
> >> yet whether that?s feasible.
> >> 
> >> Comments?
> >> 
> >> I should add that I want to merge this ASAP so that it will be
> >> available> 
> > in the
> > 
> >> nightlies for testing before the next release, which is only two
> >> weeks> 
> > away.
> > 
> >> Regards,
> >> John Ralls
> >> 
> >> 
> >> ------------------------------
> >> 
> >> Message: 2
> >> Date: Sat, 12 Sep 2015 18:50:36 -0700 (PDT)
> >> From: david.carlson.417 at gmail.com  <david.carlson.417 at gmail.com>
> >> To: jralls at ceridwen.us, geert.gnucash at kobaltwit.be
> >> Cc: gnucash-devel at gnucash.org
> >> Subject: Re: Rounding in the price db.
> >> Message-ID: <000f4259.651417a17ddc3837 at gmail.com>
> >> Content-Type: text/plain;	charset="utf-8"
> >> 
> >>    I could accept your proposal if it is documented. I think a user
> >>    could> 
> > still go
> > 
> >> in later if he didn't like the online price for a certain date.
> >> Sent from my LG G Pad 7.0 LTE, an AT&T 4G LTE tablet
> >> ------------------------------
> > 
> > Hi John,
> > 
> > Sorry for the late reply, needs must...
> > 
> > I haven't understood all your previous comments about this but
> > thought I'd weigh in anyway.
> > Can there only be 1 price record per stock/date?
> > 
> > I would have thought the primary key should be stock/date/source and
> > that the advanced portfolio rpt should get actual cost details from
> > the stock transactions and market price details from price records.
> > If there are multiple price records of the same stock/date, then
> > the advamced portfolio rpt should use say using source
> > user:price-editor first, then a price from FQ, (then others...)
> > 
> > AFAIK, it is not critical that the market price be accurate as the
> > costs/values on the stock transactions should be accurate.
> > That's why I suggested prices from FQ should use the date returned
> > by FQ and assume that if there is already a price record for the
> > same stock/date from FQ, then the new price should override the
> > older.
> 
> Chris,
> 
> Please read over the thread again carefully. We’ve already discussed
> all of that in some detail. In particular, actual cost for reports
> comes from the transactions, not the price db.
> 
> Regards,
> John Ralls
> 
> 
Chris' mention of the primary key should be stock/date/source triggered another question in 
my mind. So far I always considered "source" in this context to be F::Q vs user input vs 
whatever other means.

But now I started wondering is gnucash/F::Q supports tracking multiple stock exchanges for a 
single stock ? (Eg track gold price on both London stock exchange and on Amsterdam stock 
exchange) ?

Geert