GNOME Bugzilla – Bug 432235
Sorting in newly created SKR04 accounts is off
Last modified: 2018-06-29 21:33:33 UTC
Please describe the problem: I thought I had reported this earlier but cannot find it in the bugzilla database. I have not experienced this with other account schemes (Kontenrahmen) but creating acounts from SKR04 creates a weird ordering of the accounts. The problem is that some accounts are numbered. The numbering sequence is 1,2,3,...,7,8,9,10. It looks like gnucash then incorrectly assumes a non-numerical ordering of 1,10,11,...,2,20,21,... (see attached screenshot). Steps to reproduce: 1. LANG=de_DE LC_ALL=de_DE gnucash (you will not be presented with the SKR04 accounts otherwise) 2. create new accounts based on SKR04 only 3. the accounts are oddly sorted Actual results: Expected results: They should be in the intended order Does this happen every time? Yes. Other information:
Created attachment 86782 [details] Take a look at the red circle to witness the odd sorting
In case this matters, I am using gnucash on ubuntu edgy. Apparently, the package has been compiled from r14936 on April 10th 2007.
Sure, it's a non-numerical ordering; that is an alphanumeric field. I guess we could have a very sophisticated string-cmp function that sliced off any numeric sections from the front of strings, and compare those first... We need a simple patch here, someone to go through the SKR04 example accounts file and zero-pad the <10 account names. Care to supply that?
Space-padding might work too.
(In reply to comment #3) > We need a simple patch here, someone to go through the SKR04 example accounts > file and zero-pad the <10 account names. Care to supply that? I can try but I have never worked on gnucash source. I guess http://svn.gnucash.org/trac/browser/gnucash/trunk/accounts/de_DE/acctchrt_skr04.gnucash-xea is what I would need to look at? Let me see if I can come up with a patch.
I think the "patch" you are looking for is sed -i 's/\(act:name>\)\([0-9]\)/\10\2/' acctchrt_skr04.gnucash-xea\?format\=raw That should pad all "single digit accounts" with a zero.
sed -i 's/\(act:name>\)\([0-9]\.\)/\10\2/' acctchrt_skr04.gnucash-xea\?format\=raw seems more like it. But grep "<act:name>0" acctchrt_skr04.gnucash-xea\?format\=raw returns more entries than I expected. I am not sure if this indeed a problem or not.
Also I think the correct solution would be to have the possibility for a numerical sort on the "account code" field. Unfortunately I think the account code field is not set in the SKR04 template and/or that field isn't used often enough. I think if it is set, it is also possible to do a numerical sort on it, but I'm not sure.
in 1.8 space padding worked, but gtk2 tries to be smart and removesin the sort order all "meaningless" signs. May be there is an option to get the previous behavior?
(In reply to comment #9) > May be there is an option to get the previous behavior? No, as previous commenters noted, sorting as 1,10,11,...2,20,... makes sense. The right thing to do is rework the SKR04 file which is quite easy (see my one-liner above).
Created attachment 94707 [details] [review] Fix sorting for Frank's SKR04 OK, now here is my "patch" from comment 6 indeed in patch form. It seems you guys prefer this instead of applying the one-liner yourself ;-)
Created attachment 94747 [details] sorting by account number (In reply to comment #8) > Also I think the correct solution would be to have the possibility for a > numerical sort on the "account code" field. Unfortunately I think the account > code field is not set in the SKR04 template and/or that field isn't used often > enough. I think if it is set, it is also possible to do a numerical sort on > it, but I'm not sure. Not sure I understand you right. But the attached screenshot shows sorting by account number. But it is per group. It would be nice to be able to sort on the account number globally. Not sure what you meant by "Unfortunately I think the account code field is not set in the SKR04 template and/or that field isn't used often enough." It looks fine to me.
Created attachment 94748 [details] sorting by account number (In reply to comment #8) > Also I think the correct solution would be to have the possibility for a > numerical sort on the "account code" field. Unfortunately I think the account > code field is not set in the SKR04 template and/or that field isn't used often > enough. I think if it is set, it is also possible to do a numerical sort on > it, but I'm not sure. Not sure I understand you right. But the attached screenshot shows sorting by account number. But it is per group. It would be nice to be able to sort on the account number globally. Not sure what you meant by "Unfortunately I think the account code field is not set in the SKR04 template and/or that field isn't used often enough." It looks fine to me.
Sorry for the double post. The bugzilla server was having some hickups.
Is this issue still a problem with the updated SKR04? If no, please close it. In your last comment you asked for "sorting by account code globally, not per-group". This would be an enhancement request for a new feature. But in gnucash's current implementation the whole point of the grouping in hierarchies is that they indicate "This is a totally fixed group, it will never be sorted into something else." If you wanted to change that, one would have to change a *lot* of places in gnucash.
(In reply to comment #15) > Is this issue still a problem with the updated SKR04? yes, of course. You need to apply the bzipped patch from attachment 94707 [details] [review]. > In your last comment you asked for "sorting by account code globally, not > per-group". This would be an enhancement request for a new feature. But in > gnucash's current implementation the whole point of the grouping in hierarchies > is that they indicate "This is a totally fixed group, it will never be sorted > into something else." If you wanted to change that, one would have to change a > *lot* of places in gnucash. OK, any other way to do this? Is it possible to search for an account number?
fixed in r16489
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=432235. Please update any external references or bookmarks.