A member sends several separate payments to cover outstanding dues on a single purchase, like an expensive membership or a table at an event. How are you going to record this?
A conference participant selects “Pay Later” on several different event registrations, and later wants to pay them all in a single credit card transaction. How are you going to support this?
Current versions of CiviCRM don't offer a way to record multiple payments against a single obligation, or to split one payment among multiple obligations, but the CiviAccounts project is working to allow this flexibility. Work on data structure improvements has been going on for some time; it's part of a broad effort to help CiviCRM's financial data to be more compatible with QuickBooks and other accounting software packages, and it lays the groundwork for lots of possibilities, including more flexible payment processing.
Over at the CiviAccounts “Flexibile User Payments” wiki page, we're discussing UI improvements for both end-users/constituents and staff/back-office users.
If your clients or your organization have a use for these features, please chime in and voice your opinion on ways to improve what we're proposing.
Areas of improvement:
1. Configuration:
Any contribution page or event registration page can be configured to allow partial payment. This replaces the current “Pay Later” option, basically allowing configuration of a minimum initial payment, down to $0.00. If partial payments are not allowed, the user will need to pay the full amount upon submitting the contribution/registration.
2. Submitting partial payments in the back-office forms:
When staff record a new event registration / membership / contribution, they'll be able to record a partial initial payment, and then later record subsequent payments until the total amount has been paid. We're debating the notion of using one form for the initial record and for subsequent payments, vs. using an entirely separate interface for applying subsequent payments to outstanding obligations.
3. Splitting payments among multiple unpaid contributions, in the back-office:
Any time staff record a payment received in the back-office, they'll have the option of applying it to one or more outstanding obligations, such as partially paid memberships or event registrations.
4. For the end-user, paying down my unpaid contributions:
The end-user needs a way to see her own unpaid obligations, and then to submit payment against one or more of them. We're proposing to add a new “My unpaid contributions” section to the user dashboard, listing all the contributions where the total paid amount is less than the total contribution amount. From this section, the user can select any one item to pay, or can select a link to make one online payment that will be split among multiple items.
Some ideas you may want to opine upon:
-
How important is it to support a configuration option to enable/disable these features sitewide, so as to simplify the workflow for organizations that don't need them? And would such a configuration default to enabling or disabling these features?
-
Is it better to have one form for back-office staff to enter both new payments and payments against outstanding obligations (namely, the “New/Edit Contribution” form), or instead to add an additional form dedicated to applying payments against outstanding obligations?
-
Naturally, all the stuff we may have forgotten, especially if you have specific use cases that will not be well covered by these changes.
The CiviAccounts Flexible User Payments wiki page is waiting for your visit. Please give it a moment and let us know (prefereably in the wiki comments, or else on this blog page) how well these changes meet your needs.
Comments
Not sure if these changes will handle this, but thought I'd bring up the case where on the screen to pay event fees we also want to add a field for "Donate ____ to the scholarship fund to help others who can't afford the fees"
I think this is a pretty common thing for nonprofits to do, but so far I haven't found a way to do it in CiviCRM.
This is a feature that my client would like too. Currently, we re-direct them on the thank you page to the donation page.
While the suggested option above is definitely a way to take in the funds at the same time as the event transaction, the drawback is really from a database integrity and reporting standpoint. Donations need to be handled separately from other types of transactions like ticketed events due to IRS reporting regs so you'd end up with 1 contribution record with all of the monies co-mingled, the contribution type for the transaction would be event fees and not donations and the detail of the split would be saved in a text field (fee_level) in the event_participant table. In addition, this donation should be coded as solicited thru the event which for all other types of donations is controlled at the contribution page level.
So ideally, for the registrant it would function as simply as the price set idea above but on the back-end it would need to do the following:
1. Split the payment transaction into 2 types of payments and record the fact that they were originally paid via 1 payment method (credit card or check) and that they were split between an event registration and a contribution form.
2. You might have to create a contribution form entitled, "Donations via an Event" so you'd have a contribution page id value to store in the contribution record.
3. If you could do this, then a report run from the civicrm_contribution table by contribution type would report monies raised via donation forms and via events accurately.
From the fundraiser's perspective, I think they will be happy as long as they can easily and accurately report:
a. The payment method of the entire transaction and the fact that it was made via a single credit card or check.
b. The fact that the donation was made via a specific event registration.
c. What monies are event fees and what monies are donations.
When I converted my client to CiviCRM, I took the historical donations which were made as a result of an event registration and mapped the event name into the source field of the contribution record. This way we can always tell what event raised the most donations. In the future, I'd like this to be validated table field for event registration form much like the drop down field you have added for contribution form.
Anyway, some food for thought on a beautiful day in Hoboken. I will comment on the overall multiple payments topic on the wiki.