CiviCRM Community Forums (archive)

I have a member org I'm working with that receives a number of renewals (rolling period) via mail, and thus the member record must be added administratively. I ran across this doc in the wiki: http://wiki.civicrm.org/confluence/display/CRM/Test+Plan+-+Membership+Renewal

I'm assuming that was a working document to sketch out the specs for a more functional renewal process? As it stands, the biggest issue is that the person entering data must make note of when the previous member year began and end, and match it up to the new record (since their membership renews continuously, not when they actually make the payment). It also makes the "join date" a questionable field, as it ends up appearing in each record.

Wondering if anyone has created an effective system or workaround, whether that's through staff policy and procedures, or a structure built in CiviCRM.

-Brian

Yes, that issue summarizes things nicely. It also includes the issue where membership records are disconnected from their corresponding contribution record when added through the admin (vs. a frontend user profile form).

I think there would need to be a renewal status definitions page (similar to member status page) that allows the admin to control the business logic for the renewal process. For example, in my case, if someone renews within the 12months after their previous end date, their start date for the new renewal period is the end date for the previous membership record-- in other words we don't start their new period from when they pay, but continue their previous record, if they fall within that 12 month window. After that period, we consider their membership as having lapsed and thus a new membership has begun. But my point is, those settings would need to be configurable for the admin.

My point about the join date is that currently, the join date is connected to each membership record. I think of the join date as the point at which the member first joined the organization, so it seems to me to be previous to, or a hierarchal level above, the series of membership records. Currently, if I manually "renew" a member by adding another membership record to their list, I have to fill in the join date, which doesn't make sense, and will tend to disconnect that value from the previous record history. Which most likely will mean that the join date value for all but the oldest record on file is not very meaningful (especially since I'm unlikely to look up their join date to fill it in correctly on the new record).

Anyway, I'm rambling. And perhaps not making sense. This jira issue sums up the key issues well. And personally, I would elevate above the minor priority status.

Thanks!
Brian