I think the confusion is arising because the default view (well intentioned for simplicity for new users) is hiding the double-entry nature of the actual data and this necessitated special terms and definitions for ’simple transaction’ and ‘compound transaction’ and then someone decided to use the term ’split transaction’ instead for one of those and then for clarification, exacerbated the confusion with ‘multi-split transaction’ as a substitute for ‘compound transaction’.
If we just abandon the use of ’split transaction’ (since they are all split at least once) and ‘multi-split transaction’ (since we have the defined ‘compound transaction’ to use) things might clear up a bit. Of course, the documentation is fine, this is just a communication and comprehension failing in a list conversation. On another note, while I have long known that mnemonics and abbreviations were used by programmers to save time (and storage space), I never considered how the time saved typing an extra letter, or few, more than made up for the small amount of time spent learning the command name and mapping it in my brain to the natural language term for what I’m trying to accomplish, especially considering I use some of those cryptic (to others) commands multiple times on a daily basis. Thanks for that tid-bit. Regards, Adrien > On Mar 24, 2019, at 11:42 AM, Michael or Penny Novack > <stepbystepf...@comcast.net> wrote: > > On 3/23/2019 6:04 PM, aeg via gnucash-user wrote: >> Thank you to those who have tried to educate me on the use of the word >> "split" in GnuCash, but whilst I believe that I understand how it is being >> used, the reason for using such an ambiguous term remains puzzling when >> better alternatives exist. > Is the objection then just to the term "split" being used when going from the > simplified method of entry (usable for the vast majority of transactions > where only two accounts are involved) to the more general "journal view" form > of entry that can be used for any transaction? > > You are right in the sense that nothing is being "split". The developers > could have used something more descriptive like "enter in journal view". > > Do you understand that gnucash would allow you to enter even simple (just two > accounts affected) transactions in this more complicated way? Instead of > entering the second account in the space provided hit the "split" button (the > "change to journal view" button) and enter the second account on its own > line. In other words, the "simple" (unsplit) method of entry is simply a work > flow shortcut making entering the vast majority of transactions much > faster/easier. > > To those of us who learned bookkeeping in the "old days", first entering > transactions in the journal, what is happening with "split" is obvious. We > are entering transactions the "old fashioned way" and with the hit of the > <enter> key at the end doing the "post". > > Those of us who know the computer language c and unix know that strange (hard > to read shortened spellings) were used by the engineers at Bell Labs who > preferred shorter (less key strokes) even if they had to be memorized. Thus > "mount" and "umount" (had to remember, no first "n"). I heard that this is > because none of them could touch type. But also how engineer minds work, in > the long run, less time spent learning that "umount" was spelled that way > than all the times afterwards hitting that extra "n". > > Just think of "enter in journal view" as being spelled "split". > > Michael D Novack _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
