Question about automatic recurring membership

[SarahG (FountainTribe)]

I have a question about the specs for the project at:  http://civicrm.org/index.php?q=civicrm/contribute/transact&reset=1&id=8&widgetID=1  

Would it be possible to use this feature to create a CiviContribute page for a yearly membership costing $4,000 where the new member can choose to pay monthly, quarterly, or some other schedule.

Would this same scenario work in the staff area after clicking "Create Membership"?

The CiviMembership type would be always set up for a period of 1 year. ( usually will be fixed time period )  

[Dave Greenberg]

As currently scoped, this feature would not support partial payments for memberships (as you've described). There's a bit of extra complexity introduced with partial payments - particularly around rules for updating membership status. What should happen to a membership if the person is paying quarterly and the first two payments are completed but then the 3rd payment fails? Do they automatically get set to "Expired", or does the "Grace" rule kick in, or

Possible workaround is to configure the membership types for shorter periods - i.e. if you want to offer monthly payments, set up a membership type with 1 month duration + auto-renew.

Would this same scenario work in the staff area after clicking "Create Membership"?

The auto-renew feature WILL support staff entering an auto-renew membership from "Create Membership" (backoffice screen). We will also support staff entry of a recurring contribution ("Create Contribution").

[SarahG (FountainTribe)]

In the scenario you describe "What should happen to a membership if the person is paying quarterly and the first two payments are completed but then the 3rd payment fails? "

The membership status should be changed to "overdue" or "needs attention". Perhaps this is overkill, as these are really the same thing as a "grace" status.

Then the organization can use the "Administer --> CiviMember --> Membership Status Rules" screen to determine how they want to treat this kind of member.  ( ie do they deny the use of member-only services, or are they still treated as a full member for a grace period, or the office may sit down with the person to work out a new schedule. )

For my clients, the usual approach would be for the membership director to sit down with the person to arrange a new schedule, or simply say to the person please pay your balance as you are able. ( Unfortunately, this is more common with many members being unemployed. )

I have thought about your work-around before. The problem is it creates a huge headaches for the bookkeepers and reporting.  For example: An organization has 10 membership types:  Family 25-29 yrs, Family 30-34 yrs, Family 35-39 yrs, Family 40-44 yrs, Family 45-65 yrs, Single parent, young couple, senior couple, associate member, and student member.  The price for each membership type is a yearly amount, with the year start date tied to the first day of their fiscal year.

Lets say this organization needs to allow 5 different payment schedules: every 2 weeks, monthly, bi-monthly, quarterly and every 6 months.    The workaround would mean there would be 50 different membership types!  Also it would be difficult to tie membership fees to their fiscal year.    

 


A few more questions:

a) Would the "Create Membership" in the staff area be available as a "batch action" on the search results pages?

b) Would the user dashboard allow the member to make an online payment in the situation that their automated payment had failed?

c) Would it be possible to set a monthly membership to auto-renew for 12 months, or some other timeframe? Or would it auto-renew until cancelled?

[Dave Greenberg]

Yes, for failed payments we could probably just assign "Grace" or "Expired" status depending on status rules. That said, there are other implementation issues for partial payments - we'd need to complete the schema modifications proposed by Andrew Perry a while back and modify a fair amount of code to use the new schema / rules. This is a pretty big project, and would require significant sponsorship or code contributions.

A few more questions:

a) Would the "Create Membership" in the staff area be available as a "batch action" on the search results pages?

b) Would the user dashboard allow the member to make an online payment in the situation that their automated payment had failed?

c) Would it be possible to set a monthly membership to auto-renew for 12 months, or some other timeframe? Or would it auto-renew until cancelled?

a) No. We don't have any model yet for batch creation of transactions (memberships or contributions). This would likely need to happen in a "grid" where you could select existing contacts or create new ones and enter payment (cc) info etc.

b) Yes.

c) Auto-renew until cancelled. We'd need to add a new property to the membership table for "Renew Until" - but not sure how much use that would get? Others should chime in.

[SarahG (FountainTribe)]

What I had in mind for batch creation of pledges, contributions and memberships would be similar to the batch "event registration" action. 

For example, create a pledge of $1200 to be paid in monthly installments. Display all the choices that are shown when creating a single pledge, just apply it for the entire set of contacts.

For contributions:  Ask the staff what the amount should be, the contribution type, the source, the date, ( everything that is asked when creating a single contribution, but do not ask for credit card info.   Then create a contribution of status "pending" for each contact.

The use-case is the staff decides how much a large group of people are going to pay( such as 500 people need to pay $1200 ).  The people impacted are mailed ( snail mail and/or email ) a monthly invoice, which they can choose to send in a check, or pay online.  ( The invoices are generated from CiviCRM )

I am currently handling this as pledges, with the contribution type set as "member dues"

[Dave Greenberg]

The use-case is the staff decides how much a large group of people are going to pay( such as 500 people need to pay $1200 ).  The people impacted are mailed ( snail mail and/or email ) a monthly invoice, which they can choose to send in a check, or pay online.  ( The invoices are generated from CiviCRM )

Wondering if others have similar use cases. Previously the primary batch input use cases have more like this....

"I've got a pile of contribution checks on my desk that I need to record and deposit at the bank. I want to enter an expected batch total and have an easy way to input the contribution info. At the end I want the system to verify the total amount for contributions entered against the expected batch total."

[SarahG (FountainTribe)]

I have summarized the use cases I want to sponsor at:

http://wiki.civicrm.org/confluence/display/CRMDOC32/Recurring-Partial+Payments+for+Membership+Specification

Could this be folded in to the existing specification for the Civi-Make-It-Happen recurring memberships campaign? Or would it be better to treat this as a separate project?

[Eileen]

Hi, Just looking at this and thinking about it in terms of our previous discussions about accounts integrations & how it would apply to events when we get to having part-payments for them..

There are two ways in which recurring payments are handled in accounts and I think these are worth bearing in mind. They are either managed by a single invoice which is paid off over time according to a plan or as a series of regular invoices (as recurring contributions are done).

I think we had more or less concluded that invoices were represented in CiviCRM as contributions - in which case the memberships would be represented by a single contribution record & a series of financial_transactions which could be totalled to give a portion of the amount paid so far. You almost need the ability to compare that percentage with the amount that would have been paid by that date according to the payment plan and set rules based on the percentage

[Dave Greenberg]

I have summarized the use cases I want to sponsor at:

http://wiki.civicrm.org/confluence/display/CRMDOC32/Recurring-Partial+Payments+for+Membership+Specification

Could this be folded in to the existing specification for the Civi-Make-It-Happen recurring memberships campaign? Or would it be better to treat this as a separate project?

I think this needs to be a separate project since the buik of the work is figuring out and implementing the right model for partial payments towards a membership (or an event registration).

[SarahG (FountainTribe)]

I updated the wiki spec with better definition of accounting terms used.

Can a new "Civi-Make-it-happen" campaign be launched to fund this, ie partial payments for membership and events, with an effort to pave the road for Quick Books integration?

The wiki page is now at:
http://wiki.civicrm.org/confluence/display/CRMDOC32/Partial+Payments+for+Membership,+Events

[Dave Greenberg]

Sarah - We'll look at launching the new Make it Happens after the deadline for 3.3 (Oct 15). You can grab Eileen on IRC or email to get it going then!