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

[Charles Day]

On Sat, Mar 29, 2008 at 12:21 PM, Ross Boylan <RossBoylan at stanfordalumni.org>
wrote:

[snip]

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

Wow, I didn't know it worked that way. I always assumed it was one entry per
transaction, not one per split. So I second this nomination... and would
have made the same mistake. (Note: Transaction Journal mode operates as
expected.)


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

I don't think anyone would deny that there is room for substantial
improvement on ease-of-use here. Druids would be nice for buy, sell, short,
and cover, for starters. Someone just has to take up the development
challenge. Perhaps it will be me?


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

There is some "lots" functionality already (Actions->View Lots) so perhaps
some of the functionality needed to support a "sell" druid is already there
to be leveraged.

If I might add a fourth item to the "unreasonable" list:

4. It should not be possible, when manually entering a transaction, to put
the books out of balance without any warning. Currently users can put the
books out of balance quite easily by entering a currency exchange or stock
sale without accounting for the capital gains.

Cheers,
Charles

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
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>