Colin,
I agree, most people are coming from a place of hearing those terms from the
institution’s perspective, which confuses many at first.
And I also agree that the GnuCash defaults of informal labels and Basic View
are much simpler to comprehend.
However, once someone encounters a situation where they don’t understand
’transfer’ account or the nature of double-entry, problems arise.
They arise because by default, GnuCash is hiding the double-entry nature of the
system from them. (something of a contra-selling point when comparing GC to
proprietary systems that do the same thing, very strange it is the GC default)
So, perhaps I am mistaken here, but my usual approach is to advise people to
delve into double-entry to understand it. Because once you understand it, the
rest of GC and accounting make so much more sense. (personally, I find this a
much stronger selling point for GC)
As part of this, I offer the suggestion to turn on either Auto-Split or
Transaction Journal view so the user can see the entire transaction with
nothing hidden. The problem with this suggestion is now, in the case of a
credit card account, the user sees:
Date Description Account Payment Charge
----- ----- ----- ----- -----
4/1/19 Wal-Mart
Expenses:Clothes $100
Liabilities:Credit Card $100
Of course, this results in mind-mush and brain-explosions, because they didn’t
make a payment on their card for Expenses:Clothes, they charged it. To them,
this transaction hasn’t anything to do with payments on the card. (and try
explaining why every payment on their card account involves a ‘charge’ as well!)
This is either a shortcoming, or bug in the informal label implementation.
So, heading off this confusion, I suggest to also turn on formal accounting
labels so one always sees ‘debit/credit’ and then proceed to explain what these
mean.
While the learning curve might seem steeper at first, I think the end result is
better understanding and ability to use GnuCash.
If GnuCash auto-switched to formal labels when expanding a transaction to show
splits, that might suffice, but it might also introduce confusion since the
user would not be warned that column headers would change.
The use of ‘payment’ or ‘charge’ as a balancing column header where no payment
or charge is involved is non-sensical in this context. (same applies to other
informal label contexts)
Recent threads showcase this exact scenario — a user didn’t understand what
GnuCash was doing, (and perhaps to my lesser judgement) I recommended turning
on BOTH Transaction Journal View and Formal Accounting Labels. Unfortunately,
only the first was initially accomplished and many list exchanges and confusion
ensued. Once both changes were made, things improved. (with, it seems, still
room for better understanding)
Maybe I’m missing something from a long ago thread where this was discussed as
a design decision. And admittedly, the case doesn’t come up often enough to
warrant a change in the defaults.
But I do see room for improvement for comprehension, though I’m not sure what
form it should take, if simply to continue to be addressed on a case-by-case
basis when a user reaches that stage. Maybe this is something for the wiki?
Maybe there is a better way to explain what GnuCash is doing without resorting
to an explanation of double-entry, debits/credits, without seeing the whole
transaction, etc. I’m all for a simple path to the ‘right answer’ or at least
the ‘most correct answer for right now’ even if it isn’t the ‘most complete
answer’.
I guess I just don’t see how to explain what is going on, without explaining
what is going on. (I’m not talking about backend details of the code of course,
just the basic accounting principles being implemented)
Maybe “I” need to read the docs more often? Perhaps they are doing the job
already and a simple, but polite version of RT(f)M (even for myself) would
suffice?
Regards,
Adrien
> On Apr 16, 2019, at 11:32 AM, Colin Law <clan...@gmail.com> wrote:
>
> On Tue, 16 Apr 2019 at 01:14, John Clark via gnucash-user
> <gnucash-user@gnucash.org> wrote:
>>
>> Because these terms ‘never make sense’, as seen by this example. It is far
>> more simpler to just say, money coming in, on the left, money going out on
>> the right… or is the other way around...
>
> Money moves from right to left, that is one of the immutable laws of
> natrure (at least in the universe of Gnucash).
>
> It may have been mentioned before but in Settings > Accounts there is
> a checkbox, Use formal accounting labels. If you clear that then the
> headings on bank accounts say withdrawal and deposit, and on Credit
> card accounts say Charge and Payment, which I find much easier to cope
> with.
>
> The reason we have so much trouble with the words debit and credit is
> that we are used to seeing them on the bank statement and such like,
> so we have got used to them apparently meaning the opposite of what
> they really mean when looked at from our own point of view, rather
> than the bank's.
>
> Colin
>
_______________________________________________
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.
