Quantcast
Channel: Finance and Accounting
Viewing all articles
Browse latest Browse all 48

Recording multiple payments on one contribution, and dividing one payment among multiple contributions

$
0
0

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:

  1. 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?

  2. 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?

  3. 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.


Viewing all articles
Browse latest Browse all 48

Trending Articles