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....@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@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.montele...@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....@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