Register stuff (summary of Carol and my talk).

Rob Browning rlb@cs.utexas.edu
24 Oct 2000 09:38:02 -0500


Dave Peticolas <dave@krondo.com> writes:

> I was considering using grey lines inside the transaction, but eliminating
> the lines for the blank date field might be good as well. When I get the
> infrastructure for this working, we can test it out.

OK.

> Why not put the 'diff' number in the unused 'deb' and 'cred' column?
> Since the diff column is only present in multi-line mode, the shift
> to multi-line mode and back would be rather awkward visually.

Actually, to Carol (and to me really), having diff number in the same
column as the normal debits and credits is one of the more confusing
things about the current approach.  It keeps the transaction line from
being visually distinguished, and it seem a little like comparing
apples to oranges.  Having a separate column makes it really clear
that this value is the summary value.  It would also make it *much*
easier to scan for a particular transaction by value.  Right now the
transaction totals are more or less just hidden in the "split noise".

> 
> >     Note too that this setup allows you to have two checks, and two
> >     check numbers in the same transaction without confusion.  This is
> >     something we can't do right now, and possibly something we don't
> >     want to do soon, but I figured it was worth mentioning as a
> >     possibility.
> > 
> >     When we look at this transaction from one of the other accounts,
> >     *everything* stays the same except for the diff and the balance.
> >     Here's what it would look like from Checking if we presume a
> >     previous balance of 1200:
> > 
> >  Date      | Num  | Desc             | Account   | deb | cr  | diff | bal
> >  --------------------------------------------------------------------------
> >  2000-10-01|      | Shopping spree.  |           |     |     | -700 | 1500 
> >            |      | Louis XIV chair  | Furniture | 200 |     |      |
> >            |      | Louis XIV sofa   | Furniture | 400 |     |      |
> >            |      | Art Deco ottoman | Furniture | 100 |     |      |
> >            | 1001 | Olga's Antiques  | Checking  |     | 400 |      |
> >            |  321 | Olga's Antiques  | Savings   |     | 300 |      |
> 
> Don't you mean diff = -400 and bal = 800?

Yep.  The former's an error because originally I didn't have two
checking accounts and forgot to go back and fix things up when I
changed that, and the latter's a "not paying attention" error.

> With the general ledger approach (show all splits), there is no need to
> have the 'current account' field, because the splits in the open account
> are visible as well, and presumably editable.

Right, but here I'd shifted to a broader discussion.  We'd still have
it in other non-single modes (presuming we still have other non-single
modes), and tabbing straight to it seems both inefficient in general
and probably confusing to new users.

> Conceivably, there is both a transaction number and a split number. 

True, but though I think that in theory, having split numbers is
likely a good idea, and if we do add a split num, then most of the
time, that's what the user should be using, *not* the transaction
number.

If we had only multi-line and single line modes, we could just set it
up so that in single-line, the num column was the num from the first
split, and in multi-line you could see all the num columns.  However,
if we keep the double-line modes, I fear that most people will keep
using the transaction num line for single split transactions.  That's
not what we'd want unless we want all code that needs the check number
to have to try and heuristically check both the transaction num and
the first split num and guess which one to use.  I don't like that at
all.

Alternately, if we fixed it so that single line mode had the
transaction memo (as soon as we add it - which I could do immediately
if you like) in it, then could we even consider doing away with
everything but a really good single-line mode and a really good
multi-line mode.  Or how about if did keep a double-line mode,
changing it to be just a more horizontally compact single-line mode
rather than a subset of multi-line mode.  For example, in that case,
the num field in double-line mode would still be the first-split's num
field.  The only way to get to the transaction num field would be
multi-line mode.  So we'd have single, double, and multi, but double
would be more like single-line mode than multi-line mode...

> I think this is a good idea, but again, how would the 'diff' field
> be displayed in that case? Just stick it in that one line? It would
> be visually hard to parse, I think.

You're right.  This is the biggest unresolved issue with the proposal,
but I tend to feel that the separate column in multi-line mode is
really important, so let me think about it for a bit and see if I can
come up with a good solution.

> I checked in some work today that removes the blank split lines in
> multi-line mode except for the current transaction. Thus, multi-line
> mode is now an 'auto' mode.

Woo hoo.  I think I'll probably like that a lot :>

Thanks
-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930