Apply payment to an invoice

features
1

Apply Payment feature

Example Systems

User Stories

Epic

Add Apply Payment feature to the invoicing to allow us to keep track of payments to enter the date, type of payment, reference # and total amount

Payment

  • As an invoice user, I would like to apply full payment to a single invoice so that I can close the invoice
  • As an invoice user, I would like to apply a partial payment to a single invoice so that I can track
  • As an invoice user, I would like to apply partial payments to multiple invoices so that I can split the payments across multiple invoices
  • As an invoice user, I would like to apply full payment to multiple invoices so that I can mark the invoices as completed
  • As an invoice user, I would like to update a payment to edit the reference number, amount, date, etc
  • As an invoice user, I would like to update payment application to edit the amount applied to different
  • As an invoice user, I would like to see the balance due for across all vendors in the system so that I understand the total amount that is owed
  • As an invoice user, I would like to see the balance due for for a single vendor in the system so that I understand the total amount owed to a vendor
  • As a user, I would like to see the history of payments for a single invoice so that I can see an audit trail of all payments on an invoice

Credit / Refund

  • As an invoice user, I would like to create a credit note (i.e. overpayment) so that I can apply the credit to a future invoice
  • As an invoice user, I would like to create a refund for payment(s) already processed
  • As an invoice user, I would like to apply a credit to a single invoice
  • As an invoice user, I would like to apply a credit to multiple invoices

Integration

  • As the payment service, I would like to process a payment message from a third-party system in order to track that a payment has been received
  • As a user, I would like to enter an online payment (processed through a payment gateway)

Proposed Data Model

Payment

  • Status (Pending, Partially Paid, Not Paid, Cleared/Settled, Paid, Overdue, Authorized, Received, Refunded, Not Authorized, Canceled, Declined)
  • Payment Type
  • Payment Date
  • Reference Number
  • Party To
  • Party From
  • Total Amount
  • Currency
  • Payment Method (ACH, Cash, Check)

Payment Application (allows for splitting payments across multiple invoices)

  • Payment
  • Amount
  • Invoice
  • Invoice Item (optional, probably not going to implement)
  • Billing Account (optional, not going to implement)
  • GL Account (override)

Payment Method (already exists)

Payment Type

  • RECEIPT (enum)
    • Customer Payment
    • Customer Deposit
    • Vendor Credit
  • DISBURSEMENT (enum)
    • Customer Refund
    • Vendor Payment
    • Vendor Prepayment

NOTE: We aren’t trying to turn OpenBoxes into an Accounting / ERP system so data associated with the following entities will be ignored for now.

  • Billing Account
  • Journal Transactions (we don’t want to become an accounting system)

Design Questions

  • How are payments applied to invoices?
    • Do we want to just have an Apply Payment to apply full payment for a single invoice?
    • Do we need to support full/partial payment for single/multiple invoices?
  • What will the user interface need to support?
    • single payment for single invoice (simplest)
    • multiple invoices per payment (requires selecting invoices)
    • multiple payments per invoice (enter multiple payments, either all at once or separately)
    • CRUD for payments (might be required for superuser)
    • allow a payment to be created but not applied to an invoice?
  • What level do we need to track payments?
    • invoice
    • invoice item (very difficult, probably not going to do as a first pass)
    • in other words, does the user applying a partial payment need to select the invoice items which the payment is being applied to?
  • Do we need to support overpayment of an invoice - does that happen?
  • Do we need to handle discounts and/or credits? If so, how?
  • Do we need to handle exceptions like bounced checks, etc. If so, what exceptions?
2

@mkatongo Here are the requirements and design questions I mentioned earlier today. The user stories are just my guess about what needs to be supported. Please let me know if I’m missing anything. In addition, it would be helpful to get priorities assigned to each user story using whatever prioritization method you want (e.g. MoSCoW - Must, Should, Could, Won’t). We can then estimate the cost of Musts/Shoulds and leave the Coulds/Won’ts for later.

cc @Artur

3

@jmiranda here are my responses

How are payments applied to invoices?

  • We just want to have an Apply Payment to a single invoice
  • Partial payments not required for now

What will the user interface need to support?

  • We just need single payment for single invoice

What level do we need to track payments?

  • At invoice level

Do we need to support overpayment of an invoice - does that happen?

  • Not required at the moment

Do we need to handle discounts and/or credits? If so, how?

  • Not required at the moment

Do we need to handle exceptions like bounced checks, etc. If so, what exceptions?

  • Not required at the moment

If possible if we can have an Export to csv Button on the List Invoices page that includes (payment type and references).

Thanks

4

Thanks @mkatongo.

@Artur Let discuss this on Slack at some point this week.

5

@jmiranda sorry for forgetting about this one. I did a small spreadsheet with a rough estimation of this feature. I estimated this as a basic implementation of an option to select 1 payment per invoice (without splitting the payments option, although I think this should be supported on the domain level for the future while implementing this). I sent you it on slack, we can discuss it further this week.