Skip to content

Invoice redesign and Payment Options

Jump to bottom
Christopher Neugebauer edited this page Apr 6, 2016 · 5 revisions

This wiki outlines a design for issue #15

InvoiceController changes

  • InvoiceController has a get_remaining_balance() method
  • InvoiceController.pay() no longer exists -- add to testing helper controller?
  • InvoiceController.refund() no longer exists -- add to testing helper controller?
  • Add evaluate_payments() method to InvoiceController
  • Changes the invoice status (see below)
  • Marks a cart as released if refunds are applied such that the remaining balance becomes positive again

Invoice model changes

  • Remove .paid and .void

  • Invoice can have the following statuses:

  • UNPAID

  • VOID

  • REFUNDED

  • PAID

  • -OVERPAID-

  • -PARTIALLY_REFUNDED-

  • UPDATE: OVERPAID, and PARTIALLY_REFUNDED have been retired in favour of credit notes.

  • Denormalise issue date for invoice

  • Denormalise due date for invoice

  • Invoice line-items should link back to the Product that they apply to, for reporting purposes.

Invoice UI changes

The dashboard should not report VOID invoices which have no payments applied (i.e. invoice status is VOID) -- most people only care about the most recent invoice they have for a cart, as well as all of the invoices that are paid and refunded.

Payments

  • Payments derive from PaymentBase -- each PaymentBase will need to be able to generate a reference for displaying with the invoice

  • Refunds are payments with a negative value -- how they're modelled at the payment app's end is left to the payment app!

  • Once credit notes are implemented, the standard way of producing a refund should be to issue a credit note against the invoice -- the subsequent credit note can be applied to an invoice for cancellation fees or refunded there.

  • PaymentBase objects should never be deleted

  • Carts should validate themselves and extend their reservation by 10 minutes to allow for payment.

  • Should not be able to pay on an unreserved cart. HOW TO ENFORCE?

Manual payments

  • registrasion comes with a staff-operated manual payments option:
  • Staff can enter a reference and a payment amount, which can also be a refund. Applying a manual payment will re-evaluate the invoice's status.

Credit Notes (FUTURE WORK)

  • Staff can generate a credit note for deltas between the invoice amount and the amount paid (or zero and the amount paid in the case of a full refund). This can take an invoice from OVERPAID to PAID; from UNPAID or PARTIALLY_REFUNDED to REFUNDED without engaging a payments gateway.
  • Credit notes can be applied by staff in full to the cost of other invoices, or refunded in full
  • Applying a credit note that overpays an invoice will automatically generate a new credit note.
Clone this wiki locally