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

[Ross Boylan]

[Original problem was that I had lost some transactions and others
appeared mangled, e.g., dollar amounts got treated as number of shares.]

On Sat, 2008-03-29 at 12:43 -0400, Derek Atkins wrote:
> > 2. Is there some way I could cut out pieces of them [log entries]
> (e.g., the lines
> > starting with B), put them in a file, and replay them to get them
> back?
> 
> Ummm.. I wouldn't.  It would be easier and faster to just re-enter
> the transactions by hand.

Having located one log file that had (all?) the offending deletions, I
first reentered them by hand and then (mostly because that had been in a
test account), I:

1. renamed the original log file so it wouldn't get deleted.
2. changed all occurrences of "D" at the start of the lines in the log
file to "C" (D=delete, C=commit, and the B's I saw were "Begin").
3. opened my main data file and asked GnuCash to replay the log I had
just edited.
4. edited (in the register) the transactions to clean them up.

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.

I also put the register in "journal" view mode, and I found the display
did less visual rearranging as a result.  I still found myself fighting
the automatic behavior at times.

For example, one split to record the capital gains against the stock
account showed the number of shares as the dollar value of the gains,
the price as 1, and then the capital gain in "Tot Buy" column where it
was supposed to be.  This made my share totals wildly off.  I deleted
the # of shares and the share price; when I hit tab to the next split
that entire split was deleted, and a corresponding imbalance (or maybe
orphan) entry appeared at the bottom of the transaction.  When I
reentered the same split with "0" shares (as the user guide recommends)
everything worked.

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).

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,"

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.

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.

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.

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

Ross