Notes on #2321 (reversal of the original invoice)
Thinking about #2321, I consider the following transaction types which could want to be reversed:
- Invoices (AR and AP)
- Transactions (AR and AP)
- GL transactions
- Payments
Reversals of payments are special, because payments aren't real transactions in the system at the time of writing. Payments have their system for reversals though and they do exact reversal of the transaction, which means we can consider them to be "addressed". Below are the considerations for reversals of each of these transaction types.
Starting with the simple type, reversal of GL transactions can be as simple as marking the transaction to be reversed (thereby blocking it from being reversed again) and posting a transaction (which is marked as a reversal transaction) with exactly the opposite amounts.
Using the "reversed" / "reversal" indicator, the UI can provide user feedback with respect to reversal status.
Invoices and Transactions share a common complexity: payments. While payments by themselves have reversal criteria and the criteria for invoices or transactions without payments applied, can also be specified relatively straight forward, reversing an invoice with a payment applied isn't as straight forward because the payment needs to be undone as well, one way or another.
With respect to applied payments on an invoice to be reversed, I see the following options:
- An invoice can only be reversed if all applied payments have been reversed
- The reversing invoice will have a negative payment applied, used to create an over payment
- No payment gets applied to the reversing invoice (but the payment remains in place on the reversed invoice), leading to a negative AR/AP position due to the negative invoice