[GNC-dev] pricedb policy

[Christopher Lam]

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
>