One of the 'features' of CiviCRM that has been an ongoing source of contention among our customers has been what happens when expired memberships are renewed. The current behaviour is that the existing expired membership has it's end date extended and the start date is altered to reflect the start of the latest membership period. This is great for figuring out when someone first became a member way back when. But, it makes it very hard to see breaks in their membership.
We find some organisations don't want expired relationships to be renewable and recently tackled creating an extension to create a new membership rather than alter an existing one if the end date was being extended. This threw up a few challenges - in particular the hook system really didn't offer the ability to remove or alter the id in the pre hook - in order to prevent the existing membership from being altered. We put in a short-medium term fix via https://issues.civicrm.org/jira/browse/CRM-15749 which will push the problem out for another year but I'm not sure the issue around whether to renew expired memberships can be resolved in an extension.
In terms of fixing this in core the approach I recommend is adding a field 'Is renewable' to the membership status table and allowing that to dictate the behaviour on renewal. My guess is that this is in theory simple but there may be a few places in the code to find and fix to do this. The customer was interested in contributing towards a fix in core (but not fully funding one). I'm certainly interested in hearing if others are interested in collaborating on a fix on this.
Another approach might be to keep existing membership behaviour but make the membership log table work a whole lot hard in terms of displaying history. I'm not sure I see an easy path on that approach though.
The extension is here https://github.com/eileenmcnaughton/nz.co.fuzion.membershiprenewalcontrol - it's not in a 'plug and play' state and at this stage it's not clear which versions of CiviCRM it will work on (we are running CRM-15749 as a patch on 4.4)
Comments
+1 (can I +10?)
I totally agree that the standard behavior is not ideal for many orgs, and it would be ideal if we could configure the behavior within the membership type configuration.
Personally, I think this should be handled with the membership records, not the membership history table. If a contact has no current membership (as determined by the "current membership" flag in the membership status rules definition), then we should create a new membership and leave the existing record intact. This preserves the "break" and allows staff to easily see where a person's membership lapsed and when they rejoined. And it makes the important distinction between "renewing" and "rejoining."
The purpose of the grace period status should be to give the member wiggle room for when their transaction is considered a renewal vs rejoining after expiration.
I don't have clients off the top of my head that would help sponsor, but I'll ask around and see if I can find any. I would be willing to help contribute some of my own time to help with the project though.
I did suggest to our customer that the 'is_current' field should be used to determine whether a status is renewable but they had a use case where they would want a discrepancy between 'is_curren't & 'is_renewable' - I didn't attempt to understand it I just accepted that 'if someone can come up with a situation where this is wrong then it would be better to separate them'. Also, I think it's easier to introduce a new field in terms of allowing people to keep current behaviour if they want to.
I might be able to get a small sponsorship on this. However, I think that maybe what's needed is a big rethink on how membership data is represented altogether. For instance, with the idea Eileen's suggesting, what would happen if you had a scheduled reminder to "Renew Your Membership!" that fired two weeks after the membership's end date? It would fire against the original membership record, even though it had been renewed. I encounter this with a client who creates a new membership record as a workaround for CRM-9128.
I like the idea of making the membership_history table work harder, but as Eileen points out, that's a lot of work to implement.
+1
Very good idea! I know that Bjorn from Systopia is also doing some work on renewing memberships and linking them to recurring contributions. So I think it would be helpful if you get in contact with Bjorn so you wouldn't do the same thing as he is working on.
I have a feeling there might be some fixes in core around renewing memberships associated with recurring - not sure which versions - but there was a problem with the membership_payment records not being created which had a bunch of implications
This issue is important for us too. Although we haven't had serious complaints about it, the loss of membership "continuity" detail was a disappointment when we launched Civi for our organization. Previously, our database had a membership item for each annual membership period. So the membership history might look something like this:
2005
2006
2009
2010
2011
2013
2015
And I think we would prefer it to continue to work that way if we had our druthers. There is a bunch of stuff that Civi does MUCH better than our previous system however, so we can work with it the way it is.
We have a pending request from our membership director to alter a related aspect to Civi, and that is the rollover behaviour. Civi is awesome in that, at a certain point in the year, you can configure it to apply a new membership to the forthcoming year. Our fixed membership year is Jan 1 to Dec 31, and have always started our renewal campaign on Oct 1. So Civi nicely allows renewals on (say) Oct 10 to apply to the following Jan 1/Dec 31 year, while making the member "current" for the remainder of the previous year if they weren't already. Perfect. Except that we have members who get confused that in those circumstances, the "start date" is the previous Jan 31. For example, a lapsed member renews on Oct 10 2014 for the Jan 1 2015 to Dec 31 2015 membership year, and their Start Date says Jan 1 2014. As a professional society, many members can have their memberships reimbursed by their employers, but the employers are saying "no" because it appears they did not renew timely enough since it appears the membership is actually for the 2014 year. The membership director has requested that in those cases that the start date is set to the date of the renewal, not Jan 1. In the example above, the Start Date would be Oct 10 2014 and the End Date Dec 31 2015. We have not yet investigated what the repurcussions of this will be in Civi.
This raises one concern for me, that is, how it could complicate reporting of membership sign ups vs renewals.
The only reliable way I've found to track renewals in CiviCRM is using an activity search. Correct me if I'm wrong, but this will report more subscriptions as sign-ups and less as renewals. Just something to consider.