Vanishing transactions and log file

Ross Boylan RossBoylan at stanfordalumni.org
Tue Apr 1 11:55:17 EDT 2008


On Tue, 2008-04-01 at 10:51 -0400, Derek Atkins wrote:
> "Donald Allen" <donaldcallen at gmail.com> writes:
> 
> > Thinking about this some more, one *could* imagine the atomic particle
> > of the basic register being a transaction, not a split. Then, in a
> > case like this, you would see one entry, not two. I think for most
> > people (myself initially, and probably for Ross) this would be less
> > confusing. But it would also be less informative, as I mentioned in my
> > previous message, because without expanding the splits, you would not
> > know that there were two splits involving the account (for which
> > you've displayed the basic register). I prefer it as it is, having
> > figured it out after my first "what's this?" reaction and come to
> > realize that it makes sense.
> 
> True, one COULD imagine this, but then you have a problem.  When
> displaying/editing the split-specific data, which split's data do you
> show/edit?  Yes, it might sound nice to be able to combine the values
> into a single line, but what do you do if you try to change the
> number?  See, there are MANY reasons GnuCash does it the way it does.
> :)
> 
> > /Don
> 
By the way, I've also been confused by the rules regarding the comment
or note in the header line vs the notes on the splits.  In some views
there seem to be 2 header lines (top one with the date and most of the
key info, 2nd one for the note, I assume).  I think there is a notion of
a "transaction comment" distinct from a "split comment", but the
contents of the transaction and split comments seem to get copied
between each other (in the display) following some rules I haven't
understood.

Back to the main question, I'll repeat that a design that invites
misinterpretation is not a good design.  I also agree that there are
times one would want to see the splits.  So far, we've been going back
and forth about what to do with the register as it is now, but this
suggests that an adequate solution might involve a different approach
altogether.  Unfortunately, the only thing that immediately comes to
mind is a small tweak.  I did notice a comment about future directions
for gnucash saying that the current design was oriented toward
replicating a paper checkbook, and that was not optimal.  So maybe
someone else already has some ideas.

The small idea is to replace the current views (basic/autosplit/journal)
with splits vs transactions views.  The former would be a lot like the
current "basic" except that it would either be read only or it would do
something special if you tried to delete or alter a split.

The problem with that is that it makes the typical case, a transaction
involving exactly 2 splits, awkward.

Ross


More information about the gnucash-user mailing list