Welcome to Project 60's homepage.
Before you ask - the project name is derived from the fact that when we created this page, there were already 59 child pages to the projects main page, so ... sorry to disappoint you if you expected something more heroic or intelligent. Also, we know that the logo does not represent the number 60, and that it is not even a valid roman number at all. So what...
Project 60 is an offspring of the discussion on Direct Debit processing in CiviCRM and its relationship to SEPA Direct Debit. In the wake of that discussion, around the end of January 2013, a number of initiatives surfaced. Project 60 tries to integrate and amalgamate the various approaches.
Project 60 produced two subprojects: CiviSEPA and CiviBanking. While CiviSEPA enables CiviCRM to generate and process SEPA direct debit payments, CiviBanking tackles the broader scope problem of bringing general accounting information (like bank statements) back into the system.
Both projects have been deployed in productive environments since early 2014 and are on the verge of the first public release. Refer to the individual pages for details:
Most of the functionality of Project 60 has to do with what Björn Endres calls Closed Loop Accounting : simply put, handling all asynchronous events that happen in the loop that connects banks and bank statements, CiviCRM users deriving Contributions from them, payment processors generating batches for providers to execute and payments happening at the bank level.
Currently, Project 60 covers two main areas of functionality :
Here, we'll try to define a kind of 'best practice' that should allow us to optimize the position of the human user, who spends hours and hours importing or inputting information into CiviCRM, and handling all kinds of exceptions.
This project tries to imagine how we could support the operator (ie. the user who feeds transactional data into CiviCRM) in the process of identifying the individual Contacts and Contribution(Type)s. Structurally, this extension will handle the loading of payments (from bank statements or equivalent data sources such as accounting systems exporting a selection of bank payments) and contain the intelligence to deduce the required contributions from them. Part of this will be fully automatic, part will be facilitating a manual conversion, and part will be heuristically driven or rule-based. Part of the intelligence of CiviBanking will be contained in the heuristic plugins, which could be generic or semi-customized to fit a specific installation's needs.
To interact with banks, CiviBanking will use one or more payment format plugins to import/export data in/to different bank statement formats, structure the data import process and manage the consistency of the bank statement import (like ensuring no files are missed in a sequence, ...). However, it's easy to extend this to plugins to draw data from different accounting packages, support custom scripts that use the API to load data from sources such as Global Giving ... and if you're open-minded, importing Contributions would also fit nicely into this scope.
There's already quite some work out there around direct debit processing, but everyone seems to have their own way to structure the process. When batches are used to group payment requests to send to a provider, how do the actual payments of the batch or its requests and/or the exceptions in this process get fed back into the process ? How are exceptions signaled to the user ? This project will address the general issues concerning asynchronous payment-to-contribution loops.
In particular, we'll focus on the SEPA Direct Debit specification, which will be mandatory in most European countries in the next few quarters.
There are a few resources that belong to the project as a whole, rather than the two subprojects:
Currently active participants :