GNOME Bugzilla – Bug 796537
Transaction Report cannot sort by "num"
Last modified: 2018-06-30 00:11:33 UTC
Transaction Report is not able to sort by "num" , even sort by primary or secondary key.
I'm unable to replicate this. Please tell us step-by-step what you did and attach a supporting screenshot showing that you've set the sort key and that the report isn't sorted.
@Alex: for screenshot please enable 'General / Add options summary' to 'Always' Also please report setting for File > Properties > Accounts > Use split action field for number
Created attachment 372609 [details] Accounts page
Created attachment 372610 [details] Display page
Created attachment 372611 [details] Filter page
Created attachment 372612 [details] General page
Created attachment 372613 [details] Sorting
Created attachment 372614 [details] Split action for num setting
Created attachment 372615 [details] Results page 1
Created attachment 372616 [details] Results page 2
Created attachment 372617 [details] Results page 2
I suspect the File > Properties > Use split action field for number should be unticked. I think this setting was created to mimic Quicken behaviour. Try untick and refresh.
Hi All Step 1 : Reports --> Transaction Report Step 2 : Select account in the account page Step 3 : In the Sorting page, select primary key = number Results : There is some blank gap in the number field cannot be sort and seem appear in random order. (See the attachment Results page 1 & 2) Use split action field for number is ticked.
try untick split-action-field-for-number
(In reply to Chris from comment #14) > try untick split-action-field-for-number Just try to untick split-action-field-for-number, the "num" field cannot shown in the report at all ...
It'll be in Display page, should be 'Num' otherwise please resend screenshot when 'split-action-field' is unticked
(In reply to Chris from comment #16) > It'll be in Display page, should be 'Num' otherwise please resend screenshot > when 'split-action-field' is unticked See the capture "Num is missing".jpg after untick
Created attachment 372618 [details] Num is missing
I think all these numbers that you wish to sort by were stored in the *split/action* field (which is meant for "ATM" "Refund" etc) rather than *transaction/number* (which was meant to show check numbers) field. Where/how did this data get entered, manually? If so then may be best to keep using 'split-action-for-num-field', because to correct it manually will be rather difficult. I really think the split-action setting was designed to shoehorn quicken users into gnucash and causes confusion as above, and it's rather unfortunate that users who enable it get into difficulties as above. I don't think there's an easy solution. Least painful solution is to not use Number field and use Date field for sorting. Copy each "Split/Action" data onto "Transaction/Number" data and untick split-action-for-num-field. More painful solution is to amend transaction.scm to achieve the desired sorting, which will involve hacking scheme and will be overwritten when upgrading Gnucash.
(In reply to Chris from comment #19) > I think all these numbers that you wish to sort by were stored in the > *split/action* field (which is meant for "ATM" "Refund" etc) rather than > *transaction/number* (which was meant to show check numbers) field. > > Where/how did this data get entered, manually? If so then may be best to > keep using 'split-action-for-num-field', because to correct it manually will > be rather difficult. > > I really think the split-action setting was designed to shoehorn quicken > users into gnucash and causes confusion as above, and it's rather > unfortunate that users who enable it get into difficulties as above. > > I don't think there's an easy solution. > > Least painful solution is to not use Number field and use Date field for > sorting. Copy each "Split/Action" data onto "Transaction/Number" data and > untick split-action-for-num-field. > > More painful solution is to amend transaction.scm to achieve the desired > sorting, which will involve hacking scheme and will be overwritten when > upgrading Gnucash. However, the sorting is work at 2.6.x version ...
(In reply to Alex Mak from comment #20) > (In reply to Chris from comment #19) > > I think all these numbers that you wish to sort by were stored in the > > *split/action* field (which is meant for "ATM" "Refund" etc) rather than > > *transaction/number* (which was meant to show check numbers) field. > > > > Where/how did this data get entered, manually? If so then may be best to > > keep using 'split-action-for-num-field', because to correct it manually will > > be rather difficult. > > > > I really think the split-action setting was designed to shoehorn quicken > > users into gnucash and causes confusion as above, and it's rather > > unfortunate that users who enable it get into difficulties as above. > > > > I don't think there's an easy solution. > > > > Least painful solution is to not use Number field and use Date field for > > sorting. Copy each "Split/Action" data onto "Transaction/Number" data and > > untick split-action-for-num-field. > > > > More painful solution is to amend transaction.scm to achieve the desired > > sorting, which will involve hacking scheme and will be overwritten when > > upgrading Gnucash. > > However, the sorting is work at 2.6.x version ... Actually, I put the actual transaction date from bank statement into the "Num" for reconcile purpose, the sorted records will just matched with the bank statement order. The official reconcile tool is not user friendly for me and usable for me ...
I think in this case, split/action fields were being populated with your transaction-date, and any missing split/action cannot be sorted properly. I don't really think there's an easy solution at all; the split-action-for-num-field being ticked will have created a database that's difficult to shoehorn into the current transaction.scm. Most users (and accountants) will advocate ignoring the bank statement date and order, and just ensure all expected transactions are present (in any order).
>> More painful solution is to amend transaction.scm to achieve the desired >> sorting, which will involve hacking scheme and will be overwritten when >> upgrading Gnucash. > However, the sorting is work at 2.6.x version ... Which is odd, because although transaction.scm was upgraded, the sorting key for "number" was intentionally kept intact, unless a bug was introduced.
Hi All I think I found the reason why it is not working. In the sorting page, Seem there is a option "Primary subtotal for data key" . it is grey color and cannot be changed if the primary key is number. It is equal to "Monthly". So all the blank of the num field is appeared at the beginning of each Month. However, I cannot disable the primary subtotal ... It is grey color as well ... Seem it will do a monthly subtotal for all case ...
Hi Alex this indeed indicates a subtle bug. It's 'primary subtotal for date key' which aims to provide monthly/weekly/etc subtotals for Posting-Date (rather than Num). It would help to investigate this bug - please generate the 'monthly-empty-number' report via options, and enable General/Add options summary to 'always'. I really wish to know the options summary printed at the top of the report to try replicate, and amend transaction.scm to fix it.
(In reply to Chris from comment #25) > Hi Alex this indeed indicates a subtle bug. It's 'primary subtotal for date > key' which aims to provide monthly/weekly/etc subtotals for Posting-Date > (rather than Num). > > It would help to investigate this bug - please generate the > 'monthly-empty-number' report via options, and enable General/Add options > summary to 'always'. > > I really wish to know the options summary printed at the top of the report > to try replicate, and amend transaction.scm to fix it. What is "Monthly-empty-number" ?
I meant - generate the report which brings all the empty number fields to the top.
Created attachment 372644 [details] Option Summary
(In reply to Chris from comment #25) > Hi Alex this indeed indicates a subtle bug. It's 'primary subtotal for date > key' which aims to provide monthly/weekly/etc subtotals for Posting-Date > (rather than Num). > > It would help to investigate this bug - please generate the > 'monthly-empty-number' report via options, and enable General/Add options > summary to 'always'. > > I really wish to know the options summary printed at the top of the report > to try replicate, and amend transaction.scm to fix it. Option summary as attached.
............ I found the cause for this genuine bug. TECH ALERT: It's exactly as described. The split-action-for-num-field isn't actually being respected for the sortkey-list generation, and the original cause is the reason that jralls needed to add (gnc-current-session-exist) during sortkey-list definition. In 2.6.xx, the sortkey was being specified during the report rendering according to report options, therefore a current session did exist, and the split-action setting could be retrieved, and the right QofQuery was chosen. In 3.0 the sortkey-list was being defined at the top level, which means the session did not exist; yet we need to retrieve the split-action setting to define the sortkeys. Jralls's solution to query (gnc-current-session-exist) to prevent a dialog box was effective, but flawed: it meant the sortkey was always 'trans-num' rather than 'trans-num or split-action'. In scheme split-action cannot be modified so I couldn't test it. SOLUTION: We cannot rely on the sortkey-list being static anymore. It needs to be redefined per report instance. It must be changed to a function, taking split-action as a parameter to dynamically define the sortkeys. LAYMAN VERSION: Bug fix. split-action setting sorting should match 2.6 behaviour. Thank you for reporting this bug!
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=796537. Please continue processing the bug there and please update any external references or bookmarks.