Default split order in release 2.5.3

[David Carlson]

On Sunday, 7/21/2013 10:03 AM, Christian Stimming wrote:
> Am Donnerstag, 18. Juli 2013, 07:21:19 schrieb David Carlson:
>> I have noticed that the order of the split lines in a split transaction
>> does not default to the same order as it does in in the old register
>> style of previous releases.  This is most noticeable in paycheck
>> transaction entries, but if I track purchase details at certain stores,
>> it appears there too.  While I did not like the old behavior, I had
>> managed to find a way to get the order to be consistently the same in
>> similar transactions.  Sometimes I even entered line numbers in the
>> Action fields so that I could detect when the order changed.
>> 1.  Will I need to resort to doing that regularly to get otherwise
>> seemingly random entries to a consistent order?
>> 2.  What if I am entering a stock transaction where I need the Action to
>> be an Action, then how would I force a certain order that is not based
>> on a simple sort?
>> 3.  What is the default split line order in release 2.5.3?
>> 4.  How can I force it to match the old behavior?
> I think the current split order in 2.5.x in the new register style 
> ("register2") is still a point for discussion. IMHO it should be changed to 
> match the old behaviour exactly, and only in subsequent steps there should be 
> options or similar to switch to different sort orders. If the current new 
> register2 split sort order doesn't match the old one, can you file a bug with 
> a simple example file and an exact description on how it is different? I think 
> you already did so, but can't remember it here.
>
> Regards,
>
> Christian
>
I may have mentioned split sorts in passing while focusing on some other
issue, but I do not think I made it a topic for discussion prior to this
message. 
I was away from my computer for a couple of days, so now I must play
catch-up.  I will try to build a test file in the next few days that
illustrates most of the possible scenarios for this concern.  I think
that it may take a two (or three or more) level sort to match the old
behavior, and I do not recall seeing that implemented in any other
program with the possible exception of some very old versions of Excel
or some of it's former competitors. 

I mentioned paycheck transactions specifically because I have always
wanted the sort order on the screen to match as closely as possible to
whatever appears on the actual pay stub.

The transactions that I have the most trouble with are the
(consolidated) monthly bills from the communication companies where they
are often adding new fees somewhere in the middle of the six page bill. 
Those companies have achieved incredible new levels of complexity and
obfuscation.  I think they transferred encryption experts into their
billing departments.

One way to allow the user to force a sort to his personal preference
would be to add a split-line number field.  While that would be my
favorite solution, it may not look pretty on low resolution screens.

If the default sort is based on the original order that the lines were
entered, it gets difficult for the user to fix 'errors' in sequence.  ;(

Regards,

David c
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xDC7C8BF3.asc
Type: application/pgp-keys
Size: 1729 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20130723/c3c91708/attachment.bin>