[EMAIL PROTECTED] writes:
> -- first, the current register code would display this transaction
> twice, (which is a bug), leading to no end of confusion.
>
> -- next, we have that sign-reversal problem debated in earlier emails.
> There'd have to be some care to make sure the sign didn't get
> accidentally reversed: there might need to be special case code
> for detecting when both ends of a transaction are in the same
> account.
>
> -- finally, this might introduce problems with the cost-basis code.
>
> On the other hand, this seems to have less of an overhead than
> introducing 'yet another field' into the engine, and tracking the value
> of that field ...
Well, since the alternative, that of just recording the split event
and computing everything dynamically based on that, avoids all these
problems, I think it would be worth at least a little time trying to
see exactly what it would take to implement so we can accurately
compare the alternatives, and it may well be that it's it's not worth
doing either because it's a bad idea, or because it would be to hard
to mplement to be worth it...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
