With the D7UC Initiative gaining steam and excepting brainstorming ideas, I figured it was a good time to map out my idea for Ubercart and CiviCRM integration. I realize that many may cringe at the mention of uniting these two applications, for all their complexities, yet I see it as critically important for many non profit organizations, and I’ll explain why.
Many organizations that I have worked with want to take in money in two ways via the web:
- Accepting Donations or Memberships
- Selling stuff: tickets to events, reports, workshops, classes, books, etc…
Nonprofit organizations have reporting requirements (internal and often external) as well as data management requirements. Put simply they want to know who gave them how much money, for what, and when, so that they can ask again.
CiviCRM is great at the first: accepting donations and membership payments. It does all of the automated receipt sending and reminder emails that you would expect. It can even do “premiums” (special gifts) based on donation thresholds and write receipts for the tax deductible portions. It is really great. CiviCRM can also sell tickets to events, however it really is designed for events, not necessarily classes, courses, workshops, etc… or events with fixed seating (think theater performances). Lastly, CiviCRM is not setup to sell physical products or downloads in any way other than as premiums for donations.
CiviCRM also brings with it CiviMail, a pretty robust mass mailer, and some good reporting features.
Ubercart is great at selling physical things, decent at selling digital things, and hopefully will get better at selling temporal things (classes, workshops and events). Ubercart2.x is not very good at reporting, and there is really no good way to browse your customers or do things like email customers who haven’t placed an order in a while with a coupon for their next order.
Right now if you were to install CiviCRM for donation and member management, and maybe major event registration, and Ubercart for selling book, reports, and swag you would have two completely different systems. The checkout processes would be completely separate. A user would not be able to become a member and buy a shirt at the same time. Their customer data would be separate from their member data. It really is quite a mess. There is the UC CiviCRM Integration Module, by the folks at DharmaTech which is being updated to work with UberCart 2.x and CiviCRM 3.x, but that merely pushes Ubercart Customer data into CiviCRM along with pushing the order into a CiviCRM activity record. No small feat. And this would let the organization run a search and email people who had or had not ordered something in some period of time.
What UC CiviCRM integration module does not do is fully integrate the addressbook so that a user’s CiviCRM locations are used as their addresses. It does not update Ubercart addresses if a change is made to the CiviCRM address record (billing or shipping of a user), and it does not let you expose custom fields, or even standard CiviCRM fields to the Ubercart Checkout process. AJ Roach wrote a module for one of our clients called UC CiviCRM Profile Pane which does allow you to expose a CiviCRM profile with custom data fields on the Ubercart Checkout process. Read more about it in his blog post.
Alas, this is all with Drupal 6 and Ubercart 2.0. And I’m now looking forward to UberCore for Drupal 7, where hopefully we will have a more sensible and coherent architecture for integration. Here I will outline the functionality that I believe can and should be integrated (with contributed modules of course.)
Address Storage and Recall
Ubercart needs to know your billing and in some cases your shipping address. I presume there are good reasons for Ubercart needing to know the exact address at the time your ordered, and to maintain that address historically (in the event a shipment doesn’t get where it was going, for example). However, I believe that there is a much more powerful way of doing the addressing in Ubercart. I would like to see the address book system made more extensible, probably through an API, so that various addressing systems could be plugged in, namely CiviCRM, but also the User Location Module.
CiviCRM is a fantastic address book. It can maintain multiple addresses for each contact, for example: Billing, Shipping, Home, Office, etc… CiviCRM also can maintain relationships between contacts. With this functionality, I could, in theory, order a gift that I want to send to my father. When I add the shipping address for him, a new contact is recorded in CiviCRM (if he does not exist there yet), and a relationship is formed between my contact and his. When I place subsequent orders I would be able to select his shipping address, or that of any other contact with whom I have a certain specified relationship (“purchaser for :: recipient from” for example).
UberCart could still record the actual address used on the order for posterity’s sake.
To be clear, I am not suggesting the CiviCRM become a requirement for Ubercart, but that Ubercart’s addressing system become flexible enough that CiviCRM could be used if desired, in conjunction with a module that does the connecting (call it uc_civicrm_addressbook for example).
Order History
To allow for CiviCRM queries, reports and smart groups based on order history, Ubercart orders should be recorded into CiviCRM’s activity records. This is a major component of the functionality provided by UC CiviCRM integration. I believe that this piece of functionality should reside in its own module that simply manages how orders are recorded as activities, providing options for recording the full order as an activity, or recording the purchase of individual items as an activity. As the concept of “products” changes in D7UC, I could see different product types having their own protocol for being recorded as activities: physical products like shirts, books, etc… would be recorded as an order, but course registrations or event ticket sales could be recorded a an even activity, individually.
CiviCRM Standard and Custom Field Data Collection
This was the idea behind AJ’s UC CiviCRM Profile Pane module, however due to certain limitations in the way UberCart2.0 works, this module only allows you to expose fields that are not standard location fields, which are collected by UberCart and stored in CiviCRM.
Ideally if you were using the UC CiviCRM address book module described above, you would have the option to select a CiviCRM profile to be used for address collection, and any other CiviCRM profile(s) you wanted to use in the checkout process to collect additional information via this module, and put them into a different checkout pane.
Cart and Payment Processing
This is the bonus, and I’ll be honest, I haven’t thought as much about it as the other three parts above which solve many but not all of the challenges I outlined above. The last big one remaining is the cart and payment processing. Even with everything above, buying a membership from CiviCRM and buying a product from UberCart would be two separate actions, which is certainly sub-optimal from a user experience point of view.
It is hard, especially with the still emerging proposed changes of UberCore, to imagine the solution. Perhaps CiviCRM could become an Ubercart Payment Processor? Or maybe UberCore’s payment system becomes a payment processor for CiviCRM? Maybe CiviCRM objects that get “sold” can be placed in UberCore’s shopping cart? Or the other way around, the UberCart order becomes part of the CiviCRM transaction.
These are certainly sticky questions. I hope that this post can stir some interest and ideas about this last step.
I don’t believe that the integration of payment processing AND shopping cart functionality is 100% necessary out of the gate, however I do believe that it would go a long way toward making the shopping and donating/joining experiences of these two application much easier and more seamless for the end user.
A Note on Reporting and P2P Selling
During the Pacific Northwest Drupal Summit session I hosted with Ryan Szrama from Ubercart, Ryan mentioned improved support for “marketplace” functionality, or P2P selling where users can upload their own items to sell to other users. CiviCRM could provide a data storage and reporting option for this sort of functionality that would give sellers access to their customers specifically (via relationships and ACLs), as well as detailed reporting on sales statistics. Just a thought.
Please note due to spam issues our comments functionality is currently disabled: you can post a comment, but you can’t see it. We will be fixing this shortly. Feel free to continue the discussion over on D7UC.org.
Recent Comments