We are thinking about creating a native CiviCRM extension Someone Else Pays.
In CiviCRM you could use the soft credits (with a new soft credit type) to register another contact pay for an event registration, a membership and in theory any contribution. Our customer Domus Medica is using that at the moment. We encounter some issues though. Some of the issues are possibly bugs but some are also because we think soft credits is originally not meant to cater for this. It was meant to cater for soft credits. So we prefer to create an extension rather than fix a few issues in a hackish way and then finding out we have some more.
At this point in time our thinking would be to:
- generate a new table (sep_contribution_payer) where the contribution_id and the paying contact_id are stored if there is a different payer
- add a new collapse window on the contribution forms (also membership and event registration) to show this link if it is there, and enable the setting of 'someone else pays' in the UI
- create API's (get, create, delete)
Domus Medica would like this functionality we have a few questions for all of you out there:
- recognize the problem and found a good solution? Please tell us (mailto:erik.hommel@civicoop.org)
- recognize the problem and interested in co-funding the development? Please tell us (mailto:erik.hommel@civicoop.org)
- have some good suggestions, questions or think we have totally lost our mind? Please tell us too :-) (mailto:erik.hommel@civicoop.org)
Later note: this extension was the result and is used by Domus Medica: https://github.com/CiviCooP/org.civicoop.someoneelsepays
Comments
Sounds really good.
Who is going to pay for the extension development? Someone else?
Obviously :-)
How can you record that 'someone else' is paying when you have not yet developed the functionality to do so?
That's why they need the extension.
This seems to overlap with similar functionality that exists elsewhere. That doesn't need to be your problem, but it does complicate things a bit.
* Any contribution can be made on behalf of an organization by checking the appropriate box on the first page of the Contribution Page configuration.
* Back-end memberships have an option "Record Payment from a Different Contact?"
* The Gift Memberships extension.
Ideally a new extension would build on one of the existing methodologies, but without looking in detail I don't know how feasible that is.
Thanks for thinking along with us JonGold! Much appreciated!
We are aware of the current possibilities in core CiviCRM with back end memberships and contribution pages. In our opinion that functionality sort of hijacks soft credits to achieve its aim but it is only a half way solution for what we need. So yes, we will have to cater for that in our extension, meaning that we are aiming to pick up the data in both spots and process it towards whatever we will have in the end.
I am not aware of the Gift Membership extension, thanks for pointing it out! We will have a look and make sure that at least we include it in our documentation.
Any other hints, sound advice or suggestions?
I have encountered similar use cases, but have been able to resolve these with "what's already there". I am very concerned about adding yet another mechanism when there are already similar constructs in CiviCRM (cf. JonGold), and you could use the existing data model to do so. For example, you can absolutely record different contact_ids in the civicrm_contribution and civicrm_membership tables if 'someone else pays'. The same is true for event registrations. We are already using these constructs when a parent pays for a child's registration, or when an employee pays for a corporate membership. Going outside of these existing constructs could require downstream changes and/or have adverse effects on reporting, accounting integration, the calculated fields or tax receipts extensions, the webforms integration, etc.
I think it is not as dramatic as that because I will not change any of the contribution recording. Effectively we will introduce what is already there in the soft_credit table but in another table because in the back end processing it is not a soft credit. I think a soft credit is when someone donates/pays but you want to record that there is another person that you want to be grateful for this. That is quite another thing as my company pays for my membership or event registration.
When we would do what is required for the project we have at hand we would be introducing quite a few places where we would effectively code a variety of "if a soft credit is actually not a soft credt". That sounds a bit hackish to me.
Effectively all we would be introducing is a small window to show what is in the database as 'A is paying for B', not changing any other part of the financial process which works fine indeed.
FYI, the ContributionSoft in the core is at the moment not calling any hooks. Fixing that for something that is actually not a soft credit is not something I would advocate?
I've added a specific example of how you can have someone e.g. a Director -> pay for their staff to attend a Conference:
https://civicrm.stackexchange.com/questions/22493/idea-for-extension-someone-else-pays-any-feedback/22512
It’s effectively an API solution; webform civicrm is really an extension that is populating existing CiviCRM tables via the API;
Thanks @KarinG, nice! However this does not solve some of the backend problems we are encountering. At the moment we use the core solution of soft credits while this actually is not a soft credit....