[GNC-dev] pricedb policy

[David Carlson]

There are two use cases that will be more common.   One is the general
end-of-period valuation that is usually driven by publicly reported prices.
  The other would be a book value which could be a cost basis.  That might
be driven by transactions or average costs.

There needs to be a way for users to design their report for  either of
these or other cases as well.

David C

On Sun, May 13, 2018, 11:39 AM Adrien Monteleone <
adrien.monteleone at lusfiber.net> wrote:

> On the contrary, there is such a thing.
>
> Certainly, in near real-time, as you describe, no there isn’t.
>
> But when booking an existing asset at current market prices when starting
> a book, there is. There might be various reasons for this approach, not the
> least of which is that the original actual price paid in the home currency
> is no longer available. (and not relevant to any balancing with other
> accounts - this will balance with Equity:Opening Balances)
>
> And I was able to edit the ‘first’ user:price. So if it is supposed to be
> read-only, it’s not. (or at least wasn’t in 2.6.19)
>
> Regards,
> Adrien
>
> > On May 13, 2018, at 9:42 AM, Christopher Lam <christopher.lck at gmail.com>
> wrote:
> >
> > I'm sorry there's no complication.
> >
> > There's no such thing as "price source was not correct" while entering a
> transaction.
> >
> > Let's say I transfer 100 GBP to 150 USD, currently generating a pricedb
> entry of GBP/USD=1.5, later "realize" the price source was incorrect and
> should have been GBP/USD=1.6, it would mean that the USD expense or account
> would not have received $150USD in the first place, causing all sorts of
> USD imbalances or incomplete funds for purchase.
> >
> > My view is that "user:price"-type pricedb entries are usually directly
> generated from transactional transfers, therefore can be considered a
> lookup-table for existing transfers, and should not be user-editable.
> >
> >
> > On 13/05/18 22:20, Adrien Monteleone 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
>