> On May 13, 2018, at 3: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.* >
All of which would be nullified if there’s a higher-precedence (F::Q or price-editor) price in the database. The price database is intended to provide a current market price for the Accounts page, the summary bar, and the balance sheet (for unrealized gain/loss), and a set of historical prices for the time-series charts. In general practice the preferred price is the closing price on any day in the past or the last trade for today if the market is open, and that’s why F::Q overwrites user:price and user:xfer-dialog. Of course getting that requires the user to run F::Q after the close each day and few do. I added the user and xfer-dialog price entries a few years ago so that there would be some price in the pricedb if the user doesn’t run F::Q. If you want book values for a report, use Average Cost as the report’s price source: That’s calculated from the splits using the amount and value--though it needs some work, see https://bugzilla.gnome.org/show_bug.cgi?id=775368 <https://bugzilla.gnome.org/show_bug.cgi?id=775368>. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
