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 < [email protected]> 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 < > [email protected]> 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 <[email protected]> > 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 > >> [email protected] > >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel > >> > > > > > > _______________________________________________ > > gnucash-devel mailing list > > [email protected] > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > _______________________________________________ > gnucash-devel mailing list > [email protected] > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
