GNOME Bugzilla – Bug 743753
Nearest in time security price selection is incorrect in reports
Last modified: 2018-06-29 23:38:10 UTC
I observed this in release 2.6.5 for Windows. If a report such as a balance report is selected and the report is configured to include some securities and the security price selection criterion is set to Nearest in time: If there are more than one price in the Price database for that security on that date, the report selects the first one found instead of the last one that is characterized as Last. I was unable to test whether source makes a difference, but my test report had three "Last" prices from the Finance:Quote source on the selected date, and it took the first (earliest in the day) instead of the last. That subverts the entire concept of last. There is a two year old bug <https://bugzilla.gnome.org/show_bug.cgi?id=676789> indicating that it is possible to have multiple "last" prices without showing the time, which makes them ambiguous. It does not ask for logic to identify correctness, just show the time. That sets up the condition that this bug does not handle correctly.
I am not sure, but I suspect that the definition of Nearest in Time was supposed to cover (among other things) the fairly common case where GnuCash reports are dated the last calendar day of the month but the prices in the database are dated on the last business day for stocks but the business day criterion is often ignored and the last calendar day is used instead. I would like to see this issue of some data being inconclusive and some GnuCash reports giving no value at all if the database price is for Friday but the date of the report or the date shown on some line within the report falls on Saturday or Sunday and Nearest in time criterion is not respected for some reason. If the date that the datum was received was checked and compared to the date reported in that datum, it would be possible to detect Friday data that was reported on Saturday or Sunday or Monday before the market opens and use it correctly in the report. One more thing. Does Nearest in Time cut off at midnight for the named date or would it choose a Monday price instead of a Friday price if the selected report date is on Sunday? I suppose holidays for the particular exchange reported would also sometimes come into play.
I have trouble imagining an accounting case where one would want prices from the future to be used in a report. More usually, say running a report at the end of each month, one would want the last price in the month, even if it happened two or three days before, rather than a price from next month. Gnucash does appear to pick the Monday price for a Sunday report when using nearest in time. It would seem better to replace the "nearest in time" option with "latest before" for which there is a pricedb function (gnc_pricedb_lookup_latest_before).
Not everyone retrieves prices daily. The net worth graphs calculate the value of a book on one day in each period (the period being selectable in the report options). If there's a price say 5 days before the iteration date and one 2 days after, the latter is likely to be a better estimate of the value on the iteration date than the former. That said, I agree that a "Latest Before" report price option would be a reasonable enhancement.
There are four months in 2015 where the last business day is not the same as the last calendar day. That means that some of us will need to go into the price editor and add bogus weekend prices for securities to get our month end reports to match the reports from our financial institutions. That means January, February, May and October reports may all need fudging. Let's get a "Last Business Day" option for reports.
(In reply to David Carlson from comment #4) > There are four months in 2015 where the last business day is not the same as > the last calendar day. That means that some of us will need to go into the > price editor and add bogus weekend prices for securities to get our month > end reports to match the reports from our financial institutions. That > means January, February, May and October reports may all need fudging. > Let's get a "Last Business Day" option for reports. Well, it could be argued that you're being a bit obsessive about unrealized gains. "Last Business Day" for a month would be locale-dependent and since I don't know of any localization files that include that information it would be difficult to implement. "Latest before" on the other hand solves the problem in most cases without the locale dependency.
After updating my view of this bug in Mozilla Firefox so that I could see John's comment 5 I attempted to reply, and my comment bounced. Here is the text of the comment including the bounce info: Conversation opened. 5 messages. All messages read. Skip to content Using Gmail with screen readers David 1 of 24,560 [Bug 743753] Nearest in time security price selection is incorrect in reports Inbox x GnuCash Jess changed bug 743753 What Removed Added CC jess@boulder.com Comment # 2 on... Jul 29 David Carlson Alright, I'm easy. Last weekday or last day anytime in the current millennium... 4:31 PM (1 minute ago) Mail Delivery Subsystem <mailer-daemon@googlemail.com> 4:31 PM (1 minute ago) to me Delivery to the following recipient failed permanently: bugzilla@gnome.org Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the server for the recipient domain gnome.org by smtp.gnome.org. [209.132.180.187]. The error that the other server returned was: 554 5.7.1 <bugzilla@gnome.org>: Recipient address rejected: Please use the web interface at http://bugzilla.gnome.org/ ----- Original message ----- DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4U+b5WB0gEE7FVbEj+eq4LSekYfKZNXOo4YwGpFuYaA=; b=Wjhc/7hWojloTNHqkwEwFsdnzrWyB/dUKIRXmxZw3hO5B+N3iuzEL7eEaQ8n3vsG1Q M+nezynKhjP7TduyeVP4+eNbMlbK8SZNSKmXeG7fxG2uFZ2JkImCeR+tP+dWMcE7pTOK QLbb2jn6j2QmFwW97fnHSDAiUoFa7uVBNVj3Fw8zR2qzTGHPhFlaBlobK/bwWyXFjIn7 LWtij9x6rnyXZsdpkLycdvsjR5Y/Pk02CFWIQGp3i+X14c4aCrqerpbiMAFqRlBO79/x UAW83JMHPc+jHlOm5S+eXCcecFMVEiX/GENGSIu1GYUuahRzIpDBM5PuiqdXxRZxSjvM aF+A== MIME-Version: 1.0 X-Received: by 10.180.11.175 with SMTP id r15mr22856474wib.74.1442957488746; Tue, 22 Sep 2015 14:31:28 -0700 (PDT) Received: by 10.27.10.228 with HTTP; Tue, 22 Sep 2015 14:31:28 -0700 (PDT) In-Reply-To: <bug-743753-282503-pw5LbI14rP@https.bugzilla.gnome.org/> References: <bug-743753-282503@https.bugzilla.gnome.org/> <bug-743753-282503-pw5LbI14rP@https.bugzilla.gnome.org/> Date: Tue, 22 Sep 2015 16:31:28 -0500 Message-ID: <CADYgSbmar_v-jDf4i-UAAZqWvKcOH0x8ZNbL7yaSnJ7sWW7kXQ@mail.gmail.com> Subject: Re: [Bug 743753] Nearest in time security price selection is incorrect in reports From: David Carlson <david.carlson.417@gmail.com> To: GnuCash <bugzilla@gnome.org> Content-Type: multipart/alternative; boundary=001a11c34d648af85b05205cb8b9 Alright, I'm easy. Last weekday or last day anytime in the current millennium before the report date. On Tue, Sep 22, 2015 at 1:39 PM, GnuCash <bugzilla@gnome.org> wrote: > *Comment # 5 <https://bugzilla.gnome.org/show_bug.cgi?id=743753#c5> on bug > 743753 <https://bugzilla.gnome.org/show_bug.cgi?id=743753> from John Ralls > <https://bugzilla.gnome.org/page.cgi?id=describeuser.html&login=jralls%40ceridwen.fremont.ca.us> > * > > (In reply to David Carlson from comment #4 <https://bugzilla.gnome.org/show_bug.cgi?id=743753#c4>)> There are four months in 2015 where the last business day is not the same as > > the last calendar day. That means that some of us will need to go into the > > price editor and add bogus weekend prices for securities to get our month > > end reports to match the reports from our financial institutions. That > > means January, February, May and October reports may all need fudging. > > Let's get a "Last Business Day" option for reports. > > Well, it could be argued that you're being a bit obsessive about unrealized > gains. > > "Last Business Day" for a month would be locale-dependent and since I don't > know of any localization files that include that information it would be > difficult to implement. "Latest before" on the other hand solves the problem in > most cases without the locale dependency. > > ------------------------------ > You are receiving this mail because: > > - You reported the bug. > > Click here to Reply or Forward 1.02 GB (6%) of 15 GB used Manage Terms - Privacy Last account activity: in 1 minute Details Related Google+ Page GNOME's profile photo GNOME
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=743753. Please continue processing the bug there and please update any external references or bookmarks.