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

Draft proposal for phase 1 implementation of partial payments for events and memberships.

Phase 1 Scope

  • Support input and receipting of partial payments against event registration and membership fees. The total fee can be "paid" in any number of payments. Example: Event fee is $500. Participant pays $100 deposit at registration. Remaining $400 is received and recorded on the day of the event.
  • Partial payment of donations is not supported. Pledges and recurring contributions already support these use cases.
  • Only back-office partial payments are supported only for this iteration. The same model can be used for self-service (online) partial payments. However this will require additional UI and data model work to allow admins to configure partial payment "rules" for self-service / online "purchasing" (e.g. a rule might be ... for this event, participants can make an initial deposit of $nnn amount OR pay the entire amount). A new interface will also be needed for participants / members to return to the site to submit additional payments against a partially paid registration or membership.

Make it Happen Goal for this phase: $3,750

Data Model

  • Contribution records will continue to represent "actual payments received" (rather than re-interpreting them to represent "obligations to pay").
  • Participant and Membership records will carry a "total fee", and continue to represent "obligation to pay" (participant records already include this total).
  • The existing Participant_Payment and Membership_Payment join tables will support one OR multiple payments (contribution records) linked to a Participant or Membership "obligation".

Schema / Meta-data Changes

  • Add "fee_amount" column to civicrm_membership table (stores total membership fee "obligation").
  • Add "Partial paid" status option for Membership and Participant records.

User Interface

Event Registration

  • Record $100 deposit against $500 event fee:
    • Use existing back-office forms for "Add Event Registration", "Submit Credit Card Registration".
    • Select "Partial paid" from Participant Status dropdown.
    • Select $500 total event fee (radio button)
    • In Payment Information block, over-ride default "total fee" ($500) and enter $100.
    • Submit the form.
    • Participant record with "Partial paid" status and a linked $100 contribution record are created.
  • Record $400 balance for event:
    • Go to contact's Events tab OR use Find Participants to find "Partial paid" record.
    • Participant records in "Partial paid" status include a new "Action" - "Make Payment"
    • New form includes input for payment amount (defaults to remaining balance) and ability to modify Participant Status.
    • Since this is balance payment, accept $400 default and change status to Registered. (If this was another partial payment, you could modify the amount as needed and leave status as Partial paid.)
    • Second contribution record ($400) is created and participant status is updated.
    • If you View Participant record, you will see both contributions listed on the screen.
  • Participant Counts - admin can using existing mechanism to controlling whether "Partial paid" participant status should be counted against Max Participants.

Membership

  • Same steps / UI modifications as or Event Registration.

Search and Reporting

Existing search and report filters allow users to filter on Participant and Membership status, and therefore can be used as-is to locate partially paid records. Reports which calculate revenue based on completed contribution summation should continue to provide accurate revenue totals.

Are other changes needed for this phase?

Étiquette
  • Aucun
  1. Dec 12, 2010

    When I first started talking about accounts I was imagining the contributions table represented payments and that we needed an invoices table. The discussion at that time ended up convincing me that contributions better reflected invoices - with the existence of 'pending' contributions a key reason.  If we do go back to that concept we do need an invoices table because of the audit requirement to list sequentially and uniquely all invoices. The thing that I really hope to get out of the initiative is to have a clear representation in CiviCRM of invoices & payments whereby payments and invoices once created / receipted are not changed in CiviCRM (unless the data was inaccurate). So, the thing that causes me problems is that contributions can be cancelled - and there is no distinction between whether they were never paid or were paid and subsequently refunded. If I try to reconcile bank receipts against contributions then both the day (or week or month) when they were receipted and the day on which they were refunded is 'out' and I struggle to re-construct what has happened.

    If we go down this path it would also be necessary to receipt negative payments.

    The tricky one for me, however, is how does this handle when a pay-later donation is paid in installments - ie. if someone commits to pay $500 (recorded as an 'invoice' ) and sends in 2 cheques for $250 ('payments')

  2. Dec 12, 2010

    When a person signs themselves for a paid event or membership in the public part of the website, should they click "Pay Later"  if they cannot pay in full? So then the staff can use the back-office area later on to record the payments for that event?

    What will happen when someone signs up multiple people up for a paid event? Such as when a parent is registering their 3 kids for school? Should the parent choose "pay later" in this case?

  3. Dec 13, 2010

    JoeMurray dit :

    To reiterate differently a few of Eileen's and Sarah's points:

    1. Can you confirm that if there are two $250 payments made for a civicrm_participant record tallying $500, that there will be two civicrm_contribution records created?
    2. Can you confirm that this approach will not handle partial payments for pay later contributions - that is out of scope, and the work-around for that use case for the time being will be to treat it as a pledge?
    3. If a separate initiative aims to support refunds, can you confirm that we could record them with negative amounts in the civicrm_contribution table, at least in theory at this point?
    4. Even if partial payments at time of registration for an event or purchase of a membership are out of scope in the current proposal for 3.4 phase, presumably that could be added later or even now with additional funding.
    1. Dec 13, 2010

      Can you confirm that if there are two $250 payments made for a civicrm_participant record tallying $500, that there will be two civicrm_contribution records created?

      Actually no - I think that's clear - what I'm worried about is contributions since they don't have a separate table and are not always registered as pledges or paid in full. Ideally I would like to see every donation recorded as a pledge record so that there is a record of the obligation that stands separate from the payment (which may or may happen as a single transation and which may or may not result in one or more refund payments)

  4. Dec 13, 2010

    Andrew Perry dit :

    The path I thought we were heading down was to have all payments stored in the financial_trxn table, so that they can be linked to an account_id that represents a "pot of money", such as "Unbanked Money", "PayPal Account", "XYZ Bank Account" (in other words, an Asset).  Among other things, this also facilitate's the Deposit workflow, where a bunch of cheques and cash already recorded as being paid in CiviContribute, are taken from the "Unbanked Money" pot at the end of the day, and deposited as a single financial_trxn to "XYZ Bank Account" (it is this single payment into the bank account and the contributions it relates to that the accountant will be looking for CiviCRM to spit out for her reconciliation).

    The contribution table records the total amount payable (whether paid, pending or part paid) for the particular item (whether Membership/Event/Donation...), in other words the Income, against a contribution_type (which links back to an accounting_code).

    This would simplify integration with accounting packages (on either a cash or accrual basis), because all changes to Income (whether received or not) are stored in one table with a link to an accounting_code (via contribution_type), and all changes to Assets (ie payments received/refunds) are stored in one table with a link to an accounting_code (via account_id).

    To achieve this goal, and the numerous benefits that flow from it, part payments could be achieved using the same UI as proposed above but adding a new Contribution status "Part Paid".  The existing "Pending" Participant/Membership status could be used or an additional "Pending as part paid" status could be added if a reason for the Pending status is needed.

    When the participant registration/membership/contribution is submitted, the full amount would be recorded as a Contribution with status "Part Paid", and the amount of the part payment would be recorded in the financial_trxn table, linked to the contribution through the entity_financial_trxn table.  There would be a default account in "civicrm_financial_account",  as the collecting pot for all offline payments (pending the full implementation of CiviAccounts when a user could select the account to use/rename the accounts).

    For reporting purposes, CiviCRM's reports of Contributions would continue to return the full amount committed to, and could show the status.  In the case of a "Part paid" contribution CiviCRM could report the total paid to date from the payments linked to that contribution in the entity_financial_trxn table.

    In addition to the change to the Event/Membership pages you have flagged, the off-line contribution page could be modified slightly to accommodate part payments also, by moving the Status field up under the Total Amount field, and if the status is Part paid, having a box appear for the "Payment amount".

    To complete any Contribution, instead of having to go searching under the Event/Membership/Contribution tab separately, by centralising all these ideas as unpaid Contributions, you would just go to the Contributions tab and a "Pay" option would be on the right of all Contributions other than those with status "Completed" or "Cancelled".  Clicking Pay would take you to the relevant payment page for the Membership/Event in their case, as you have described above, where another full or part payment could be recorded.

    This would make the workflow easier, so you always go to Contributions to record a payment, with that page directing you off to apply the payment against a Pledge/Membership/Event, rather than having to "Go to contact's Events tab OR use Find Participants to find "Partial paid" record" (although they could still be options).

    1. Dec 15, 2010

      The plan above was an attempt to get Partial Payment functionality within what seemed like a realistic scope of effort / cost for 3.4. I agree that it doesn't move us closer to having separate storage for payments and a single source for obligations.

      For Partial Payments, from a UI point of view the work needed for either approach is similar (and the ability to record additional payments from the Contribution OR the Membership / Participant side makes sense).

      In order to implement Partial Payments while moving to the "separate payments / obligations" model, this is the additional work we think is MINIMALLY needed for "Phase 1":

      • Modify all "payment recording" code to insert a financal_trxn record (currently only done for online payments). Offline payments linked to a default "offline account" entry in civicrm_financial_account. Online payments linked to a default "online account" entry.
      • Modify all functions that return a list of contributions (includes contribution search results, contribution listing on contact tab, contributions displayed when viewing or editing membership, participant:
        • Display 2 columns: Amount Owed (from contribution record) and Amount Paid (sum of associated financial_trxn records).
        • Provide "drill-down" to view "payments" for each contribution record that has financial_trxn records with total <> contribution amount (i.e. amount paid <> amount owed).
      • Extend contribution_search api to return amount owed and amount paid (aggregate from associated financial_trxn table)
      • Develop a new report which displays and totals the financial_trxn records.
      • Upgrade script creates financial_trxn records for all completed contribution records that don't already have one. Link to offline or online financial account as applicable.

      Not covered in the estimate for "Phase 1"

      • Integrating financial trxn (payments) details into the ~10 existing reports which cover contributions (e.g. Contribution Summary, Contribution Detail, Event Income, LYBUNT, Top Donors, etc.)
      • Direct search on financial_trxn entries and export of financial_trxn entries (could be handled by custom search)
      • Other API modifications / additions
      • Anything else not described

      Total effort for Phase 1 Partial Payments using this model: $9,375

  5. Dec 13, 2010

    JoeMurray dit :

    So if the new path for partial payments is for civicrm_contribution to have the role of recording payments (rather than the civicrm_financial_trxn), then a few other things come to mind:

    1. I think I would like to move pay later contributions out of this table, as they are not payments. (BTW, when I recorded a pay later ticket purchase, the pay later value in civicrm_participant was 0, and when I recorded a full payment for it it remained 0.)
    2. For the separate initiative to allow account information to be recorded for all items, we will need to record a received_into_asset_account_id that can handle various payment processor accounts and various accounts for cash and cheques.
    3. For the separate initiative to allow account information to be recorded for all items, we will need to modify how the received_into_income_account_id information is recorded for a variety of objects and amounts, included deductible portions of ticket prices, non-deductible portions of ticket prices, deductible portions of membership fees, non-deductible portions of membership fees, cost of premiums, line items, etc.

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.