Thanks John... For some reason Gmail had classified all direct emails as spam so I've effectively missed a lot of similar official replies 😓
On Mon, 14 May 2018, 11:01 John Ralls <jra...@ceridwen.us> wrote: > 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