multiple display of the same transaction

Stuart McGraw smcg4191 at frii.com
Wed Apr 4 20:11:34 EDT 2012


On 04/04/2012 08:29 AM, Derek Atkins wrote:
> Stuart McGraw <smcg4191 at frii.com> writes:
> 
> [snip]
>>   Assets:Receipts         $150.00 
>>   Assets:Receipts         $200.00
>>   Assets:Bank:Checking              $350
>>
>> In the Assets:Receipts register in Basic Ledger view, the 
>> transaction will be shown twice. 
> 
> Yes, in Basic Mode (and in AutoSplit Mode) it will.  This is by design.

OK.  That (as amplified the rest of this and your other messages) 
is basically what I wanted to know.  I accept that the current 
behavior is what is desired and will drop my request for a change 
to it.

My following comments are just for the record, not an attempt
to continue agitating for a change.  Apologies for the length.

>>>> I am just wondering if doing something like this would 
>>>> be a reasonable enhancement request (perhaps it already
>>>> is?), or if there is some architecture issue that makes 
>>>> this impractical.
>>> 
>>> Perhaps.  The issue is a misconception that the register is actually
>>> displaying transactions.  It is not.  The register is displaying splits.
>>> This is why you see multiple entries from a transaction with multiple
>>> splits into the same account.
>>
>> But is it really a misconception?  When I look an entry 
>> in a register in Basic Ledger view, I see the *transaction* 
>> date, number and description, and when I view it in 
>> Transaction View I see *all* of the transaction's splits, 
>> not just one.  The only split-specific info shown (in Basic 
>> Ledger view) seems to be the reconcile flag and the value.
> 
> Just because it's showing splits doesn't mean that it MUST be limited to
> only data in the "Split" object.  Yes, it shows the Date and
> Description, because frankly not showing that data would be stupid and
> pointless. 

Yes, I got all that, and indicated so by what I wrote 
further on.  My point was that if it walks like a duck
(transaction) and quacks like a duck (transaction)...

> Would it really make sense to only show an account and an
> amount?  (note, also, that the "account" shown is technically for the
> *other* split in a basic transaction, and not the Split attached to the
> "current" register.

But in Basic Ledger view, that pretty much *is* all that's 
shown -- at least that is unique to the split.  And when 
there are more than two splits. not even that much is shown, 
since the account name is replaced by "-- Split Transaction --".  
All the other information presented is for the transaction; 
the only split-specific info is the split amount (and R flag).  
This is one of the points I was making -- if this register 
entry is supposed to be displaying a split (rather than a 
particular view of a transaction) it doesn't do a very good 
job of it.

In other other words, if you are using Auto-split view you
get the full transaction information when you look at any of
multiple entries.  So there is no need for multiple entries
because they all show exactly the same information.

I use Basic Ledger view when I want to maximize the number
of transactions I can see at once.  So showing each of the
multiple splits of a transaction as separate entries, with 
most of the displayed information duplicating what has already 
been shown, and not enough information to actually describe 
the splits uniquely, serves neither the goal of showing the 
splits, or of providing a condensed view of the transactions.

> So yes, it's still a misconception.

Then it is a misconception shared by most Gnucash users I
think and one that is encouraged by Gnucash's own documentation.

>> Most tellingly, when I delete one of these split/transaction
>> things, the entire transaction goes away, not just one of 
>> its splits.
> 
> Sure, because you are deleting the transaction.  You can also tell it
> just to delete the split.

Are you referring to the Transactions -> Remove Transaction 
Splits menu item?  When I tried it, it deleted *all* the other
splits in the transaction.  (I guess this would be "the split"
in the two-split case when "the split" refers to what is shown 
in the Account column.)  Were there to be a single register
entry for the case when there are currently multiple ones,
it is true that one could no longer identify a single split 
to keep.  On the other hand, I don't see why keeping all
of the splits for the current register would be bad and 
might well be desirable (and consistent).

>> I can conceptualize what's happening: Gnucash retrieves 
>> all splits associated with the current register and for
>> each of those, gets and displays the associated transaction
>> with a few items that are unique to this split.
> 
> Yes, that's indeed what is happening.
> 
>> But regardless of what one calls what is displayed, I think 
>> it useful to ask if what is currently displayed is more or 
>> less useful than what I propose be displayed.  It seems to 
>> me that for most users, most of the time, showing a single 
>> transaction entry when for cases when multiple ones are now 
>> displayed, is more useful and less confusing.
> 
> Most users, most of the time, don't have transactions with multiple
> splits into the same account.  I can certainly tell you that in ten
> years of storing my data in GnuCash, I have very few transactions that
> are affected by this.

Perhaps my own experience can provide some light.

I've been using Gnucash for several years.  At first 
associating checks with deposits was not a problem; 
the Receipts register would have a $0 balance, then
a handful of checks, then a deposit for the current
balance bringing it back to $0 again.  It was obvious
what checks constituted the deposit.

But later for various reasons not all checks got deposited 
at the same time, and I could no longer rely on $0 balance
totals to delimit sets of receipts and a deposit.  So until
a few weeks ago I kept track by recording in the deposit 
transaction Notes field what checks were involved.  This 
worked ok when there were only a few checks but it is a 
problem to record the date, source and amount for twenty 
or thirty checks in a single Notes field.

It was only when I looked at Gnucash's recommendation for
recording a stock sale transaction (as part of figuring 
out how to handle spunoff stock) that I realized one could 
have more than one split referencing the same account.  I 
also realized that it was the perfect answer to my problem
of tracking the specific receipts that go into a deposit.
Except that it turned out to be less than perfect because 
of the duplicated transaction view problem.

So why haven't other run into this problem?
* They may have.  Most people don't complain -- they find
  another way to do what they want or find another tool or
  live with the problem.  (The latter is what I will now do.)
* Many users (like me) probably never thought of doing it
  or didn't feel the need (as I didn't until after several
  years of using Gnucash.)

I also note 'gnucash-user's post describing the same method
to itemize expenses.

One also needs to ask, if using multiple splits referencing 
the same transaction is not often done, is that because it 
is not useful, or is it because of the negative side-effects 
Gnucash imposes?

Lastly, even if only a small percent of users find this way 
of itemizing or aggregating useful, a small percent of a 
large number of users can still be a large number.

>> ----
>> [*1] The reason for the two Assets:Receipts splits rather
>> than one Asset:Receipts split for $350 is to identify exactly
>> which checks are being sent to the bank.  In my OP I gave
>> some other cases when one might want a transaction having 
>> multiple splits with the same account.
> 
> A long time ago there *was* a discussion about having yet another
> display mode that would be somewhere between Basic and Journal mode,
> where a truly basic (2-split) transaction would take one line, but a
> Split Transaction would be displayed as a journal.  This would be a real
> "one entry per transaction" display mode.

That would be useful but it doesn't provide (IMO) a substitute
for the change I proposed.  As I said above, when I use the 
Basic Ledger view, I am looking for a condensed representation
of the transactions.  The proposed forth view does not provide 
such a view (since all the multi-split transactions are shown 
expanded) so I remain left with the Basic Ledger view and its 
"problem".

> There may or may not be a BZ request for this feature.  Nobody has
> worked on implementing it.  Are you willing to work on it?

Willing?  Yes.  Competent?  Err...  last time I used C was
twenty years ago, have never done any GUI programming in C 
and am totally unfamiliar with the Gnome and other libraries
Gnucash is built on.  I am willing to invest some time but
not completely dedicate the next few years of my life.  :-)  
Any rough idea how long it has taken in the past for those 
in similar state of incompetence to get up to speed enough 
to tackle a job like this?

All the above notwithstanding, I accept that my view of this 
"problem" is not shared by the development community.  That's 
fine, I can live with things the way they are (although I 
remain convinced that Gnucash would be better if something
like the change I proposed were adopted).

Thanks for your patience in responding -- I learned a number 
of new things about Gnucash as a result.  And of course, 
thanks for all the real work you and the other developers
and contributors to Gnucash have done (as opposed to my 
easy-to-spout-off posts) to create a very good piece of 
software.


More information about the gnucash-user mailing list