Gift Subscriptions & profiles for ‘In Honor Of’

Published
2012-08-28 01:23
Written by

A few months Back John Derry from The Monthly Magazine wrote a blog about how they were planning to use CiviCRM for magazine subscriptions.

One of the biggest challenges faced by the Monthly was that it was essential for them to be able to process memberships / subscriptions paid for as a gift. They needed to collect details for both the giver and the recipient.

After some discussions with Dave we settled on the data model of putting the contribution against the giver and the membership against the recipient. The two transactions have an extra linkage in that the contribution record stores the recipient in the honor_contact_id field. As a result of this the contribution is visible on the recipient’s contribution tab. (we also did a template tweak to show the given membership on the giver's membership tab)

There are two main ways in which Gift Memberships are processed – back office and through The Monthly Magazine Subscription page.  

 

Back Office

The Monthly paid for us to add the extra functionality to receipt payment from a different contact into 4.2. As 4.2 has only just come out and the system went live in July we had to develop this for both 4.1 and 4.2, which we found quite difficult. However, we realised it was important to do this to ensure that it would work into the future. The UI in 4.2 looks like this.

Back office gift membership

Front End

There are 2 parts to the front end implementation

1)  When someone pays from the Front End we needed them to be able to specify that they were paying for someone else and to assign the membership to them. As with the back end we used the honor contact mechanism for recording this – however, we use a custom module to grab and switch the membership to the correct contact when it is being saved.

2)      We needed to record more fields about the honor contact than were provided in the built in form.  i.e. we needed to use a profile to gather honor contact fields.

Front end gift membership

 

Both of these are managed through a custom module. The more complex part was the second – getting the extra fields showing to gather honor contact details. We did this primarily by extracting the portion of the Profile Code that dealt with rendering the profile fields into a new php class (ProfileContact) within our module & assigning it onto the contribution page using the buildForm hook.  Of course we had to use the dreaded tpl over-ride to make it display.

None of this front-end work is ready to directly put back into Core but it was written with the expectation that eventually we would find a way to merge it back in. It would also work to present a soft credit contact profile if the decision is made to merge honour contact & soft credit.

The one item that is currently hard-coded is the profile id number. Unfortunately, in terms of getting code back into core, the system around defining that id is likely to be relatively complex.

So, can you use this code?

Yes – we are using this on 4.1. You need the gift memberships module & probably to be using our deployment of https://github.com/fuzionnz/civicrm (branch 6.x.1.x or 7.x.1.x) which includes the back office membership and a hack which we recently discovered the need for … https://github.com/fuzionnz/civicrm/commit/23eb7e0f0b61188984564a36bde756d2eaaf3868

You need to set up the honor contact profile & hard code the profile ID into the giftmemberships.module  file

Going Forwards

We’d like to see the ability to present a profile for honor contacts built into Core. There has been some discussion about merging the ‘honor contact’ and ‘soft credit’ functionality. I think the solution we are working with would be fairly easy to adapt to soft credit instead of honor contact if the soft credit code adopts the existing honor contact front end and back office functionality. However, being able to use a profile to gather information is important here. I would also be interested in looking at receipting from alternative payees for events.

Other features / requirements

There were a few other features / details we worked on for this deployment

-          Extending the membership report to contain a bunch of other details about the honor contact

-          Adding the ability to add either of the contacts from the above report to a group (http://issues.civicrm.org/jira/browse/CRM-10661 is part of this)

-          Figuring out how to represent Aussie GST in Smarty (   {math equation="( $amount / 11 )" format="%.2f"|crmMoney}  )

 

http://wiki.civicrm.org/confluence/display/CRM/Making+Gift+Memberships+a+Standard+Feature

 

 

image001.jpg15.71 KB
image002.jpg15.87 KB
Filed under

Comments

Eileen,  thanks for sharing.  

One of the things we've struggled with on simliar profile extensions is matching/over writing contact information of the person receiving the gift.  Once a match is made it seems that the giftee's contact information can be over unintentionally over-written.  How do you recomend dealing with that or am I missing something?  

We've considered only creating  a new address type - to ensure home/primary address is not over written, not updating information, only including custom data from a membership custom data set...

Thanks