[GNC-dev] pricedb policy

Mon May 28 01:08:47 EDT 2018

Thanks John... For some reason Gmail had classified all direct emails as
spam so I've effectively missed a lot of similar official replies 😓

On Mon, 14 May 2018, 11:01 John Ralls <jralls at ceridwen.us> wrote:

> The hierarchy is user:price/user:xfer-dialog<-F::Q<-user:price-editor for
> the reason I explained.
>
> One more time: No, the user:price entries in the pricedb should ***NOT***
> be considered a lookup table to the actual prices in transactions. If you
> want the actual prices in transactions (actually splits, transactions don’t
> have any amounts or values) then *go look at the splits*. If for some
> reason you need to cache the prices then cache the prices. Don’t overload
> the pricedb for a purpose for which it’s not designed.
>
> Regards,
> John Ralls
>
>
> > On May 13, 2018, at 6:19 PM, Christopher Lam <christopher.lck at gmail.com>
> wrote:
> >
> > Thank you.
> >
> > Hence my RFC about whether "user:price" entries in pricedb should be
> > considered as a lookup-table to the actual prices achieved in
> transactions,
> > and should be subject to Check&Repair fixing. I'm sure the reports will
> > then fix themselves if they can rely on pricedb being accurate.
> >
> > IMHO if a transaction had documented an incorrect asset price, the
> > values/amounts should be amended. If I'd overvalued my house in
> > Equity:Opening Balances, I'd just go and amend the amounts.
> >
> > Perhaps I'll whip out a .scm to look at the prices and (optionally) offer
> > to fix any discrepancies.
> >
> > In future perhaps reports can offer use pricedb entries in a customizable
> > hierarchy - Finance::Quote prices, user:price, user:price-editor.
> >
> > On 14 May 2018 at 00:56, David T. via gnucash-devel <
> > gnucash-devel at gnucash.org> wrote:
> >
> >> The ONLY way to change the value in a transaction is to change it in the
> >> transaction itself—either by changing the number of shares, the actual
> >> price per share, or the total amount in the transaction (and note that
> the
> >> UI will ask you about this if you change one without changing the
> others).
> >> The price db doesn’t and shouldn’t push changes into existing real
> >> transactions.
> >>
> >> Changing the valuation in a transaction based on a price db change is
> the
> >> path to madness.
> >>
> >> The price db is for reporting on potential valuation. The transactions
> >> represent what actually happened. If I paid $100 for 10 shares of ABC
> >> stock, it doesn’t matter that the going price for ABC on the same day
> is $1
> >> per share—I’m still out $100 (and pretty gullible, too, I’d say).
> >>
> >> David T.
> >>
> >>
> >>> On May 13, 2018, at 7:20 PM, Adrien Monteleone <
> >> adrien.monteleone at lusfiber.net> wrote:
> >>>
> >>> Christopher,
> >>>
> >>> I’ll add a complication for you.
> >>>
> >>> Suppose one enters a transaction and later realizes the price source
> was
> >> not correct.
> >>>
> >>> Does editing the originally generated user:price affect the
> transactions
> >> in the register? Are they in-sync or now unrelated?
> >>>
> >>> If editing user:price does not change the register, does that mean you
> >> have to edit the register entries (or use correcting entries) and if so,
> >> does this alter the original user:price? (or add another?)
> >>>
> >>> If the two get out of sync, how do you determine what is the true
> source
> >> to use to regenerate upon loading and Check&Repair?
> >>>
> >>> Regards,
> >>> Adrien
> >>>
> >>>> On May 13, 2018, at 5:34 AM, Christopher Lam <
> christopher.lck at gmail.com>
> >> wrote:
> >>>>
> >>>> Hi Devs
> >>>>
> >>>> I wish to enquire about policy on pricedb.
> >>>>
> >>>> As far as I can understand, pricedb receives entries from 3 different
> >>>> sources:
> >>>>
> >>>> 1. from entering transactions into the register, if the transaction
> >>>> involves a foreign currency conversion or stock. e.g. originating
> >> account
> >>>> is GBP, target currency is USD --> creates a pricedb entry GBP/USD.
> >> (can't
> >>>> determine which one is deemed to be the base currency). These pricedb
> >>>> entries are tagged "user:price" or "user:xfer-dialog".
> >>>>
> >>>> 2. from online sources eg alphavantage. This requires careful setup,
> and
> >>>> seems to create price entries for all foreign currencies /
> commodities,
> >>>> compared to the book currency (in my case AUD). These are tagged
> >>>> "Finance::Quote".
> >>>>
> >>>> 3. entries added by the user. These are tagged "user:price-editor".
> >>>>
> >>>> From my review of code so far, pricedb entries are rather important in
> >>>> reports... an incorrect pricedb entry will lead to incorrect foreign
> >>>> currency reporting, even if the transaction contains the exact
> transfer
> >>>> amount.
> >>>>
> >>>> My concerns relate to (1) above. I believe these transactional prices
> >> are
> >>>> always more accurate than online quotes, because they describe the
> exact
> >>>> prices achieved.
> >>>>
> >>>> But it's buggy, e.g. if there are 2 transactions involving GBP/USD on
> >> the
> >>>> same day, the second entered price will overwrite the first. (<-
> >> according
> >>>> to my last test)
> >>>>
> >>>> I'd think it would be important for accuracy that, upon book opening,
> >> and
> >>>> Check&Repair, the user:price data should be *overwritten* by the
> actual
> >>>> prices obtained from the transactions. Moreover if there are several
> >>>> transactions involving commodities, Check&Repair should **add**
> relevant
> >>>> amounts to ensure accurate pricing.
> >>>>
> >>>> e.g.
> >>>> 01/01/2018 Transfer 100 GBP to 150 USD (generates pricing 1.5 USD/GBP)
> >>>> 01/01/2018 Transfer 100 GBP to 152 USD (generates pricing 1.52
> USD/GBP)
> >>>>
> >>>> should generate a price for "200 GBP to 302 USD -> pricing 1.51
> USD/GBP)
> >>>>
> >>>> Unfortunately I don't do C so cannot help with coding, but would think
> >> that*
> >>>> the "user:price" prices should *always* be regenerated from the
> >> transaction
> >>>> amounts during Check & Repair and upon loading datafile.*
> >>>>
> >>>> Thoughts?
> >>>> _______________________________________________
> >>>> gnucash-devel mailing list
> >>>> gnucash-devel at gnucash.org
> >>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> gnucash-devel mailing list
> >>> gnucash-devel at gnucash.org
> >>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >>
> >> _______________________________________________
> >> gnucash-devel mailing list
> >> gnucash-devel at gnucash.org
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >>
> > _______________________________________________
> > gnucash-devel mailing list
> > gnucash-devel at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>