Notice to non-developers: This post is about how some functionality in 4.2 will be implemented in code and in the database, with very minor changes to anything visible through a browser. If you're not a developer, it probably won't interest you.
Simplifying the Codebase
As part of the CiviAccounts project we are looking to redo some of the implementation of the configuration and processing of payments for contributions, memberships, and events. Currently the processing for each of these three types of objects has two paths: one for a simple configuration of the objects, and one using price sets. This means there is more code, more complexity, more possibility of errors, more work when making changes, and more need for testing.
As we refactor the existing code we're looking at keeping the simplified UI for configuration and administration, but implementing everything under the hood using price sets. Before going ahead with that, we wanted some...Read more
Direct Debit, is easy, convenient and safe. It is the UK’s favourite way to make payments automatically, and there has been a Make It Happen for Direct Debit Integration.
We have a couple of customers who have been asking to be able to set-up recurring contributions against pledges. This seems to be a possibly contentious improvement so I'm looking for feedback on it.
These organisations in question deal with lots of pledges (they solicit them by phone) and they record them in CiviCRM. Some of them are paid off by cheques, & some by credit card. Usually they try to get a commitment to set up a recurring credit card contribution & here's where they are struggling with CiviCRM. CiviCRM won't let you record a recurring credit card contribution against a pledge.
We have hacked out CiviCRM 3.4.7 / 4.0.7 install to meet their needs but obviously if we are going to move to 4.1 then we want to know we have a way to manage that.
There are 2 main reasons why they want recurring payments against pledges:
1) Because they want the same reporting for all their pledges no matter how they are paid
2) Because the pledge...
We've just started a make it happen for UK direct debit integration - something that lots of UK non profits have been asking for and we are happy to provide :)
The fabulous Eileen will be carrying out the work and we are aiming to raise the total amount needed by August 15 in time for her trip to the UK so we can spend some time kick starting it all.
So if direct debit is important to you or your clients, please step up and help us reach the goal amount.
The requirements and specification are being developed on the wiki. The spec. will be finalised before work commences based on requirements expressed by contributors and we can't garuntee to fulfill all requirements so please discusss any specific questions you have with us before adding requirements...Read more
As part of the Google Grants program for non-profits, Google offers their Google Checkout service to qualifying non-profits at no-charge with no processing fees. Depending on the fees you would pay with a competing processor this represents an instant 3% jump in your organization's fundraising efforts just by using Google Checkout.
The only limitation has been recurring donations. To address this Google launched Google Subscriptions and now we need to get support into CiviCRM so we can enjoy a single free processing fee payment gateway.
A new Make it Happen iniative was launched to get this going in 4.1 or even 3.4 if we meet the campaign...Read more
There have been a number of blog posts discussing the needs for improved accounting features in CiviCRM. The results and current specification is at the wiki at: http://wiki.civicrm.org/confluence/display/CRM/Finance+and+Accounting
Its time to help to make-it-happen for CiviAccounts once the specifications on the wiki are streamlined and prioritized. Dave has requested that all interested parties join this new CiviAccounts team.
My priorities are:
1) Get many-to-many transactions to obligations working, both in the database as well as the UI. Many-to-many includes the following use cases:
- One check/credit card transaction that needs to be allocated to many obligations ( such as event fees, member dues, donations, etc )
- One obligation that will be fufilled by many transactions. Also known as partial payments. So...Read more
Today at the Bristol Code sprint a few of us made a concerted effort on getting making Giftaid 'plug and play' for Civi.
Our starting point is code written by Millertech and our aim is to get it into a state that we can package it as a Drupal module. Once we've done that, we're hopeful that we'll be able to package it for Joomla also.
We're having to make a few improvements to Civi's hooks, and some modifications to the existing functionality to enable us to package it up, but the benefits are obvious: much easier installation and thus wider uptake of the module, and thus higher CiviCRM adpotion in the UK :)
We spent most of the morning familiarising ourselves with the code and discussing the necessary changes we would need to make. This threw up some difficult problems (I'll spare you the details) but the result was this outline of...Read more
I have shared the slides ( and video ) from my ignite session at CiviCon, which describes a case study of my use of CiviCRM for a synagogue, including invoicing and non-Western calendars. Everything is at my blog.
This is really a continuation of previous blogs on CiviCRM accounting integration. I now have some basic integration bewteen CiviCRM and Xero working and decided to do a screencast.
Screencasts are hardly my preferred medium - especially now that I've tried to make one but I thought it might be useful for people to see what a CiviCRM integration with the accounting package Xero would look like. The screencast doesn't show you any CiviCRM - just Xero and is more intended to give people an idea of what the day-to-day reality of it is.
This is a pretty limited integration with a fair bit of hard coding and a narrow focus on event registrations but it's enough to cut down the work for our next block of classes pretty substantially.
In getting this far the issues I had were in many senses fairly predictable as several have been discussed before but it did throw some light :
The Physician Health Program of BC has a task that goes something like this: Their vendors, and even staff and board members, are not paid directly by them but by the provincial medical association (BCMA), so when invoices from vendors come in, they need to enter the information onto a special form and send that off to the BCMA for payment. Then they periodically send back a statement to reconcile against. Since all the vendors are contacts in CiviCRM already, it made sense to think about putting this in there too.
The customization for entering the invoices and generating the printable forms is currently in first-attempt mode and might still need some tweaking. You can find it in the unfortunately named php repository (php = physician health program). The reconciliation part isn't done yet so I'll just describe the first part. Well, I guess "not done yet" is a form of...Read more