GUI - accounts vs. transactions

[Terry]

Sorry if this posting becomes rather long. I have been using gnucash for
several months now - since. 1.3.4, I believe, and the beginning of this posting
came to me last night as I was trying to get to sleep.

I believe that most of the problems I am having in using gnucash is because
gnucash is really rather schizophrenic, I don't mean that as derogatory to
either gnucash or to those who may have that disease. What I mean in very short
sentence is that gnucash does things behind the scenes in one manner and
presents a very different perspective to the user.

>From what I have learned so far from the very knowledgable people on this list,
Dave. Bill, Christopher and many others, is that, I believe, the basic element
to gnucash is an account. But the basic element that is presented to the user
on a daily basis is the transaction.  This is after the user has set things up
with all of the accounts, past that point the users deals almost exclusively in
"transactions". However, gnucash deals with "journal entries". Now an
experienced accountant would probably have no problem, since they would have
been dealing in paper journal entries for years and, using gnucash, would keep
their mental image of the process. gnucash then becomes a great help to them in
"automatically" filling in the "other end" of a transaction, i.e., the second
journal entry of a double entry book-keeping system.

As an aside, my father was an LPA and one of the few things I remember is that
the beauty of double entry book-keeping is that it didn't keep you fom entering
193.56 as 139.56, but usually one of the two entries was correct and so the
fact that there was an error was self-evident. In single entry, you might not 
know for a very long time that there even was an error. Of course with
computers this advantage is no longer present since you only enter one "journal
entry" and the computer propagates your entry error to the second "journal
entry". Bingo, you now have the same problem as the single entry system. Of
course, double entry does have other advantages, or so I have read.

Now back to the main topic. Whenever I use gnucash now, I deal in
"transactions", i.e., I open the register for an account, fill in the various
fields with the appropriate information, specify the account ffrom which the
money is to be drawn, or to which the money is to go. If I bother to open the
register for the other account, gnucash has "automatically" completed the
transaction in that account. Now an accountant (or somebody profficient in
accounting) would think of that as two journal entries. The non-accountant
user, such as myself (and I would be willing to bet most gnucash users are
non-accountants, even those wanting to use it for a business), would more than
likely think of the action just completed as a "transaction". Open the report
menu, one of the reports is a "transaction report", not a "journal entry
report".

However, how does gnucash treat the action just completed? From what I have
managed to learn, let me hazard a guess. All the information entered by the
user in the "register window" isn't a transaction, but rather a journal entry
in the account for which the register is opened. All of the information
"belongs to that account" and not to the "transaction". gnucash "copies" the
necessary information from that account to the second account which now "owns a
copy thereof". gnucash has "done the user a favor" and completed the second
entry of the double entry system by copying the information and moving the
credit amount to the debit field or vice versa as appropriate. But by "doing
the user a favor", gnucash has reinforced in the non-accountant users mind that
(s)he is dealing with transactions and they do not even think therefore in
journal entries.

If gnucash didn't "do the user a favor" and copy the information, but forced
the user to actually open the register for the second account and re-enter the
information, then it would reinforce the notion of journal entries instead of
transactions. This would, of course, also reintroduce the fact that gnucash
could then "catch" entry errors. Now this "foolish" notion of forcing the user
to actually do double entries is meant only half seriously. Half because I
don't think many users would accept doing it when they have an expensive
computer sitting in front of them to do just that. I certainly wouldn't.  But
then gnucash wouldn't have this schizophrenic behavior. It forces me to think
in terms of transactions, but it works in terms of journal entries. 

Let me give you two real examples of how this is really, really confusing.
First a simple example that could be fixed rather simply. It exhibits what I
call "lazy programming", at least when I am guilty of committing this behavior,
that's what I call it. I have two checking accounts, A and B. I write a check
withdrawing funds from A and deposit the check in B, transfering funds from A
to B. Of course, I open A's register and create a transaction with check number
'1346" say. I specify B as the "transfer To" account. Now in B everything gets
copied over including the check number as it should be. But account B now
"owns" the "copy" of the information. The next time I write a check against
account B, I simple-mindedly position the curser in the check number field and
press the '+' key to get the next check number. Now the last check I wrote
against B had a check number of '978". What number do you think gnucash fills
in for me automatically, that's right ,'1347'.  Now this is where I guess what
is happening. Two things occur one because gnucash views everything as journal
entries and the second bacause of "lazy programming". First gnucash reads
down the list of journal entries looking for check numbers and finds the
largest check number for any entry. Since all of the information is "owned by
account B", no thought is given to the fact that the check number came from
another account. Bingo, you get the wrong check number. Now this could be fixed
very simply without changing gnucash greatly, by having the check increment
algorithm, check that the journal entry for that check number actually withdrew
money from account B. Have you ever written a check against an account to
deposit money into that account? If so, then the algorithm will have to be even
smarter.  But this is a simple example of the inconsistent behavior of gnucash.
It forces the user to deal in transactions and itself works in journal entries.

Another example. I want to create a "transaction" transfering funds from
account C to account D. I open the register for account C and remember that I
had created a similar "transaction" 3 months ago. I scroll up, find the desired
transaction and "duplicate" it. See, gnucash is really great, I don't have to
go through all of that tedium again. Now, I'll just change the amount and edit
the "memo" field to reflect the purpose of this transaction and I'm home free.
Right? Well not exactly. Another couple of months go by and I'm reviewing the
entries in account D and I run into two entries which are identical except for
the dates and the amounts. Now I know that I didn't pay that bill twice, what
is going on here? I look at the entry for the first "transaction" and
everything looks okay. I use the "jump" feature of gnucash and look at the
entry in account C. Yep everything is fine there. I "jump" back to account D
and scroll down to the second identical entry and "jump" to that entry in
account C. Guess what? Everything looks fine there also except for one small
thing, it's not the same as the entry that I just looked at in account D. Whats
different? The memo field of course. What happened? When I duplicated the entry
in account C, gnucash copied the entry in account C and then copied the copied
information into a journal entry in account D. I then changed the amount in C
and gnucash, being the smart beastie it is, changed the corresponding amount in
D. I then edited the memo field in account C. Again gnucash being the smart
beastie that it is and working in journal entries did absolutely nothing with
the corrsponding journal entry memo field in D. Why not? you ask. Simple is
the explanation. I changed the information "owned by C", not the information
"owned by D". In order to change the memo field in D to agree with the memo
field in C, I have open D's register, find the appropriate journal entry and
change the information "owned by D". Has gnucash done me favor? Well if I'm an
accountant thinking in terms of journal entries, of course. Changing the second
journal entry is second nature. If I'm a non-accountant, NO. I have been going
along duplicating transactions, editing the duplicate and thinking that gnucash
changed the amounts and other fields accordingly for that transaction
whereever it appears, I am dealing in transactions as gnucash's User Interface
has amply reinforced in my mind. Now after several months I find that I have to
go back and painstakingly find all of those duplicated entries trace the "other
end" of the transactions, and change the entries accordingly. Not only that, but
I have to be sure to remember that gnucash doesn't do this for me in the future.

Now all of that is merely a matter of documenting gnucash's quirks or
documenting the philosophy of double entry so that user thinks in terms of
journal entries instead of transactions. Then removing all instances of the
word "transaction" from all gnucash documentation. Right?? Well, I .....don't
know. I wish it were that simple, but I have this sinking feeling that it
isn't. I run into this inconsistency all through gnucash. Well, to be fair not
just gnucash, but the accounting as described here and in gnucash's docs. For
example "splits". I thought I understood splits. I create a transaction/journal
entry for say 100 in Account A. I want to transfer that 100 into accounts B, C,
D and E so that the total transfered is 100, say 25 to B, 30 to C, 10 to D and
35 to E. I have seen that termed a split on this mailing list and I thought it
was termed a split in the gnucash docs, but I couldn't find it. After some
correspondence with Dave, however, I learn that a "split" is also a double
entry transaction, i.e., transfering money from A to B is a "split". I suspect
that both meanings are correct and used by those knowledgable enough to do so
with the proper meaning derived from context. However, to those not so
knowledgable it is inconsistent and confusing.

The bottom line, as long as the gnucash user interface "deals" in
"transactions", but works in journal entries, the inconsistency is going to
always be there. "You cannot serve two masters." This basic inconsistency is
going to lead non-accountants (those who do not think in terms of journal
entries), down the proverbial rosy garden path into the thorns.

I wish I could now detail the magic words that would eliminate this
inconsistency, but I cannot. I think the basic problem comes from wanting to
have the computer be the user's servant and not the user's master, i.e., taking
care automatically of the double entry details. But that leads the user to
think in terms of "transaction" instead of journal entries. As I wrote above,
forcing the user to do both journal entries in the double entry book-keeping
would, I think, force the user to think in terms of journal entries and not
transactions, but few of us would accept that.

Changing the user interface of the register window may be possible to
accomplish this, but I am at a complete loss as to how this would/could be
done. I can only hope that those on this list who are smarter than I am can
think of a way to do so. Also, I hope that what I have written above will
stimulate some thought/discussion along these lines to change gnucash so that
the inconsistencies can be eliminated. I know that the two examples I have
given above may seem trivial, but they become very annoying after encountering
them the second, third, fourth, five and more times. At first I thought some
trivial programming changes could eliminate them. Maybe so, but I think they
are only the tip of the iceberg, so to speak, and until this dichotomy in
gnucash is "fixed" others will appear, some simpler, some more serious. In
my experience, inconsistency ALWAYS leads to problems, usually serious problems.