CiviCRM Community Forums (archive)

Hi,

This post is intended to stimulate discussion about the way CiviContribute handles CiviMember sign ups and renewals. While the base functionality exists today to achieve this, it does have some limitations. The plan is to extract the details from this and create an updated “CiviMember - Phase 2 Specifications” page on the wiki. (http://wiki.civicrm.org/confluence/display/CRM/CiviMember+-+Phase+2+Specifications)

Available Membership Types
Typically organisations will run membership based on a level (Bronze, Silver, Gold) or categories (Single, Joint, Household, Probationary, Life, Honorary) or even a combination of both. This creates some challenges when presenting membership options to new and existing users:
      1.   New Members should only be presented with Membership Types which are available to new members
           (eg. Probationary, Probationary Joint, Probationary Household but not Life).
      2.   Current Members should be offered Membership Types at renewal which are applicable to their current
            status. (eg An “Ordinary” member is only offered the option to renew as an “Ordinary” or “Silver”
            member but not as a life member.
      3.   Where a membership is available which covers multiple individuals they should be offered the option
            of purchasing memberships for additional household or family members.

Uplifts to Membership Fees
Where an organisation offers a base membership fee for a Membership Type and uplifts for additional membership items, a method needs to be available to handle this in CiviContribute. For example all Membership Types might offer the contact a magazine, insurance or other feature for an additional fee. Currently these options may be placed in the Contribution Amounts section.

Where the “Separate Membership Payment” setting has been enabled these contributions are added to the Membership Type Fee. However for payment processors that do not support Separate Membership Payment (Google Checkout & PayPal Express) you must also include the Membership Type Fee in the online contribution. This makes the Contribution Amounts section extremely cumbersome.

A summary of requirements is:
      1.   Offer global membership uplifts
      2.   Offer Membership Type specific uplifts
      3.   Provide a method to store which uplifts a user has paid for.
      4.   Allow multiple items to be selected from the Contribution Amounts and total them before presenting for payment.

Another approach to this would be to allow the membership block to offer multiple memberships. For instance as well as standard membership a user could also purchase a membership for the organisation magazine.

Sign up for Multiple Memberships
Contacts should be able to sign up for multiple memberships at the same time either with the same organisation or multiple orgs.

Payment by Cheque & One Click Membership Update
Where cheques are used for payment it would be extremely useful to have a single click membership update which is only available to admins. So for example, the admin receives a cheque from Joe Bloggs for his next years dues. When he looks at Joe’s memberships on the view contact membership summary screen there is an option alongside View | Edit | Delete called Renew. Pressing this will extend the current membership by one term as defined in the membership type rules.

Payment Receipting and Information Flow
Payment details passed to the Payment Processor includes the name of the Contribution Page and amount but not what Contrbution Amounts were selected. If uplifts are offered with the same fees it is not possible to resolve what uplift was selected.

The requirement here is to provide more detailed information:
      1.   When passed to the Payment Processor
      2.   On the confirmation pages and receipts.

It would also be extremely useful if when a Contribution Amount is selected and fully processed that a custom field could be modified. This would require the name of the field to be given and it’s new value.

Payment Record Keeping
Currently the PayPal and Google Checkout IPNs modify the contacts address and contact details. The address info is taken from the payment system and modifies the primary contact info. The address data should be recorded in the billing address and the contacts name be left unchanged. This has been discussed in http://forum.civicrm.org/index.php/topic,532.0.html

Yes, please post this on the wiki, so we remember and take it into account when we upgrade CiviMember in a 2.x release

lobo

I know the dev team have a lot on their plate but how does one go about getting features like the above onto the roadmap? Should I be posting "New Feature" issue in jira?