Quickfill gripe -- again!

[David Carlson]

On 12/21/2011 12:02 AM, David T. wrote:
> 
> 
> 
> 
> ________________________________
>  From: John Ralls <jralls at ceridwen.us>
> To: David T. <sunfish62 at yahoo.com> 
> Cc: Paul Abrahams <abrahams at acm.org>; "gnucash-user at gnucash.org" <gnucash-user at gnucash.org>; Fred Bone <Fred.Bone at dial.pipex.com> 
> Sent: Tuesday, December 20, 2011 8:24 PM
> Subject: Re: Quickfill gripe -- again!
>  
> 
> On Dec 20, 2011, at 6:05 PM, David T. wrote:
> 
>>
>> I'll note for the record that in Gnucash, every transaction has at least one split, so I don't quite understand your third case. As for your squishy middle case, how exactly do you propose implementing this? As I noted, this has come up in earlier threads, without anyone arriving at a solution that meets people's various needs--never mind anyone actually offering code to implement that ethereal solution.
> 
> No, a transaction has at least *two* splits. That's where "double entry" comes from, after all. A transaction marked "--split transaction--" in the account field of basic or double-line view has at least three splits., only one of which is for the current account. A transaction with more than one split in the current account will display once in the register *for each split* unless splits are displayed. (I see this often in my stock accounts because I prefer to do my own cap gains calculations and add the cap gain splits to the sell transaction to using lots and having a separate cap gains transaction.)
> 
> Yeah. Sorry. That *is* what I meant; there's a terminology problem here. When I think of the word "split", to me it implies taking one thing and ending up with more than one thing. Common spoken usage follows this: we have "split ends" (hair with more than one end) "split infinitives" (the act of taking the infinitive form of a verb and separating it with other words), we "split wood" (or atoms) (one item ends up in pieces). Therefore, in my mind, a "split" implies more than one thing--not an actual unitary entity. Looking at Wordnet's entry for the noun form of "split" shows plenty of examples similar to the Gnucash usage (e.g. "a promised or claimed share of loot or money"); I should have been more careful with my wording.
> 
> David
> _______________________________________________
> 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.
> 

Suppose that the transaction entry window were redesigned so that it
looked noticeably different than an entry in the transaction register,
even if the transaction journal view is selected.
It should be designed to clarify the differences from the register view
caused by the need for the 'extra' account to complete double entry
information, which defaults, of course, to the current account.

The window could have the "home" account (The current active account)
separated from the sub-account transaction area that has a reference
number, action, memo, amount and destination account.  When a "Split" is
added, a new line appears without bumping into "home" account box.  This
eliminates a major problem when adding splits.
Space could be provided for existing or possible additional features
like reconcile date, links to images, etc. which may not need to be
shown in the register itself. It could be extendable to have additional
fields appear when creating stock transactions, loan transactions or
business transactions such as accounts payable or receivable.

The existing navigation shortcuts like tabbing and quick fill could be
used or not, and there could be boxes to "Accept" or "Discard" the
edits.  This should all be compatible with the database back end.

That would change the environment within which the quick fill feature
works sufficiently to allow a user preference in the register section to
choose how it works in their instance.  I think that could enjoy better
user acceptance than the current implementation.

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/20111221/d720dc70/attachment.bin>