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

This is just a few point form notes, to be fleshed out into more detail. 

 Renewals

 There are three major approaches to renewals that an organization can take if a contact makes an additional contribution partway through their membership

  1. Additional contributions renew the membership:
    1. 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).
    2. 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).
  2. 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:

http://wiki.civicrm.org/confluence/display/CRM/Membership+-+Multiple+type+signup+and+alternate+calculations

 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.
Étiquette
  • Aucun
  1. Feb 05, 2008

    I've done some background on how CiviContribute and CiviMember membership renewal payment process requirements could be enhanced.

    Details here http://wiki.civicrm.org/confluence/display/CRM/CiviContribute+++CiviMember+membership+renewal+payment+process+requirements;

  2. Feb 25, 2008

    JoeMurray dit :

    Not sure how common this use case is, but organizational memberships have a variable cost for some organizations I work with, based either on their membership count or their volume of business. Would be nice to support that.

  3. Mar 03, 2008

    Peter Davis dit :

    In addition to 1 and 2 which are renewals that an organization can take if a contact makes an additional contribution partway through their membership
    are the cases for renewals post End Date. The three cases I see are

    1. renewal needs to simply extend existing dates, therefore new Start Date = Old End Date + 1
    2. renewal needs to kick off from date of payment received
    3. renewal needs to kick off from some other Admin specified date

    If I have it right, at present Civi2.0 does 1/ if in Current or Grace, does 2/ if in Expired (though this is Editable), it does not offer 3/ unless in Expired period

    We have circumstances where 3/ is required (we have a very long grace period and a renewal near the end of that period should trigger a start date part way through the period rather than at the beginning of it. 

  4. Mar 10, 2008

    If a member selects a new member level it is considered a new membership, not a renewal and both are monitored under their member profile. We would like to allow the member to change their level (upgrade or downgrade) when they renew with the original start and end dates.  If they have one $35 membership that expires on 3/15/2008 and they renew with a $50 membership on 2/25/2008 it would be preferred to have the original membership continue rolling with a new end date of 3/15/2009, not a new membership with an end date of 2/24/2008.  Or, the current membership could finish its term and the new membership at the new level could start at the current membership's end date, thus keeping a history of the memberships with the membership levels.

  5. Aug 06, 2009

    EdP dit :

    On the 'types of membership linked to contact types' point - if there is a 'family' membership (using a household as the family) then when it is created you would want to create the family members (or link to existing ones) and extend the benefit of that membership to them all - you might also want to specify a maximum number of adults/children that can be included. For the corporate memberships this may apply to all "employee of" members.

    There is also an age element - many organisations allow 'old age pensioner' or 'veteran' type memberships to those over a certain age and 'child' or 'student' memberships to those under a certain age.

  6. Jul 06, 2010

    Would be great if memberships could be paid in installments. For some organizations the yearly membership fee is over $2,000 USD and many people like to split into smaller payments.  Perhaps the membership signup / renewal could be tied under the hood to a pledge.

    1. Jul 08, 2010

      JoeMurray dit :

      +1 for installments / recurring payments / pledges associated with memberships. Being able to configure some option for split payments scheduled for now and/or later is a common use case.

  7. Mar 20, 2014

    Has there been any work on prorating of payments for fixed members. Members can sign up for membership at any point during the year so that the membership fee owed is only from date (month) of joining to the end of the current year.

    1. Mar 20, 2014

      Not in core. I suspect some folks are doing this using hooks and an extension.


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.