This is just a few point form notes, to be fleshed out into more detail.
There are three major approaches to renewals that an organization can take if a contact makes an additional contribution partway through their membership
- Additional contributions renew the membership:
- The contribution should renew and extend her membership by the 1 full term (ex. The contact purchases a 1 year membership in Jan 2007. 6 months later (July 2007) she makes an additional contribution. The membership should be renewed. This pushes the membership end date to Jan 2009).
- The contribution should renew and extend her membership by the 1 term from the renewal date (ex. The contact purchases a 1 year membership in Jan 2007. 6 months later (July 2007) she makes an additional contribution. The membership should be renewed. This pushes the membership end date to July 2008).
- The contribution should upgrade the membership to the next level. (ex. The contact purchases a 1 year basic membership in Jan 2007. 6 months later (July 2007) she makes an additional contribution. Her membership level is bumped to the "gold" level and her membership end date remains Jan 2008). These are often referred to as support levels or contribution levels instead of memberships. Organizations often see this approach as highly beneficial if they can then renew the member at the higher level come next year. Often all contributions, donations and membership purchases combine to set the contact's support level.
CiviContribute 1.7 currently supports option 1.2 (mostly. I think there's a bug in the queue which will make this work). To make the later happen we need 2 improvements:
- A setting to define what contribution types (if any) combine to set the contact's membership type (support level).
- A mechanism to define the upgrade path for membership types (support level) ex. Bronze (min $0) can be upgraded to Silver (min $100) can be upgraded to Gold (min $500).
- modifying the cron job to do the heavy lifting.
Here are some additional specs/ideas on the renewal issue:
Recurring membership renewals
For organizations taking Renewal approach #1 as described above with a short term membership. It is desirable to have these membership auto-renew. In 1.7 this functionality exists in civicontribute and just needs to be copied to civimember.
Membership Type Defined/Restricted based on Contact Type
Currently, a membership type may be applied to any contact type, without restriction. In many cases a single membership type is actually intended for a specific contact type, and cannot/should not be applied to other contact types. For example, an organization may have an organization-based structure in which all memberships flow through the organization and individuals (employees) are subsumed under the parent organization's membership. While the current relationship type feature in the membership type definition allows the membership status to be passed from the parent org to the child individual contact, it is still *possible* to independently assign that membership to an individual. In other words, nothing restricts that particular membership type to its corresponding contact type.
It would be useful to have the ability to restrict membership types, similar to the functionality and flexibility currently provided in the custom data group definition. In some cases, the membership type may have no restriction (applied to all contact types), but in other cases, it would be applied to organizations, individuals, or households, specifically and exclusively.
This restriction would be apparent when applying a membership to an org/indiv/household in the contact administrator membership tab. Only those membership types that apply to the contact type would be visible. It would also impact membership types available when profiles are exposed to the front end.
Additional feature requests
- Proration option for fixed period membership. Example: If I signup in June for a calendar year membership, my membership fee is 50% of the full fee.
- Display most recent membership-linked payment on CiviMember summary table.