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 registants came to the site to register at midnight. We had 42 days to pick a solution, and implement.

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:

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.

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.

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.

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.

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.
 

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!).

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.

At the Developer camps on the 28th and 29th of April, 2009 (ie last week) one of the major tracks for all the breakout sessions was usability. Which is a major theme of the 2.3 version upgrade. In two of the groups I participated in we talked about the usability of the CiviEvent module from a an administrators perspective. One frustration that we decided need addressed was the 5 step wizard to create an event.