After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 340991 - Default price source for reports not good
Default price source for reports not good
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: Reports
unspecified
Other All
: Normal enhancement
: ---
Assigned To: Chris Lyttle
Chris Lyttle
: 105331 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-05-08 09:18 UTC by Wouter van Marle
Modified: 2018-06-29 21:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Wouter van Marle 2006-05-08 09:18:20 UTC
Currently, the default for the "price source" (set via the Options) for all the
reports (such as "account summary" and "profit and loss") is set to "weighted
average". However, for most if not all reports it makes much more sense to set
this option to either "nearest in time" or "most recent".
Personally I ran into this, getting strange values for some currency exchange
rates and stock prices, causing me to enquire on the mailing list - this support
would have been unnecessary if the default had been set differently. I think
that people who need to use a "weighted average" and thus know more about this
kind of issues than me, will start searching for such an option. For the rest of
us I think the "most recent" is the most suitable and most sensible setting.

Other information:
Comment 1 Christian Stimming 2006-05-08 13:16:07 UTC
The point of having "weighted average" as price source is that this will always give some non-zero prices for the currencies/commodities involved. On the other hand, "nearest in time" and "most recent" will give non-zero prices if and only if prices have been entered into the price database (price editor) by some means. You got "strange values" because of the unexpected price source, where you have prices in the price db. If we set the default the other way round, then those people who do not have prices in the price db will not see "strange" values but they will see all-zeros. Not so good either. 

Therefore simply choosing a different default doesn't solve anything here. If you have a different proposal on how to deal with this for both cases (with/without prices in price-db), then we're glad to hear about it.
Comment 2 Wouter van Marle 2006-05-08 14:58:42 UTC
The values I got were simply plain wrong and out of any reasonble range, so that's why I got confused.
I just tried it out for myself - removing a certain exchange rate from the database indeed gives interesting results.

From the top of my head, I'd suggest to change the default to "latest in time" or "nearest in time" (I think it'll depend on the report which one is more sensible); with the software falling back to "weighted average" for prices that miss from the price editor database.
The user should of course be warned of this, by setting for example a line like "warning: estimated exchange rate due to insufficient price information" after the exchange rate in the report.

Another good addition I think would be for the zero-prices to add a note like "no price information available in the price editor" for a currency (or stock) that doesn't have a price set. With if possible a (hyper)link to the relevant section of the manual.
Comment 3 Christian Stimming 2006-05-09 08:49:44 UTC
The ideas are fine. However, currently there is no infrastructure existing in the report system that would support the "falling back to weighted average for prices that miss from the price editor database" behaviour. If the report system starts to calculate the numbers for the reports, it expects to have only numbers returned, but no extra error or warning messages. This would require some substantial changes in the reporting code, but currently no developer is working on that area of gnucash. 

What we would need is something like this: Before calculating the actual numbers for the reports, we would need to run an extra function that checks whether the exchange rates for all involved currencies are available. If that one fails or returns some error codes, we should show the appropriate errors or warnings. Then the actual number calculation for the report should continue. But currently we don't have these functions in the code.
Comment 4 Christian Stimming 2006-05-23 11:06:47 UTC
*** Bug 105331 has been marked as a duplicate of this bug. ***
Comment 5 Wm 2016-03-26 22:55:00 UTC
triage: I think if we were looking at this today we would probably put it under
  Currency and Commodity
rather than
  Reports

The price db has certainly moved on since 2006 so I suggest this is probably no longer relevant.
Comment 6 John Ralls 2018-06-29 21:03:38 UTC
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=340991. Please continue processing the bug there and please update any external references or bookmarks.