> On Sep 16, 2015, at 8:42 AM, Geert Janssens <[email protected]> > wrote: > > On Wednesday 16 September 2015 06:52:14 John Ralls wrote: > > > On Sep 16, 2015, at 12:01 AM, Chris Good <[email protected] > > > <mailto:[email protected]>> wrote: > > >> Message: 1 > > >> Date: Sat, 12 Sep 2015 12:20:46 -0700 > > >> From: John Ralls <[email protected] <mailto:[email protected]>> > > >> To: Geert Janssens <[email protected] > > >> <mailto:[email protected]>> > > >> Cc: [email protected] <mailto:[email protected]> > > >> Subject: Re: Rounding in the price db. > > >> Message-ID: <[email protected] > > >> <mailto:[email protected]>> > > >> 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: [email protected] <mailto:[email protected]> > > >> <[email protected] <mailto:[email protected]>> > > >> To: [email protected] <mailto:[email protected]>, > > >> [email protected] <mailto:[email protected]> > > >> Cc: [email protected] <mailto:[email protected]> > > >> Subject: Re: Rounding in the price db. > > >> Message-ID: <[email protected] > > >> <mailto:[email protected]>> > > >> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
