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

David Carlson david.carlson.417 at gmail.com
Sun Jan 10 19:45:02 EST 2016


The multiple entries in the register view has been present 'forever'.  I
find it most irritating when in a security register viewing a sale
transaction.

I think that was one of the issues that the 'Register 2' development was
supposed to address.  I would prefer to first see the completion of the
infrastructure improvements that will enable completion of the 'register 2'
work.

David C

On Sun, Jan 10, 2016 at 2:43 PM, Art <pinaart at yahoo.com> wrote:

> 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
>
>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>


More information about the gnucash-user mailing list