This little story about financial transactions has a couple of objectives:
1. share what we want to do for the benefit of each and everyone
2. find out if there are more organisations out there that would be interested
3. even better, organisations out there that want to co-fund and influence!
If you are interested and want to co-contribute, drop either Björn (endres@systopia.de) or me (erik.hommel@civicoop.org) a mail!
At the moment CiviCRM allows for the linking of a financial account to the financial type as a basis for data exporting to whatever software you are using for accounting. You can also attach an asset type financial account to a payment instrument. When creating, updating, cancelling or refunding a contribution the financial 'traffic' between the configured financial accounts is nicely recorded in the financial transactions table. We are not sure yet if changing the payment instrument also create nice financial transactions. All good stuff when exporting your financial transactions to accounting!
However, at Amnesty International Vlaanderen we do not have an account per financial type. We have income accounts per financial type/payment instrument/campaign. And we have cost accounts that go even a level deeper: they also look at the timeframe (so a different cost account (cocoa) when a campaign acquisition is in the actual acquisition year of the campaign or later. So the core CiviCRM functionality is not enough, although it is a good start. We need to be able to generate financial transactions at a more detailed level to be able to use the accounting batches in CiviCRM.
Youth for Christ UK has a similar problem. Here the correct financial account is determined mostly by a contribution's campaign – with a few exceptions. And the original account is not only determined by the payment instrument, but also the bank account involved.
So we want to develop something that will allow us to:
- disable the creation of financial transactions completely. In a lot of cases there will be CiviCRM customers that do not use the financial transactions at all, and at the moment CiviCRM will then do a lot of creation and use system resources for absolutely nothing. So I should be able to switch it off. I should also be able to say I only want it to process for certain financial types, campaigns, payment instruments etc.
- create some kind of hook or something that allows me to replace the 'standard' calculation of financial transactions based on financial accounts linked to financial types to a customized calculation and configuration.
- configure the accounts in a way required for Amnesty International Vlaanderen. So I should be able to link a P/L account, a cost account for the acquisition year and a cost account for the following years to a campaign.
- create financial transactions based on this specific account configuration. As CiviCRM uses contributions as the key financial item (for donations, membership payments, event payments and if I would create an extension that allows the selling of promotional items I would probably add a contribution of a specific financial type too) I would create those financial transactions whenever a contribution is added, updated or deleted.
This mainly details the Amnesty requirement, but Youth for Christ UK has very similar needs and will contribute to the development budget! As can be expected, that is why that will be a specific extension for each case :-). We want to have as little impact on core as possible, and enable everybody to create their own flavour!
Techy stuff
After some conceptual discussion (and Björn still working on the technical details and possibly changing everything again) we think we need to do only one core change at this point. This change will add a configuration setting to the CiviContribute Component settings generate financial transactions (name = generateFinancialTransactions) with the options:
- none (which should lead to no financial transactions being generated whatsoever)
- default (the default behaviour as we all know and love)
- customized (your specific generation, which should implement the post hook on Contribution)
In the specific extension we will implement the post hook, check if the entity is Contribution, check if the setting is 'customized' and do our stuff. Obviously, if the above setting is set to 'none', the extension shouldn't create any transactions either.
Oh yes, we do have a basic GitHub fork where we will be playing around: https://github.com/systopia/civicrm-core/tree/dev_txhooks_4.6.24
