14 April, 2010
By hershel
Filed under CiviEvent, CiviCRM, Drupal


This is a brief introduction to how CiviCRM can be used for ticketing and attendance purposes, via custom Drupal modules. The concept is to provide printable tickets for event registrants, and to put a unique UPC code on each ticket; then at the event itself, to provide a way for the event management staff to scan the UPC codes and easily take attendance using those codes. Such a system is in place on one site and has been used successfully.


The flow of the code is to capture event registrations using hook_civicrm_post and then, in that function, send an email to the new registrant with a link to download his PDF ticket. The PDF ticket is generated using the TCPDF PHP class. This class is used by the Printer-friendly, e-mail and PDF versions module, but for the purposes of creating tickets we needed a custom solution. The content of the tickets is not a node--it's content... Read more
09 March, 2010
By AkronAA
Filed under CiviEvent, v3.1, CiviCRM

Every year in June, around the 10th day, a commemorative event happens in Akron, Ohio - the annual celebration of the founding of Alcoholics Anonymous. Hosted at the University of Akron, over 10,000 participants from around the world gather to celebrate the founding of this wonderful fellowship. In recent years, registration for this all weekend event has moved from mail-in forms to an online registration process. Online registration challenges from the past few years had made us seek a solution to that could handle a surge of registrations in the first 24 hours, and collect all the necessary information required by the University.

In past years, Zen Cart could handle our registrations - it may have even been able to handle it this year, except we needed to collect more infomation than in years' past, and we wanted to still be able to allow multiple registrations per transaction. One serious issue from last year was the server became overloaded as thousands of...

Read more
05 August, 2009
By andrew
This post started out as a reply to Eileen's "Banking Screen?" comment on my previous post on this topic, but by the time I was done, I thought that this warranted its own post. I think that the core "Accounts" or "Banking" functionality that could be helpful to Civi users without getting too out of control, is:
  1. generate a listing of the individual cheque and cash "receipts" processed since the last "deposit" was generated, add selected receipts to a deposit and print it as a deposit listing, using a template that would enable you to submit the listing to your bank with a deposit slip;
  2. enable a bank reconciliation to confirm that each deposit was successful and highlight any discrepancies such as bounced cheques or typo's when entering cash or cheque amounts. Ideally you would be able to tick off each receipt within a deposit as reconciled (or just tick the deposit as a whole and have the system mark each receipt within that deposit as reconciled). If a...
Read more
04 August, 2009
By andrew

We are finding that CiviCRM/accounts issues are becoming increasingly important for our clients, and Eileen's recent blogs and the discussion they are generating are a fantastic step towards helping find the best way for Civi to deal with financial transactions.

For example, I think it could be useful for Civi to ultimately develop functionality for maintaining simple bank accounts within CiviCRM, so that small organisations can maintain basic accounts without the headaches of integration with an external package.

Currently we have clients who are willing to rely on CiviCRM as being the central repository for the detail of all contributions, with a lump sum figure hitting their GL at the end of each month which can be reconciled against CiviCRM's records. This is largely reliant on the organisation having very good procedures in place to attend to banking on the same day as transactions are entered into CiviCRM, to make it easier for payments to be reconciled. It...

Read more
03 August, 2009
By Eileen

This is my second blog on the topic of integrating with CiviCRM with an accounting system. Those of you who haven't just run screaming from the room or suddenly discovered an urgent need to polish the inside of your car exhaust, re-organise your tupperware or push needles into your eyes ... read on.

I was going to talk now about the second (conceptual) stage of Xero / CiviCRM integration - getting payment information out of Xero to confirm transactions in CiviCRM, but, some of the scenarios that are difficult to get my head around in automated integration are also the same scenarios that cause me problems under 'manual' integraion, so I'm going to focus for this blog on 'manual' integration between CiviCRM and Accounting systems. This also ties in with a suggestion from Dave that I specify possible future changes to the workflows around receipting multiple payments against events.

Manual integration is an over-jargony way of describing a person...

Read more
01 August, 2009
By Eileen

One of the areas that occasionally hits the forums is whether CiviCRM integrates with accounting systems. I've been giving a little thought to accounts integration lately and have now spent a bit of time poking around the Xero API and thinking about what I would do if I were to spent time trying to get CiviCRM talking to Xero. The content of this blog is mostly non-technical so if you can safely ignore the stuff about APIs if it doesn't mean anything to you.

For those (most) of you that haven't heard of Xero, it is the company that would have made me rich had I bought shares when I said I thought I should. If I had also bought oodles of US dollars at the same time and sold them 3 months ago I would now be sitting on a tropical island instead of writing this. Such things aside, Xero is an online accounting package with a RESTFUL interface which targets small to medium businesses and organisations and is aiming for World Domination. I believe they will fail...

Read more
07 July, 2009
Filed under CiviEvent

We want the ability to sell tickets. CiviCRM has a maximum participants feature but this applies to the whole event. We want it to apply to each individual ticket. This will be particularly useful when related to a floor plan which can be uploaded.

In the Price Sets. In the Page Edit a price set. Next to Price will be another column called "Number" (people can suggest something better) where the number of tickets can be set. I thought this should not be in "Edit price numbers" so that different groups could still pay different amount but would deduct from the remaining tickets.

- All the current features that apply to "Maxiumum number of participants" should apply to tickets. Don't know exactly what that is. But obviously that means a ticket should count as "Sold out" and not be selectable for a user. If there are waiting list features this should apply to individual tickets, not whole events. Refunds and cancellations should apply to individual tickets not events....

Read more
06 July, 2009
Version 2.2.7 was released today with CiviReport ("the return") phase 1. This version includes fourteen report templates with coverage for contact data, activities, contributions, events and memberships. Folks in the community who have had a chance to preview the functionality have been quite excited - and we think this is a significant step forward for CiviCRM. First, a few concepts... CiviReport is delivered with a set of report templates. Each template covers a general reporting area - for example: Donor Report (Summary), LYBUNT (Last Year but not this Year), etc. Administrators can then create one or more report instances from a template - with specific display columns, filters and grouping rules. Users go to the CiviReport menu to see a list of report instances, and run the reports.   For example, your organization might need a report which summarizes donations year-to-date grouped by Country. You create this instance from the... Read more
16 June, 2009
By shot
Filed under CiviEvent, v2.3, CiviCRM

As mentioned previously, we’re introducing quite a few new CiviEvent features in CiviCRM 2.3. Most of them are still undergoing our internal CiviCRM QA cycle, but do check them out at our CiviCRM 2.3 sandbox if you’re interested (there is still time for some minor fixes to accommodate your use-cases!).


CiviCRM 2.3 introduces the concept of wait lists, where participants who registered after a given event was full are placed. These participants are informed before their initial registration that the event is full, and if they continue their registration process, they are put on a waitlist. Once the event gets some free spaces (because some other participations expire, or participants cancel their participation, or are removed by an admin, or the event gets more spaces…), a cronjob-based script makes sure that the participants from the top of the waitlist (first-registered-first) are moved to pending...

Read more
13 May, 2009
By jalama
Filed under CiviEvent, v2.3, CiviCRM, Drupal

With CiviCRM 2.2.3 and a patch to the Drupal Date API CiviCRM will be adding integration with one more Drupal Module, Calendar. This means you will be able to display CiviCRM events in Drupal calendars and decide what events are displayed by using Views filters in the same manner as you would any View.

As with the Calendar module in Drupal the same dependencies exist meaning the latest version of the following modules must be installed; Views, Date API and Calendar. Once you install CiviCRM and the other modules a disabled CiviCRM events view, formatted as a calendar, will be available under Site Building | Views. You will need to enable this calendar, at which point a calendar will be available at http://www.example.com/events. As with the Calendar module the best practice is to clone the default CiviCRM events calendar in order to create any custom Calendars, be...

Read more