Re: Auto-Split Bug – Two transaction records shown when main account has two split entries

[Art]

Thank you, John.I'll split them to reflect the fact that it's two transactions and I'm looking forward to other opinions on this.My rationale was to let the checking account see the accrued interest, but that's like a sub-split really makes it unnecessarily more complex.

      From: John Ralls <jralls at ceridwen.us>
 To: Art <pinaart at yahoo.com> 
Cc: "gnucash-user at gnucash.org" <gnucash-user at gnucash.org>
 Sent: Sunday, January 10, 2016 8:33 AM
 Subject: Re: Auto-Split Bug – Two transaction records shown when main account has two split entries
   

> On Jan 9, 2016, at 10:56 PM, Art <pinaart at yahoo.com> wrote:
> 
> Hi!
> 
> 
> I don't know if this might be a "feature" for some, but it's not for me.
> I don't know how attachments are handled by the list and I didn't want to just stick a reference to a ".rtf" file yet.
> I created 4 figures to illustrate the bug and described them thus, Auto-Split Bug – Two transaction records shown when main accounthas two split entries. 160109 ajp
> The 4 figures below show this.Figure 1: Transaction Journal – all splits shown properlyFigure 2: Auto-split ledger – each WV13BLE account record shown asa separate transactionFigure3: Auto-split ledger – When first record is selected, the balanceis correctFigure 4: Auto-split ledger – When second record is selected, thefirst record balance is incorrect
> This message is in in RTF, so I'll just paste them below, Figure 1: Transaction Journal – all splits shown properly
> 
> Figure2: Auto-split ledger – each WV13BLE account record shown as aseparate transaction
> 
> Figure3: Auto-split ledger – When first record is selected, the balanceis correct
> 
> Figure4: Auto-split ledger – When second record is selected, the firstrecord balance is incorrect
> I wanted to preserve the statement numbers so I added the splits to increase the loan from the accrued interest within the next month transaction where I paid two installments as shown by the loan statement.
> One bad thing about this is that I tend to go "auto-pilot" and when I see two transactions that seem like a duplicate, I've deleted the first "bogus" transaction only to realize that both "transactions" disappear. I know the trivial work-around is to only do one entry as the sum of the loan splits and maybe I should because that would be cleaner, though if I wanted to note the discrepancy with the loan statement, I'd have to stick a comment with it.  I didn't look at the source code to see if there might be some information on this implementation. The docs do say the transaction line is the summary of " the transaction’s effect on the current account" which supports this behavior, but it could also be reduced so that the "current account" isn't considered factored as two transactions.
> 
> I'm wondering if best accounting practices call for me actually factoring these out into a "missed" payment transaction and the "two" payment transaction?
> That's why I posted here rather than the developer list.  As a bug, it would be quite minor from a user nuisance standpoint, but it might be a non-trivial fix to the source code.
> BTW, this is with GnuCash 2.6.6  built from rev 132c9e3+ on 2015-08-12, running on ubuntu 15.10 (64-bit OS, 16 GB Ram, 2 TB SSHD, CPU Intel Core  i7-5820)
> Thanks,Art

It's a result of the design of the register, which collects splits rather than transactions. It's not trivial to change, but not impossible, either. It's not strictly speaking a bug because the code is doing exactly what's intended, but it might be a misfeature. Others can weigh in on that, but changing it certainly isn't going to be high on my priority list.

As for the structure of your transaction, I'd suggest separating the finance charge into a new transaction because it's not really part of the current payment but rather due to your failure to make the previous one. Others here may have something to say about that too.

Regards,
John Ralls