Transaction voiding

[Dave Peticolas]

--=-DqZ3Dxq7U+d4W1UrkVhL
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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. =20
>=20
> 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".=20
>=20
> 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?=20

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


--=-DqZ3Dxq7U+d4W1UrkVhL
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA7sXLb5effKKCmfpIRArNJAJ9a6KG8OdEwoyIXexUtzWV4KMQ4CACfUQaR
Uc0+XQ7BzlEpaTi1GiG41+8=
=wzTF
-----END PGP SIGNATURE-----

--=-DqZ3Dxq7U+d4W1UrkVhL--