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 752035 - Transaction Report Filter By not Always Working
Transaction Report Filter By not Always Working
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Reports
2.6.7
Other Linux
: Normal normal
: ---
Assigned To: gnucash-reports-maint
gnucash-reports-maint
Depends on:
Blocks:
 
 
Reported: 2015-07-06 20:33 UTC by Sam
Modified: 2018-06-29 23:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Data files and screenshots showing reports (617.51 KB, application/gzip)
2015-07-06 20:33 UTC, Sam
Details
Contains uncompressed data file (625.17 KB, application/gzip)
2015-07-06 20:38 UTC, Sam
Details

Description Sam 2015-07-06 20:33:24 UTC
Created attachment 306958 [details]
Data files and screenshots showing reports

When using the Transaction Report the "Filter By" option does not always work. In the data files included, I created three transactions: Test1, Test2, Test3. The issue is with Test1. Test2 and Test3 behave as I would expect. I will describe them first. Test2 is an Etsy sale which includes sales tax (credit to the sales tax payable liability account). Test3 is an Etsy sale which does not include sales tax. See the three screenshots starting with "Etsy". "Etsy - Filter None.png" has Filter Type set to None and both transactions show up. "Etsy - Filter Include.png" has Filter Type set to include and only Test2 (the one dealing with sales tax) shows up. "Etsy - Filter Exclude.png" only shows Test3 (the transaction without sales tax). This is the behavior I expected. However, the three screen shots starting with "Direct" show the issue. The transaction Test1 is a direct sale which includes sales tax. "Direct - Filter None.png" shows the single transaction. However, "Direct - Filter Include.png" does not show Test1 transaction even though it has a credit to the sales tax account. Further, "Direct - Filter Exclude.png" does show Test1 when it should not - the transaction does include a credit to sales tax account.
Comment 1 Sam 2015-07-06 20:38:12 UTC
Created attachment 306959 [details]
Contains uncompressed data file

Realized first attachment had compressed data file
Comment 2 Geert Janssens 2015-07-28 15:36:38 UTC
Wow, that bug has been around since gnucash 1.9.3 (2.0). I'm surprised
nobody tripped over it earlier.

Good news is I managed to trace it down and a fix will appear in the next
version of gnucash (2.6.8).

For future reference I'll summarize the cause:
the transaction report uses the function xaccSplitGetCorrAccountFullName
which was however not behaving as intended.

The transaction report uses it to detect multi-split transactions.
The function however only attempted to find a single split of the opposite
sign as the sale split. For the Test1 transaction it does find exactly
one, which is then returned to the transaction report. This interprets
the succesful return as meaning the transaction only has 2 splits and
will only test if the account for the returned split is in the filter
list. Since the opposite signed split in this case is the split in the
Checkings Account, it it not found in the filter list, so the intended
filter action is wrongfully inverted.

Both the Test2 and Test3 transaction have more than one opposite signed
split, so the function returns "-- Split Transaction --". This causes
the transaction report to correctly test all the splits in the transaction
against the filter.

As the comments surrounding xaccSplitGetCorrAccountFullName and friends
suggest their *intended* behaviour is what the transaction report assumed
I have chosen to fix these filter functions. Everywhere they were used
this new behaviour results in the same or improved behaviour (ie the new
behaviour makes more sense in most cases, or is irrelevant in the others).

I have also added a test case to prevent future regressions in this part
of the code.

Lastly I have slightly simplified the filter code in the transaction
report which should make it slightly more efficient in case of a large
amount of splits.


Thank you for your report and for providing an example file. That helped
a lot in hunting down this bug !
Comment 3 John Ralls 2018-06-29 23:41:44 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=752035. Please update any external references or bookmarks.