Rounding in the price db.

John Ralls jralls at ceridwen.us
Wed Sep 16 23:23:15 EDT 2015


> On Sep 16, 2015, at 8:42 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> 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 <mailto: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 <mailto:jralls at ceridwen.us>>
> > >> To: Geert Janssens <geert.gnucash at kobaltwit.be <mailto:geert.gnucash at kobaltwit.be>>
> > >> Cc: gnucash-devel at gnucash.org <mailto:gnucash-devel at gnucash.org>
> > >> Subject: Re: Rounding in the price db.
> > >> Message-ID: <4A7C3475-9787-4346-BFD7-F086DCD7870C at ceridwen.us <mailto: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 <mailto:david.carlson.417 at gmail.com>  <david.carlson.417 at gmail.com <mailto:david.carlson.417 at gmail.com>>
> > >> To: jralls at ceridwen.us <mailto:jralls at ceridwen.us>, geert.gnucash at kobaltwit.be <mailto:geert.gnucash at kobaltwit.be>
> > >> Cc: gnucash-devel at gnucash.org <mailto:gnucash-devel at gnucash.org>
> > >> Subject: Re: Rounding in the price db.
> > >> Message-ID: <000f4259.651417a17ddc3837 at gmail.com <mailto: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,

You could certainly set up two commodities with different symbols for the two exchanges. F::Q also has certain multi-source sources, named things like ‘europe’, ‘asia’, and
so on. I haven’t experimented with how they work, but it’s probably not what you’re looking for. In the case of stocks the symbol changes depending upon the exchange so
there wouldn’t be a way to associate multiple stocks with a single currency. Commodities like precious metals and foreign exchange for speculative purposes might be different, I don’t know. Note that for anything heavily traded such differences tend to be very short lived: There’s a class of speculation called arbitrage that involves making countervailing trades on two exchanges to exploit such price differences and it tends to correct them rather quickly.

But what would GnuCash do with the information that a particular commodity is trading at different prices in different places? Pick the higher or lower or take the average for computing market value? 

Regards,
John Ralls


More information about the gnucash-devel mailing list