GUI - accounts vs. transactions

[Terry]

On Wed, 04 Oct 2000, you wrote:

> 
>    A "journal entry" and a "split" are the same thing.  Internally in
>    gnucash, "split" is the name that's used.  A split is a credit or
>    debit to a *single* account.  In terms of paper accounting, a split
>    is ONE entry in a "double entry" transaction.  Each split has some
>    additional data associated with it, including a memo and a
>    "cleared" flag.
> 
>    A "transaction" is a collection of splits whose credits and debits
>    sum to zero.  For a transaction to be "balanced" (i.e. conformant
>    to double-entry accounting) it must have at least two splits, one
>    which is a credit and one a debit.  Transactions have other
>    information associated with them, including a "description", a
>    date, and a number.  Transactions do not have amounts (the splits
>    contain the amounts; the sum of the splits is always zero) or
>    "memos", although the transaction's Description is basically the
>    same as a memo.

Is this documented in gnucash's documentation. I admit to not having read the
documentation on-line since 1.3.4 (I think), but I did read all of it at that
time. I am probably one of the few who reads the manual first. If not then it
should be added by someone who understands it and can explain it clearly.

> 
> The fundamental unit of display in the register is the transaction.
> In any display mode, the transaction's date, description, and number

exactly - but the fundamental unit of gnucash is the account (At least I would
say it is from what I have read, experienced and had written to me). Everything
is an entry in an account. I am speaking from ignorance, but I would be willing
to bet that transactions, at least as displayed in the register, probably do
not exist in gnucash beyond the register display.


> are shown.  the key to understanding the register display is to note
> that the register generally shows a single account, and for each
> transaction, splits affecting that account ARE NOT SHOWN.  The only
> time you can directly see the split affecting "this account" is from a
> register for another account.  In double line mode ONLY, you can also
> see the Memo for the split affecting "this account".  Toggling between

Exactly, but when I "attach" a memo to a transaction, i.e., fill in the memo
field in the register display, I am describing this "transaction" and not this
journal entry. By using transactions in register windows as the primary, if not
only, means for the user to interact with gnucash, gnucash relagates journal
entries to oblivion for the user who then is trained to think in terms of
transactions and not journal entries and this then leads to problems because
gnucash works with journal entries.

> "multi-line" (which shows all splits except for the ones in "this"
> account) and "double line" mode can be disconcerting until you
> understand this.

Again, is any of this documented in the latest on-line documentation. I must
read it again!

> 
> I will let Dave address the rest of your issues since he knows much
> more about the register than I do.  However, let me say that I
> disagree with your overall premise that there's something
> fundamentally wrong or conflicted about the way gnucash works right

I don't think I said anything was wrong, I aplogize if I did. What I think I
was saying is that I get a very confused/confusing picture of what is happening
when I use gnucash. I don't think this is unique to me from questions I have
seen on this list. I also don't think it is possible to say that "educating the
user" is the solution. I don't think it is the solution any more than forcing
the user to do both entries of the "split" is the solution to catching entry
errors. Like most things with the computer, adapting the paper process does not
really work well on the computer. It does for the user who has used the paper
process for years, because they don't have to learn anything new. But the new
user who never used the paper process is just confused because a computer
screen is a really poor imitation of paper. Electronic books won't work well or
sell well until the people trying to sell them realize that. Why is it a poor
imitation? Well for one really obvious thing, you can view a single, full size
page at one time, no more. With paper I can arrange as many as will fit on my
desk top and scan them all rapidly and easily. I make appointments with many
secretaries in this area all the time. Each and every one has a computer
sitting besides their desk with s/w designed for them to arrange appointments.
Each and every secretary I have met despises the computer s/w and they all go
back to the old wire bound appointment books. Why? because the computer s/w for
the most part tries to imitate the wire bound appointment book, and forces the
secretary into a straight jacket in doing so. With the paper, the secretary can
flip between pages and arrange/change appointments in seconds as opposed to
waiting for the computer to change from 9-2-2000 to 10-3-2000 and then back
because she/he forgot what was on 9-2-2000 in the time it took to change the
date on the computer. The computer s/w designers/writers haven't really learned
how to adapt the computer medium to the process. Maybe it doesn't translate
well at all. The paper procress has been designed over centuries to how people
think and work. I hope it won't take centuries to adapt the computer medium.

What I think I am saying is that gnucash has done a very good job of
translating the double entry paper system onto the computer. What gnucash has
not done is change the perpective of the double entry system to fit the
computer medium. Note I did not say change double entry system. Rather the
"perspective" thereof.  Now I do not think gnucash is unique in this. The only
other "accounting" s/w I used did not do double entry, it really only
imitated the shoe box accounting I had before the s/w. It was constricting, but
easier than the shoe boxes.

As you say toggling between multi-line and double line mode is disconcerting.
Where I disagree with your assesment is that you seem to be assuming and saying
that the user must adapt to gnucash rather than gnucash adapting to the user.
gnucash could adapt to the user by changing the double entry perspective to
suit the computer medium instead of trying to force the computer medium to
adopt the paper system perspective. It just doesn't work well.

For example, hypertext - works beautifully on a computer. It would be a total
disaster on paper. Communicating with hypertext on a computer is really good at
leading the reader through disjointed, loosely related topics that can be fully
explained on a  single screen. Try explaining the full theory of general
relativity with all of the gory equations on a computer. That would be a
disaster.  It is impossible to flip from equation 1 on screen 5 to equation 50
on screen 30 and then to equation 75 on screen 45 and remember what you were
doing in the first place. In a book, that would be a trivial excercise  (I  can
attest to that from personal experience in the book at least).  Or for an
example you might relate to better. Think of scanning Knuth's 3 book set to
electronic form. Then think of using the electronic form as the only form you
had for learning the information. If you think it would be easy, pick one of
the books and seriously read a chapter. How many references were there to other
pages, chapters? How easy would it be to remember what you are reading, find
the reference, read that and then return to what you were doing or flip from
the reference to what you are reading and back and return and back to the
reference? It just doesn't work well. The whole format would have to be redone
to fit the electronic medium.


> now.  Splits, Transactions, and Accounts are all useful and valid
> organizational units, both from the user's perspective and from an
> accounting perspective.

Again you are correct, but that really has little to do with the users
experience in trying to use gnucash. It may have everything to do with an
accountant using paper journals, but not computer accounts. The terms and
concepts were created when paper journals were used. How good are those
concepts and terms when trying to educate a non-professional using only
computer s/w? When you can show me how gnucash can effectively, safely and with
99.9999% certainty detect entry errors as can be done with a paper double entry
system, then you can say that you have really adapted gnucash and double entry
to the computer medium. Right now gnucash cannot detect any monetary entry
errors at all. For that function of a double entry system, it is no better than
single entry.

>    
> Thanks for taking time to put your critique down in writing.

Thank you for taking me seriously.
> 
> Bill Gribble