Destroying Entry does not destroy the associated credit and debit amounts.

[vanboom]

entry.destroy does not remove the associated credit and debit transactions and does not affect the account balances. Test by creating an entry with credits and debits, and then destroy the entry. The associated credit_amounts and debit_amounts are not removed.

Is this intentional or a bug maybe? It seems intuitive that deleting an Entry should update the account balances, but I might be missing something?

Thanks

[mejibyte]

+1, seems like a bug to me.

[Aesthetikx]

This is seemingly addressed by #108

[mbulat]

Normally I would immediatly say yes to this, since I definilty don't like orphaned records. My only hesitation is that with accounting, deleting records should be rare to never happening. Obviously there's accounting perfection and then there's the real world.

At the moment, if an entry is accidently deleted, the credits and debits leave a little information to show that something bad may have happened, which might help during a reconciliation/audit process. On the other hand from the app perspective, its a bug since there's no obvios method to call out orphaned records.

Perhaps what we need is a better method for deleting entries that makes deleting a little harder? Maybe we overide destroy/delete with something that gives a warning / leaves an audit log?

So my instinct is to merge this, and then add a new feature. But if anyone is relying on this bad behavior at the moment I'm open to keeping it around till the new feature is in place.

[vanboom]

Generally I would consider protecting the destruction of the entries as a higher level responsibility for the application. If a credit/debit amount requires an entry to be valid, then the destruction of the entry should also destroy the associated amounts.

[mbulat]

Entry deletion has come up before, and I think I'm going to try and make the default behavior to make entries immutable.

Plutus's philosophy has always been to at the minimum ensure that accounting is done correctly, and deleting entries really is not the correct way to go about things. Lots of companies start out winging things, and then when they grow and need to deal with GAAP and outside audits, the s*** hits the fan. Part of the reason I created plutus was, having been through that, to create a basic account system that gives companies a few basic best practices. Ultimately, you don't really need "double entry"... basic accounting can be done easily with single entry systems. So by picking double entry, you're choosing to start out doing things properly, and part of that is not deleting entries.

So I'll leave this issue open for the time being. And reference the new feature issue from here.

[vonchristian]

What I recommend also instead of deleting the entry is to create another entry that corrects the previous one. By reversing that entry, you can make sure the balances on the accounts are back to where it was.

[mbulat]

Opened a new issue #133 to cover the new feature. Please let me know if anyone has any further suggestions for revision features there.

[vanboom]

Our application acts as an intermediate between Quickbooks, so we need the flexibility to get the accounting transactions correct (i.e. delete entries and the associated amounts) before exporting them to Quickbooks. We never edit entries, but need to delete them occasionally when a user enters an invalid transaction that we need to correct.

This issue addresses the behavior of the entry / amount relation. If a credit/debit amount requires an entry to be valid, then the destruction of the entry should also destroy the associated amounts. It is OK if entries are immutable, but destroying them should destroy the amounts that belong to the entry.