Bill Gribble <[EMAIL PROTECTED]> writes:
> The last problem doesn't go away at all; stock splits will cause
> problems for cost-basis computation no matter how they are
> implemented. That's just something that needs to be dealt with.
Sorry, I should have been clearer. I didn't mean to lump this into
the "fixes it" bin. It's just no better or worse with either
approach.
> It seems like Rob's main argument relates to editing. If you make a
> mistake in entering some information before the split, like the
> number of shares you own, he wants corrections to that information
> to propagate through the split, so that you don't have to go back
> and edit the "split event" by hand.
And every subsequent one.
> It seems to me that the stock case is similar; when there's a stock
> split, you receive a real, concrete number of "new shares", not a
> "multiplier". If you make a mistake in recording the transaction,
> you *should* have to edit it.
Actually, I think perhaps this is a winning argument, and I don't know
why I didn't think this way initially. Since you *should* :> be
reconciling your accounts with your financial statements, you will
know *exactly* what happened from the statement which plus or minus
you calling up and making cranky noises when they make a mistake *is*
authoritative.
OK. I say Linas' proposal, better documentation, and a
dialog/druid/helper for stock splits it is. Unless some strong
objection comes up, I'll see to it.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
