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.montele...@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....@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....@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@gnucash.org > >>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel > >>> > >> > >> _______________________________________________ > >> gnucash-devel mailing list > >> gnucash-devel@gnucash.org > >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > > > _______________________________________________ > > gnucash-devel mailing list > > gnucash-devel@gnucash.org > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
