Vanishing transactions and log file [repair procedure and nominations for unreasonable behaviors]

Derek Atkins warlord at MIT.EDU
Sun Mar 30 10:17:43 EDT 2008


Quoting Ross Boylan <RossBoylan at stanfordalumni.org>:

> There was a substantive reason for replaying rather than re-entering:
> splits from new transactions are unreconciled.  But some of the deleted
> splits were reconciled.  It wasn't clear to me there would be an easy
> way to get reconciliation to work properly after entering the splits
> new.

That's not a substantive reason...  All you need to do is re-reconcile
them at the next reconciliation period.  The reconcile process doesn't
care about starting balance, only ending balance.  So if you accidentally
unreconcile a split for $100, then the starting balance will be off by
$100, but then when you put in the correct ending balance just check off
that $100 and you're golden.

> One reason for the confusion is that the comparable splits on previous
> transactions display with nothing showing in the shares or price
> columns.  So if one follows the "repeat what worked before" by copying,
> it doesn't work (in fact, the autofill feature repeats the whole entire
> transaction when I start a new one).

Correct, auto-fill goes by transactions, not splits.  But as I said
in my last reply, the register is showing you splits, not transactions.
That's why you see double.

> Editorial: Your development web site
> http://wiki.gnucash.org/wiki/Development has this:
> What this thing needs is some normal human beings using it and saying
> "you know what, it's NOT acceptable that window A obscures window B and
> freezes while window B is waiting for input from me." It needs, I am
> sorry to say, Quicken or MS Money users, who say "It was really easy to
> do X, Y, and Z, but here, I can't even figure out if it's possible,"

Note that that wiki page wasn't necessarily created by the gnucash
developers, so you cannot take what it says as gospel.

> Well, I've said that kind of thing about a few behaviors, but I tend to
> hear that "it's not clear the behavior is a bug" or at least that fixing
> it is a low priority.  I've also been told I don't understand
> double-entry bookkeeping, which is untrue.  Clearly I don't understand
> gnucash.

99% of the time this IS the case.. The user just doesn't understand.
In that other 1% of cases there really is a bug.  Most of the time
that bug (or misfeature) is already known.

> I'm a PhD, a financial engineer, a user of Managing Your Money, and a
> programmer of financial software, among other things, and the program
> repeatedly violates my expectations and apparently caused me to delete
> some of of my data.  This is not good.  You can tell me I should be more
> careful, or more knowledgeable, but the program simply doesn't act
> reasonably.

Excellent!  I look forward to your patches, then.

> I nominate the following features as unreasonable:
>
> 1. Displaying a single transaction as multiple entries in the register
> if one is in "Basic Ledger" or "Autosplit" view mode.  This only happens
> if the transaction has multiple splits using the account on which the
> register is open.  Note that if one follows the advice on entering stock
> sales, one will have multiple splits in the account on view.
> I thought these multiple entries were duplicates; I guess I tried to
> delete one and ended up deleting the whole transaction.
>
> To be clear, to me the group of lines headed by a date and followed by
> splits look to me like a "transaction," and I think they should be a
> transaction.  This means that if there are multiple splits for the
> register account the total of them appears in the line with the date.
>
> 2. Needing to enter 5 different splits for a single stock sale.  In
> particular, the split involving the stock and 0 shares at $0/share is
> unintuitive, inconsistent with the visual display of previous
> transactions, and inconsistent with the rule the shares * price = amount
> in the buy or sell column.
>
> 3. Changing the display and the splits without warning in the middle of
> entering a transaction.  Examples include carving one transaction into
> what (visually) is two transactions, reordering the splits (if it does
> that; it seems to me I've seen that), and eliminating splits with
> content (e.g., the stock split to record the kapital gain mentioned
> above).  If you're not looking carefully, you can miss the changes; if
> you are, you can be confused.
>
> The long run solution to #2 sounds as if it involves "lots"; a more
> practical short term solution would be a druid that asks for the key
> information once: number of shares; gross proceeds; commissions; capital
> gains (or perhaps basis or share price).  With lots the capital gains
> calculation could be automatic, since the original purchase price would
> be known.  Purchases require slightly different info.
>
> I know changing software is hard.  I just hate to see that, or excessive
> familiarity with the program internals, driving decisions about the best
> behavior for the program.

It's not that changing software is hard.  It's finding the development
resources to do the work.  GnuCash is a 100% volunteer effort.  Everyone
who works on GnuCash has a primary job doing something else so GnuCash
only gets the crumbs of time from what's left over after work, eating,
sleeping, etc.  THAT'S what mostly drives decisions..  How much time
will it take to do it, or, WHO will do the work.

I can't even COUNT how many half-finished features are still lingering
around in the source code.  Even I am guilty of starting something and
then not finishing it (the QIF importer rewrite).

So the best way to help is NOT to provide a list of more work to do, but
really (right now) it's to actually help us DO that work.

Not that the wiki is necessarily wrong.   While someone IS working on a
new feature it's very important for people to test it and give feedback.
However just saying "here are some major changes you need to fix" and
tossing that over the wall, or entering them into bugzilla (NOTE: You
should make sure your ideas are in Bugzilla so they don't get lost)
just adds to the apparent workload but still does very little to help
gnucash progress.

> Thanks to everyone for developing GnuCash, and thanks particularly to
> Derek for helping me dig out of my latest mess.

You're welcome.  I'm glad you undug yourself.

> Ross

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available



More information about the gnucash-user mailing list