GUI - accounts vs. transactions

Terry tboldt@attglobal.net
Thu, 5 Oct 2000 16:31:07 -0400


On Thu, 05 Oct 2000, you wrote:
> Terry writes:
> > 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 posti
> > came to me last night as I was trying to get to sleep.
> 
> I think the issue that is the most confusing is how memos work.
> You point out that GnuCash tries to help the user by copying the
> memo field, but ends up confusing things because memos are really
> associated with splits and not transactions.
> 
> If I understand your post, you are suggesting that gnucash stop
> performing this copying, and I agree. Additionally, I think it
> would make sense if we introduced a 'memo' field (we should give
> it another name, say 'notes') that really is associated with
> transactions and not splits.
> 
> Thus, in double-line mode, you would see this transaction 'notes'
> field, and it would be the same regardless of which register you
> viewed it from, and would be copied whenever the transaction was
> duplicated, auto-completed, etc.
> 
> There would still be split 'memos', but you would only see them
> associated with splits, i.e., in the mult-line and auto-modes, and
> GnuCash would not try to perform any special copying behavior.
> 
> Would that makes things easier to understand?
> 
> dave

Dave, I'm really conflicted in answering this. 

Yes I think that what you are proposing would answer the problem with the
"memo" field, but it doesn't address what I think is the underlying conflict. At
this point I'm stumped to try and write more. I want to suggest ways to resolve
what I percieve to be the underlying conflict, but I am at a complete loss to
be able to do so. I don't know if this is because of my ignorance of
accounting or my ignorance of GUI's beyond using them and knowing what I like
and what I don't like. I just have this feeling that "patching" or rather
"fixing" problems like this will arrive at a workable product, but not a really
good or great product which is what I believe gnucash can become and I want it
to become. I think that resolving the conflict  I perceive will require a leap,
one of those "Aha" moments. It will require stepping out of the "box that we
are currently in" and viewing double-entry accounting or maybe the problems
that double entry accounting is supposed to solve from a new perspective. Will
that require redoing double entry accounting? I don't know. I would hope not
since getting knowledgable people to abandon double entry and accept a new
method would take generations and another Richard Stallman. I would rather
think at this moment in time that the conflict can be resolved with a
new/different/out of the box approach to the GUI. I don't know if this is
justified thinking on my part or just wishful thinking. I do know, after having
spent 99% of my working career in pure/basic/applied research and development
that managing/forcing/cajoling/motivating/anticipating a "Aha" moment is not
humanly possible. It will come on its own time, in its own way for some-one
probably not looking for it, but another solution to another problem. I guess
that this is all a long-winded way of saying that what you are doing is
probably correct at this point in time and we will have to wait for the person
with the "Aha".

Maybe this will inspire an "Aha" for some people:

-------Natural Childbbirth--------
Two siblings are born naturally on the same date, in the same year, to the same
mother and the same father. However, they are not twins - neither fraternal nor
identical. Is this possible or impossible?

Answer posted if enough people want it.