For the past several months, my team at the Alliance for Catholic Education at the University of Notre Dame have been working on developing a mobile client for CiviCRM. It is now hosted on GitHub HERE.
So what exactly does it do, and what is its purpose? We know that with the increasingly mobile world, client relations need to be accessible on-the-go. This is the main motivation behind the work we've done with our CiviCRM Mobile Client (not to be confused with CiviMobile). We have a demo running HERE. Right now the client has functionality for viewing, searching, editing, and adding contacts with basic fields, notes and relationships (we have organizations, activities and tasks, also in the works but they’re a little buggy right now). We use the Client exclusively with Joomla right now and are very pleased with how it is developing.
Work on Project60 continues in the limelight. SEPA Direct Debit processing is alive and kicking, and we've just completed a first demo run of CiviBanking integrated with the Belgian bank format (CODA) importer. 261 files containing 1600+ transactions, running through an initial set of matching rules, good for an 80% hit rate ... not bad at all. Considering that the entire matching process takes about 2 minutes to complete, and only 320 transactions need a human intervention, this is promising news !
Since quite a number of customers will be rolling out CiviBanking in Q4, we expect to have a stable v1 ready by the time CiviCRM 4.4 goes GA.
If you are interested -- and why would you not be -- you can come and take a look at CiviBanking during CiviCon London.
Update: we've arrived at the point where we are going to be transforming our CiviCRM CDN Tax Receipts Drupal module - https://drupal.org/sandbox/semperit/1289724 to a CiviCRM extension. Thanks to my projects, and Jake's from Peaceworks and Lola's from Freeform we have been able to add a huge amount of functionality during 2013: e.g. Annual Tax receipts, Receipts issued in bulk, reporting, hooks which can be used to decide whether contributions are eligible or not to be receipted based on custom fields, based on amount, and soon to come: inject your own custom PDF letterhead/template as a background template). The added functionality has made it a popular module for CDN non-profits and the requests for a Joomla version are now persistent. So it makes total sense to transform this into an extension now. We've scheduled work on it starting this month!
Even though London has become hotter then the face of the sun over the past few days we've been busy beavering away on an update to the UK Gift Aid module to support compatability for Civi v4.3 and to add some new and exciting features.
- v4.3 compatability
- Able to now select a batch from a drop down list in the contribution search
- Able to remove contributions from a batch
- Plays nicely with the online submission module so you cant remove submitted contributions from a batch
- Able to change the gift aid percentage (now held in an option group)
- Improved install and uninstall /...
We recently had a client using Rajesh's civicrm_offline_recurring_payment module, but they were wanting to also upgrade their CMS to Drupal 7, so we've put together an extension version which should now support any of the CMSes supported by Civi. You can install it via the Manage Extensions page, and it supports versions 4.1, 4.2 and 4.3 at the current time of writing.
The extension basically allows a Civi admin to set up recurring payments for contacts via the admin interface. When installed, the extension places a 'Setup Recurring Payment' button at the bottom of the Contributions tab for each contact record:
.. which, when clicked on, takes you through to the following form for setting up a recurring payment:
I have previously blogged (http://civicrm.org/blogs/sarahgladstone/fun-and-joy-authorizenet-code-attached) and chatted about (http://forum.civicrm.org/index.php/topic,29234.0.html) about the fun and joy related to supporting automated recurring transactions in a production environment, and started the process of restructuring that portion of the code. I have made much more progress and have been using the code attached on production for about 2 weeks now. I think this approach (which I have implemented for Authorize.net) makes a good model for any payment processor that offers automated recurring contributions. You can download the code (works with version 4.3.4) HERE
My primary goals were as follows:... Read more
For some time i've been trying to make my organisations contact list accessible outside of CiviCRM. Why you may ask?
Well, mainly convenience, but also for reducing duplication, maintaining a personal address book, an organisational address book and a CRM will mean inconsistent information, duplicates, contacts in one place and not the other etc. On the convenience side of things, it means potentially having access to your CiviCRM contacts in your email program, phone and many other places LDAP can be utilised.
Initially I tried the google apps sync extension but that had a couple of pitfalls, firstly you need google apps (which you may not have), if you do have an account, you will need a paid account (again not necessarily a blocker), but the main problem I hit was that the extension can only write (a Google limitation) to your accounts directory, which...Read more
Imagine you're a non-profit employee or volunteer, responsible for managing donations. You get into the office, pick up the first coffee on the way to your desk, to find a HUGE bank statement for you to process today. Good news for your employer, not for you, because even at the rate of roughly two payments per minute, you'll be spending 19.5 hours processing them. Yay !
Wouldn't it be nice if CiviCRM would load the bank statement files and turn them into contributions, membership renewals, new contacts, people who have moved and so on ? Yes, of course.
Why can't we just import it as contributions ? Well, think about what the human operator does. For starters, it about identifying who the donor is, and either locating the contact or creating a new one. Next, it's about looking at the context that knowledge provides : perhaps this is the payment of an already existing pay-later contribution, or a pending...Read more
CiviCRM configuration is largely driven through the web interface and the database: if an administrator wants to add a new "report" or new "relationship type", he can accomplish this with a few clicks of the web interface. The new item is inserted into the database and immediately becomes live. This is great for web-based administration, but it's inconvenient for developers: if a developer writes a module or extension that registers something in the database, then he needs to write an installation routine to insert the item (and an uninstallation routine to delete the item). CiviCRM 4.2+ includes a better way: use the API and hook_civicrm_managed. This technique is already used in "civix" based extensions, but it also works with Drupal modules, Joomla plugins, etc.
As an example, suppose we are creating a module/extension called "fancyreports" which defines three new report classes. Each of these classes...Read more
Proper GRM tools can make all the difference in the success or failure of your herd. As many developers have found, working with a proprietary goat resource management system can seem simple in the beginning, but customizing it to your herd's specific needs can feel like eating brambles. With the new CiviCRM extensions framework and easily digestible API 3.0, developers can dig in and produce at an unprecedented rate.
CiviGoat Alpha, the world's preeminent GRM, has just launched onto the fertile open-source landscape. Let's get right to the questions.
What's a GRM?
That stands for Goat Resource Management.
Does it integrate with the equine and/or bovine retinal scanner I already use at my ranch?
Not yet, but community contributions are encouraged. Find us on IRC.
Does it scale well?