`Balance' dialog box.. what is it for.

[Josh Sled]

On Wed, 2004-08-04 at 22:12, Harry Putnam wrote:
> Josh Sled <jsled at asynchronous.org> writes:
> > On Tue, 2004-08-03 at 23:09, Harry Putnam wrote:

> As above `simple deposit withdrawal stuff'  read=> I put in 30, I take
> back out 20.  I get the aggravating dialog box.  Of course this is

Ah.  So, this is two transactions...
* Transaction 1 -- "put in 30":
  Income:      "-" 30 [running balance: 30]
  Assets:Bank: "+" 30 [running balance: 30]

* Transaction 2 -- "take back out 20":
  Assets:Bank:        "-" 20 [running balance: 10]
  Expenses:Groceries: "+" 20 [running balance: 20]

[I quote the "+" and "-" because the meaning of "crediting" and
"debiting" accoutns can become non-obvious at times... but stick with
it, though, and it becomes intuitive.]


> unbalanced .. what else would it be?  If money remains in the account
> the balance will not be zero.

The balance of the *transactions* will be 0.
The balance of the *account* will be >0 [hopefully! :)].

> This term `split' seems rather silly to me.  What is being split here?

Aye, we could use a better user-facing word.



> > * of what amounts?
> 
> Opening balance (678.06)... to enter it I must be handed the dialog.

Equity:Opening Balance: -678.06
Assets:Checking       : +678.06

> To take something from it (atm withdrawal of $240) again the dialog.

Assets:Checking: -240
Expenses:This  : +120
Expenses:That  : + 90
Expenses:Other : + 30

> To add something back (deposit 200 from a saving account) again the dialog.

Assets:Checking: +200
Assets:Savings:  -200


> Not to just be a wise guy but:
> I'm not real concerned with zero balances.  Far more interested in
> the + kind.  But must keep up with the - kind or go to jail.

:)

The double-entry-accounting constraint that all transactions sum to zero
is a Good Thing.   Obviously, our UI and docs needs to polish it some
more...

> I see I'll have to really dig into the documentation etc which does
> seem a bit ridiculous for something as simple as keeping track of a
> basic bank checking account.  I could understand needing to do some
> reading and study to process complicated financial stuff in gnucash
> but it shouldn't take all that to keep up with a check book.

No, the problem here is with GnuCash's usability.  It needs to be as
approachable as a checkbook, and graciously allow and expose it's true
nature.  We're obviously not quite there, yet.

...jsled

-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`