On Tue, 2001-09-25 at 08:51, Bill Gribble wrote:
> I'm interested in adding support for transaction voiding to the engine.
> That is, the transaction and splits continue to exist in the engine but
> they don't affect balances.
>
> It's possible to fake this with a reversing transaction, but in general
> that's not really accurate; there would be an period between the initial
> transaction and the reversing one where account balances would be
> incorrect, where a true "void" just says "this transaction never
> happened, but we want to continue to keep a record of its entry".
>
> Any thoughts about how to do this? It would be possible to add voiding
> splits to the transaction (i.e. an equal-and-opposite split for each
> original split, in the same transaction) plus a note in the KVP
> structure for the transaction saying that the transaction is voided ...
> but is that correct from an accounting perspective? Should we really be
> just marking the transaction (or its splits) as void and somehow
> explicitly ignoring them in the engine?
I guess the real question is what should the visibility of a voided
transaction be? Should they show up in regular queries with their
original values? Putting in voiding splits could still let the
original splits affect queries & reports. A more agressive technique
might be to set the amount/value of voided splits to zero and store
the original values in kvp data. That might require less code to
be modified to check for void transactions.
dave
PGP signature