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

Use-case A: Staff-driven financial activity

The staff decides how much a large group of people are going to pay( such as 500 people need to pay $1200 each for an annual "family" membership;  or 50 kids are being registered for school, and the parents will pay off the tuition over the course of the school year). 

The staff member does a search on this set of contacts, then chooses "Create Membership" from the batch actions select list. The next screen should ask for the membership type, and the current choices shown when creating a batch action membership.  It should also create a financial obligation of $1200 for each contact.  This could be a "pledge" of $1200. The staff member should also select which CiviContribute page should be used for the contacts to make their payments. 

A similar batch action should be "Create Contribution" and "Create Pledge". The actions "Create Membership", "Create Contribution" and "Create Pledge" would not require credit card information, but simply create a pending obligation/pledge for each contact. 

When the contact later logs onto the website, they should have the ability to 1) Pay the full amount 2) set up a schedule, such as monthly payments plus make their first payment, such as just $100 for that month, or 3) set up automated  recurring payments. The automated payments would stop at the end of the year ( or whatever the last day of the membership is )  

If someone falls behind in their membership-related payments, their membership status should be changed to "grace" until they pay what they owe, or the term of membership ends. 

Ideally, the staff member is not responsible for picking the payment schedule. Ideally the member logs into the website, reviews how much they owe and then chooses a payment schedule, and whether or not to set up automated payments for that time-frame. 

 Pay as able:

Some people may choose "no schedule."  Which means they will visit the organization website periodically, review their outstanding balance and make a payment against their obligations.   In this situation the organization sends monthly statements ( I already have custom mail merge tokens that I use to create the statements) to remind people of their outstanding balance.

Use-case B: Contact-driven financial activity

A existing contact or a new contact visits the organization's website. They use a CiviContribute page that is configured for membership signups/renewals.   They choose which membership type they want, then choose the schedule of how they want to pay their member dues.  If they choose a year-long "family" membership for $1200 per year, they can choose to pay the full amount upfront, or break it into monthly payments, quarterly payments, or every 6 months.  They could choose to fully automate the transactions or just get reminders to visit the website and make the payment manually for each transaction 

The same contact may also signup for an event, and is bringing 3 guests. The event pricing may use pricesets or may be simple pricing. They may put an initial deposit, then pay the rest later. Or set up a payment schedule. 

 Pay as able:

Some people may choose "no schedule."  Which means they will visit the organization website periodically, review their outstanding balance and make a payment against their obligations.   In this situation the organization sends monthly statements to remind people of their outstanding balance.

Use Case C: An Automated payment fails

Someone chooses to do fully automated payments. The first 2 payments work correctly.  However, the third payment fails due to the credit card being expired.   In this case, the person should be able to visit the organization's website and make a manual payment or setup recurring payments again with a new credit card for the remainder of the of the membership term. It might be nice to have an option to set a standard charge for NSF checks and for declined payments of other sorts into the system.


Ideally payment options available to staff and public-facing forms offer the same choices/flexibility for pledges, events, and membership activities.  

  • Aucun
  1. Oct 16, 2010

    A common use case my clients experience is with regard to changes in event registration options. Many conferences will use pricesets for multiple fee options, which often include various optional values (meals purchased, special events, etc.). It's not uncommon for a registration to be purchased, but then changes be required. Currently, there's no way to attach multiple contribution records to a single event record, or to alter the event registration fees if the record was made with an online payment.

    Since editing a registration record could just involve data changes to custom or core fields, and not impact the fees selected, I think we may need to distinguish a fee and contribution related change/addition from other basic data changes. Ideally, such fee/contribution changes would retain a history. If someone registers for an event and later needs changes that have financial impact, I would like to see a subrecord that details the original fees+contrib, and the altered fees+contribution.

    The contribution record would also need to support refunds. I think some of the payment processors can now support refunds via API, so ideally the triggering of a change could also handle the transaction piece. But even if the staff person must handle the actual refund elsewhere, it would be important to have a clear method for tracking such transaction via the interface.

    So, the record may be something like:

    Initial event registration + associated contribution
    - Altered fee (subset of registration) + second contribution record connected to initial event registration
    - Second and subsequent alterations

    The schema supports the multiple contributions attached to a single event record -- this is similar to how a membership renewal has a single core record with multiple contributions. I'm not sure the best way to track the changes against the event registration. I'd prefer not to add another table, or to pollute the registration table with the historical information via multiple records (i.e one registration having multiple records, some of which are flagged as changes). If there was a way to have a system-only field that logged the record of changes, and the registration record always displayed the latest settings, I think that would be sufficient.

  2. Nov 06, 2010


    I believe these additional transactions would be called "adjustments" by the bookkeeper. This will also have impact when sending data to QuickBooks or another general ledger program. There would need to be a way to associate the adjustment transaction with the original transaction.

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.