Aller directement à la fin des métadonnées
Aller au début des métadonnées

Support Online Payments for Unpaid and Partially Paid Invoices

Invoices list goods or services provided and the amount due for them, and can be unpaid, partially paid, or paid. They are often required by organizations in workflows like cheque requisitions which ask an accounting department to pay an amount owed. Currently CiviCRM supports invoices for amounts owing as well as previously paid via the Contact Dashboard. But there are several improvements required.

  1. CiviCRM does not natively have a way to process a credit card or other immediate online payment to pay for an existing “pay later” contribution either in the backend or front-end.

    1. Build front-end and back-end processes for paying existing invoices online (this is simpler than the 2012 spec).

      1. Front-end: The contact dashboard already displays links to PDF invoices; extend that by creating a link to pay any open invoices (balance due) online.


        Clicking the Pay Now button will bring up the contribution page defined as the default invoice payment page on the CiviContribute Component Settings page:

        A validation will be made to ensure a payment processor is defined for the selected contribution page, and that it is enabled. A validation is added to Edit Contribution Page to ensure that if the page is defined as Default invoice payment page, then it is invalid to remove the last payment processor from the page. (Please verify that there is a validation to prevent a payment processor from being disabled if it is in use on a contribution page like the Default invoice payment page.)  

        When a Pay Now button on a Contact Dashboard is clicked, the Default invoice payment page is loaded:

        1. Discounts, premiums, recurring payments and pledge sections of the page will be disabled.
        2. The price set part of the page will be replaced with a frozen (ie non-editable) listing of the existing line items for the contribution, membership, or event registration, including taxes, with discounts applied. 
        3. Option A: The total payment amount could be frozen.

        4. Option B: Partial payments could be supported.

      2. Back-end: On the New Contribution form, near the top right there a link submit credit card contribution. The differences between the Create contribution form in the two cases provide a pattern for how this could be done on the edit form with minimal effort (though perhaps not optimal usability):


    1. As an additional feature, the ability to pay for outstanding online will need to accommodate partial payments (where the user has partial amount due on the invoice total). 

  1. Create a process to auto-generate membership invoices for the coming year. (lower priority for core integration)

(Background:Contribution records are created in one of two ways -- either by processing a online transaction (typically a credit card, but also PayPal, direct debit / ACH), or through a pay later contribution that gets a Pending (pay later) status and is typically paid through an offline means (checks, also certain types of EFTs outside of North American). Both ways are supported in the back-office for staff and on public facing pages for users. The former supports actions such as an individual becoming a member for the first time, where the membership record and transaction are created through the application form. Such pay immediate transactions are handled the same using cash method and accrual method of accounting. Pay Later transactions are currently recorded in CiviCRM as accounts receivable amounts, which is used in the accrual method of accounting but not the cash basis.)

Better Handling of Refunds, Partial Payments, Multiple/Split Payments

Currently refunds must be handled through a two-step process: process the refund through the payment processor and then record the refund in CiviCRM. Partial payment processing is provided for events but has some shortcomings. Partial payments for memberships is not currently available.

  • Integrate refund handling directly in CiviCRM so that the actual transaction can be processed from the system. This functionality will be payment processor dependent. Initial need is for Authorize.net.

  • Enhance partial payments for event registration to support credit card payments and improve the general flexibility of the tool.

  • Implement partial payment tools for membership records. This will need to accommodate several use cases:

    • Membership type is changed: The user signed up for a membership they do not qualify for and must pay a balance to join at the correct level.

    • Membership fee is changed: A student joins at the full rate and is later informed the chapter will cover 50% of their dues. In this case, a refund is owed the student and a partial (split) payment applied to the chapter.

  • Support the ability to move a payment/contribution to a different contact. This may happen if a chapter pays the dues for one student and later determines it should be applied to a different student.

Étiquette
  • Aucun
  1. Apr 12, 2016

    JoeMurray dit :

    Some preliminary points for confirmation before I work on specs for the second section.

    Refunds through payment processors:

    1. Refunds will be a back-office only operation, and will get their own create permission.
    2. When an edit to a contribution (possible for membership purchase) or event registration results in reducing the total to less than has been paid, and the payment was made via a payment processor that is currently enabled, and this payment processor plugin supports refunds, and the user has refund permissions, then the user will be asked if they want to refund the amount or create a credit note. Otherwise the current process of creating a credit note occurs automatically.
    3. There will need to be a UI for refunds, both on the Contact Summary page Contributions tab and on the Contact Dashboard.
    4. Existing reports will not be changed from using the final amount after refund.
    5. A new report on refunds is required.

    Partial payments for events:

    1. Will the spec above for partial payments handle this? 

    Partial payments for memberships:

    1. Will the spec above handle additional payments required as a result of changing the membership type to a more expensive one?

    Membership partially paid by chapter:

    1. I take it you want the functionality in the backoffice new membership form that supports

       

      to be made available as an option when editing the contribution associated with a membership, and for only part of the amount. It is currently possible to make an edit to a Gift type soft credit for a partial amount by a different contact. Perhaps we can enhance the functionality here with a new 'Paid on behalf of' soft credit type that will result in a credit note/refund dialog for the original payor? Question: do you need to have an option to process an online payment at this point against the chapter or is manually recording an offline contribution sufficient?

    Move payment from one contact to another:

    1. Would it be okay to make this as an extension? In terms of a UI, what about making a change when the user is reducing or cancelling a 'Paid on behalf of' amount: in addition to options for refund and credit note, there could be an option to apply amount to a different membership payment of a different contact?

    General:

    1. I think we should likely specify automated emails for a number of the scenarios in the whole Deferred revenue/accrual accounting project. 
    2. As we move to having multiple activities on the payment side of the obligation/payment split, we should also examine existing workflow message templates for events, contributions and memberships to see if they can properly handle invoices with multiple payments and refunds and credit notes.
  2. Apr 12, 2016

    refunds:

    1. correct. only a back office operation.
    2. only admin staff will control this. but yes – they will have the option of either issuing a refund or retaining a credit note which may be applied to another invoice at a later time.
    3. I think this follows our discussion of terminology: an invoice is an obligation to pay. a payment is a debit against that obligation. a refund is a credit against that obligation – either because the obligation was canceled, adjusted, or a recorded payment exceeded the obligation. so I would envision a refund as simply being a negative payment. I'm not sure it deserves it's own interface. I think the bigger issue is how we more clearly distinguish between the invoice obligation and the payment/refund. currently, the only place you can truly view payments is by viewing and event registration and clicking to view payments. all that said – you have a better handle on this than I do, so I defer to you.
    4. not sure what you're getting at with that item.
    5. yes. more broadly, I think we need reports on payments (not just invoices) as well as refunds.

    partial payments for events:

    1. the UI seems to account for full payments (you note that the total amount is frozen). when viewing a contribution (i.e. invoice) record, I think we need to be able to view the existing payment history, so that the amount due is distinguished from the total amount. as currently envisioned the amount due is not clear.

    partial payments for membership:

    1. yes, with the same qualification as with events

    membership partially paid by chapter

    1. yes, that is the gist of things. however, I'm reticent to use soft credits as that is functionally very different from what we're doing. we are actually recording a partial payment against a second contact – not just giving a second contact attribution for the payment. and yes, we need to be able to handle credit card payments for this use case. If I were to describe it differently: a contact will "own" an invoice – it is their obligation to pay. but who actually supplies the payment for that obligation is not bound to the owner of the obligation. one or more contacts may submit partial payment for the obligation.

    move payment from one contact to another

    1. I'm not opposed to it being an extension, but think it will live better in core. this use case is better understood with the idea of credit notes discussed earlier. for example: Jane is a student and signs up for membership. she owes $40. her region agrees to pay 1/2 – they pay $20 which is recorded against the invoice, leaving $20 balance which Jane is responsible for. she decides to switch majors and become a philosopher, and ignores the invoice. the region finds out and wants to move that payment to Ricky, who recently expressed interest in joining. so really what would happen is that the invoice for Jane would be canceled, creating a credit for the $20 paid by the region, and would need to be moved to another invoice. I think the key here is that although invoices are attached to contacts, they live as semi-independent records that a payment from any contact could potentially be recorded against.

    general

    1. agreed. optional emails (as currently)
    2. agreed. sounds painful.

     

     

     

    1. Apr 12, 2016

      JoeMurray dit :

      Thanks - very useful. I am going to put some thought into a significant refactoring of the UI for contributions.

      My only big question - totally unexplained by your response - is why switching to philosophy makes Jane want to ignore the invoice and not become a member. (clin d'œil) What kind of club is it anyway?

  3. May 05, 2016

    Some additional comments/feedback from the client, in response to your comments:

    refunds:

    4. - This should also create a correcting journal entry to correct the account affected, to ensure the journal entries recorded on the trial balance are correct.

    partially paid membership:

    1. - Manually recording the transfer of a payment from one contact to another contact is preferred.

    Example: We receive a check payment for student dues of $60 from Mohawk Company for student Jane Doe. Mohawk informs us Jane Doe is no longer an employee and that payment should be transferred to Henry Doe. We need to cancel Jane Doe’s dues of $60 which will leave a credit on Jane’s account. We then need to transfer the $60 credit to Henry Doe’s open invoice.


Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.