A/P Register Question

[Geert Janssens]

On Saturday 23 January 2016 10:58:16 Joseph Pellegrino wrote:
> > On Jan 21, 2016, at 10:27 AM, Derek Atkins <warlord at MIT.EDU> wrote:
> > 
> > Hi Joseph,
> > 
> > Joseph Pellegrino <jdpellegrino at comcast.net> writes:
> >> Thanks Derek,
> >> 
> >> Is it possible to go from this:
> >> 
> >> T	Ref		 Payment
> >> P	Payment	   1
> >> P	Payment	   5
> >> P	Payment	 10
> >> 
> >> To this:
> >> 
> >> T	Ref		 Payment
> >> P	Payment	   16
> > 
> > Sure.  Pay only a single invoice!
> 
> Ha! That’s not quite what I had in mind. Paying them individually
> would result in the same cluttered look I am trying to avoid.
> > If you are paying multiple invoices at the same time then you need
> > individual splits in your A/P account, one split for each invoice
> > you're paying.
> 
> I get that I am just trying to understand why the splits can’t be
> hidden under the total value of the transaction. If I make a deposit,
> for example, the entry in the register is the value of the total
> deposit and if the deposit consisted of more than one individual
> element, say two checks, I’d have to click on the ‘split’ button to
> reveal that. That’s what I am looking for in the A/P.  So like
> described above:
> 
> T	Ref			Payment
> P	Payment	   	16
> 
> click on ‘split’
> 
> T	Ref		 Payment
> P	Payment	   1
> P	Payment	   5
> P	Payment	 10
> 
That's mostly due to design decisions taken years ago. Registers are not showing transactions, 
they are showing splits. So if you have transactions that happen to have multiple splits in the 
same account, they are listed individually.

I can see your point of a cleaner view when splits would be accumulated. This means a lot of 
changes simply because of the design concept of displaying individual splits being so deeply 
integrated.

There was another thread on this list (or gnucash-devel) with a request to change this. I'm not 
against that and I know John Ralls wasn't opposed either. However both of us also indicated 
that this change is very low on our priority list.

Regards,

Geert