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