multiple display of the same transaction

[Stuart McGraw]

On 04/04/2012 09:38 AM, David Carlson wrote:
> On 4/3/2012 11:43 PM, Stuart McGraw wrote:
>> [snip]
>> To clarify, "one line" in this context means an entry
>> (what I view as a transaction) in the a register tab, not
>> a split line shown as part of a transaction viewed in
>> Auto-split or transaction journal view.
>>
>> Since I argue that it is more useful (and very common)
>> to view registers as showing transactions, I would expect
>> "Delete" to delete the transaction it is executed in.
>>
>> I think if there's a bug[*1], it is the showing of a 
>> transaction multiple times when it contains multiple 
>> splits for the same account.
> That only happens in 'child' accounts.
>>> 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.
>> Not sure why the delete confirmation choice would affect 
>> anything.
>>
> If a user is in a 'child' account rather than a 'parent' account, he
> might accidentally be trying to delete a single split from a multiple
> split transaction.

By "parent" account you mean the account in a transaction 
with more than two splits that has just one split on the 
debit or credit side, and the "child" accounts the ones 
that have multiple splits on the "other" (credit or debit) 
side?

(I think of parent-child accounts more in the context of 
of things like Liabilities:CreditCards and Liabilities:-
CreditCard:Citibank.)

But to address your point, the Delete button AFAICT always
deletes the entire transaction unless you have explicitly
selected a split in a view that shows all splits.  But you 
are saying that a user, aware that registers in Basic Ledger 
view actually display splits rather than transactions as 
pointed out in this thread, might accidentally be mislead 
into deleting an entire transaction when they thought they 
were going to delete a split?  Isn't that an another argument 
*for* what I suggest: compressing multiple splits that look 
like transactions into a single entry?  Then there would be 
no such confusion.

>[...]
> For the stock or commodity transactions, the split lines are there to
> separate actions rather than stocks or commodities, the basis of the
> account. This is a different can of worms that only investors would be
> interested in.

With banks (at least around here) paying minuscule interest 
rates (through my own inattention I recently had a 2-year
CD renewed at 0.00% and a $10/year maintenance fee) many 
more of us are investors these days.

> Your third example is an aggregated deposit slip transaction. Wouldn't
> such a transaction normally be viewed from the 'parent' bank account
> rather than the 'child' Receipts account?
> 
> My example, the paycheck, would normally be viewed from the 'parent'
> bank account rather than the 'child' taxes account(s).  Oops, in my case
> there are deposits to more than one bank account as well as 401(k).

[I rearranged your text slightly to make my response
more coherent.]

> So my question to you is: When would a user be viewing a transaction
> from the 'child' side?

I find myself going back and forth between accounts 
quite frequently (the Jump button is probably my third
most frequently used button after Enter and Cancel).

And what you call parent and child accounts change 
depending on what one is doing.  Going back to my
example again, the "parent" account may be the Bank
account when I am researching deposits but when I am 
entering checks received, the Receipts account is the 
"parent" account.  It is also the parent account when 
I am making the deposit because I want to see the checks 
received in order to create the deposit transaction.  So 
yes, I frequently see these duplicate views of the same 
transaction, and they reduce the usefulness of the Basic 
Ledger view.

> The multiple lines per transaction issue only arises when viewing a
> transaction from a 'child' account, which is not the usual 'parent'
> account that most of us would use.
> 
> This may be why no-one else has been bothered by that 'artifact'.

Are you sure "no one else" has been bothered?  See my 
response to Derek.