multiple display of the same transaction

Tue Apr 3 20:34:19 EDT 2012

On 4/3/2012 7:15 PM, David Carlson wrote:
> On 4/3/2012 12:39 PM, Stuart McGraw wrote:
>> On 04/02/2012 07:32 AM, Derek Atkins wrote:
>>> Stuart McGraw <smcg4191 at frii.com> writes:
>>> [snip]
>>>> Would there be any way, when this case occurs, of 
>>>> displaying the transaction only once in the register?
>>>> One would want the displayed value of the consolidated
>>>> transaction to be the sum of the split values, so I 
>>>> guess so you can't just pick one of the multiple views 
>>>> to display and hide the rest. 
>>>
>>> Yes, set your view mode to Journal mode and it will collapse all splits
>>> into their respective transactions.
>>
>> I know. :-)  I am taking about the multiple entries 
>> that are shown in Basic Ledger (Journal?) view when 
>> there is a transaction has more than one split in the 
>> register's account, NOT the split's shown for a transaction
>> in Auto-split or Transaction Journal views).
>>
>> >From what you write below, I realize you understand the 
>> situation I am talking about but as a specific example, 
>> I'll repeat the same example [*1] I just used in my 
>> response to David Carlson:
>>
>>   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. 
>>
>>>> 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.
>>
>> Most tellingly, when I delete one of these split/transaction
>> things, the entire transaction goes away, not just one of 
>> its splits.
>>
>> 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.
>>
>> 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.
>>
>> ----
>> [*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.
>> _______________________________________________
>> 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.
>>
> 
> 
> Stuart,
> 
> My initial response to your first email actually went out twelve minutes
> late by my local time.  It was supposed to be on April 1, and the part
> about voting for one of my suggestions on that web page was supposed to
> be with tongue at least partly in cheek.  The mental link that I made to
> your request was that if the entire transaction was viewed in a separate
> window it would more closely resemble what is now shown in the journal
> view, and would necessarily be complete in the sense of including every
> split line.
> 
> As Derek pointed out, by design, the basic view is showing split lines
> individually rather than complete transactions.
> 
> For me, I have no problem accepting multiple split lines being shown in
> some cases because, as you point out, each split line in your example
> should have a different description.  I want a way to see those split
> related descriptions, and the present display method does show them.
> 
> The two most common examples of transactions that can have many split
> lines would be a paycheck transaction with the deductions split to
> separate accounts and an aggregated deposit transaction split to match a
> paper deposit slip.  In both those cases, individual line descriptions
> matter in the 'child' accounts, where they may appear more than once in
> the same transaction.
> 
> If it is actually possible to delete an entire transaction by
> highlighting one line in the basic view as you allege, I would consider
> that a reportable bug.  Before reporting it, though, be sure that you
> have not accidentally turned off the delete warning confirmation.  Go to
> Actions:Reset Warnings to check whether that is the case.
> 
> David Carlson
> 
> 
> 
> _______________________________________________
> 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.

Two things I forgot to mention:

1.  If you want to use the basic view as your default, but use the
journal view in certain accounts, simply leave those accounts open when
you close the file.  I do that all the time.

2.  In English GnuCash uses the word 'Notes" to refer to the second line
at the the top of the transaction and the word "Memo" for the individual
split lines.  You can see this in the titles as you tab around the
fields in the transaction.  As far as I know, the program is fully
consistent with using those terms in report options, etc.  Of course
other languages will vary.

David Carlson
David Carlson
-------------- 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-user/attachments/20120403/6dd32e0f/attachment.bin>