GNOME Bugzilla – Bug 752035
Transaction Report Filter By not Always Working
Last modified: 2018-06-29 23:41:44 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.
Created attachment 306959 [details] Contains uncompressed data file Realized first attachment had compressed data file
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 !
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.