OverviewThis 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.
CodeThe 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
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
- 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;
- 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...
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
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
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
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
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