Design: Deleting Vouchers

[jniles]

This issue covers the design for deleting vouchers using the proposal described in #2044.

Design
Deleting vouchers will be performed from the Voucher Registry and the Posting Journal (via the transaction edit modal). It is not allowed on posted records. A deleted voucher will remove the lines from the voucher, voucher_item, and posting_journal. It will also remove the record_uuid from the document_map.

There are some conditional rules on this operation:

1. If the voucher has been posted, it cannot be deleted. The only way to reverse a posted record is by using a reversing voucher.
2. If the voucher has a referencing transaction, it cannot be deleted. This is most likely a second voucher that is reversing the current voucher.

The steps to implement this are:

1. Create a routing function from HTTP DELETE /transactions/:uuid that will determine if the transaction is a cash payment, voucher, or invoice.
2. Create the safelyDeleteVoucher(uuid) in the finance/vouchers.js. module.
3. Write the SQL logic to determine if the voucher should be deleted as described in the above rules.

[jniles]

Note: there are a couple of modules that create vouchers or reference vouchers on the fly to provide their financial documentation. These would have to be accounted for. I believe some of the stock modules/purchasing will have to take this into account.

[DedrickEnc]

I am wondering what is the purpose of this, because we can only discard a voucher or simply reverse it.
This design if accepted will cost a lot in terms of time during the implementation.
Are we sure there is no good alternative ?

[jniles]

The primary goal is to not leave any trailing receipts/documents when an accounting decides to remove a record from the Journal prior to it being posted.

There are three other goals:

1. Allow users to remove records that never made any sense. If these are unposted, the easiest way is to just delete it. That way, we don't have to check things like deleted or reversed in each of our queries.
2. Deflate the database size. According to this analysis, users are making mistakes all the time - 241 credit notes were issued in January/February. It would be proactive to allow them to simply abolish mistakes, rather than polluting the Patient Financial History with irrelevant information.
3. Symmetry with Design: Deleting Invoices #2160 and Design: Deleting Cash Payments #2159.

[jniles]

Closed in #2188.