5

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)

Any comments, suggestions, tips, offers to co-fund?

Improve this question
5
  • If this gets interest from others then we would chip in though we don't have a need/purpose for it, but good to see the options for using civi grow.
    – petednz - fuzion ♦
    Jan 29, 2018 at 18:52
  • 1
    It's a very good discussion, but not sure it fits the SE format. Not sure we have a space to have that type of chat, something missing? Let's chat at civicon ;)
    – Xavier
    Jan 30, 2018 at 7:57
  • There is a blog post from @ErikH-CiviCooP with interesting discussions civicrm.org/blog/erikhommel/someone-else-pays
    – Xavier
    Jan 30, 2018 at 20:40
  • Just to check, we have a use case where we want a parent to book his/her child/ren onto a holiday event but want to avoid webforms (client wants more flexibility with discount codes, and price sets are too inflexible in webforms) but contribution forms don't integrate with events and the normal online event registration doesn't facilitate soft credits/booking someone else on (well, you can book someone else but that makes it difficult to record information like consent to keep data on the adult's record). Your description implies the extension would be a CMS-neutral solution?
    – Rose Lanigan
    Mar 7, 2019 at 14:35
  • @RoseLanigan it is a CiviCRM extension that basically presents the data in a more user friendly way. It also provides an API to create/get a someone else pays situation. Not sure if it would meet your criteria. give me a Skype shout?
    – ErikH - CiviCooP
    Mar 11, 2019 at 7:19

2 Answers 2

Reset to default
2

Here's how we get someone else to pay! This is an Example of an Event Registration:

  1. Primary Contact -> and 4 Participants; Key is: register each Contact separately;

enter image description hereenter image description here

  1. Use Conditionals to help with how many # participants fields you need - and configure the Events webform elements - to be a checkbox for the Primary Contact;

  2. End result: if Primary Contact (in this example often a Director of a ChildCare program) is simply registering and paying for Staff to attend a Conference -> the Director pays and all the Participants are added.

  3. Example: KarinG will register Karin G: KarinG has paid - but has no Events: enter image description here

  4. Karin G is the Participant but has no Contributions: enter image description here

  5. Receipting? Does it work? Almost -> the person who paid (KarinG) gets a transaction receipt showing those who have been registered (Karin G) [triggered via the API - sendConfirmation to be exact)enter image description here

  6. And what about sending a Confirmation to the Participants that their Director has signed them up. That works too - with a little help from... CiviRules! Trigger: participant add; All I needed to do was write a small custom module to generate some participant tokens;

enter image description here

  1. Ok what does not work as well yet -> CiviCRM native is a bit confused about Payments; and the invoicing is a bit off -> it should really look much like the receipt that you can get at with sendConfirmation - but you can't. It's not clear at all that KarinG paid for Karin G to go to the Conference - Fuzion has helped make this work - by adding a Participant Name to the LineItem before webform_civicrm uses the lineItem API to create the lineItems: enter image description here

  2. What really does not work is -> if you sign up more than 1 Participant -> their Event Participant View -> shows the total $ for all the participants - not just for their lineItem (so CiviCRM native thinks that each single participant is owed a refund);

  3. If I were tasked to do this in an Extension -> use the APIs that webform civicrm uses to get this registered by functionality up and running; no extra table required; use the registered_by -> to properly link payments and event registrations; Extend the registered_by at the Event level to the Membership level -> (that would be a gift membership e.g.);

Improve this answer
3
  • Clever, but appears to be a Drupal-based solution, no?
    – Evan
    Jan 30, 2018 at 18:54
  • It’s effectively an API solution (webform civicrm is really an extension - one that does not create any tables)
    – KarinG - Semper IT
    Jan 30, 2018 at 19:15
  • Thanks @Karing, nice! However, my client does not use Drupal. And also the issue is not so much about not being able to get them to do this on the website but more the backend processing where IMO the core solution is using soft credits to do something that is not a soft credit?
    – ErikH - CiviCooP
    Jan 31, 2018 at 7:38
0

Why are you saying that soft credit isn't meant for it? It's already used to link a contribution to both the individual donor and the organisation that paid for instance, is your use case very different?

See for instance this blog post, what you want to do seems to be conceptually covered, and if there is a bug/UI issue, it could be fixed in the core.

I see the value of having a more tailored extension and it might make sense in your case, but your underlying assumption sounds awfully like "there are bugs in the core, so let's not use the core and write something else"

If the long term plan is to remove soft credit from the core and have it as an extension, it might make sense, but if there is no such plan, you will end up with lots of more of less buggy solutions that do roughly the same thing and it's something that will make it harder to adopt civi and hurt it growths.

Lastly, are the problem you experience linked to how soft credit works, or is this more a problem of separating who pays vs who benefits (is the participant or member)?

Improve this answer
5
  • Whooaa @Xavier, tone it down a bit. You should know me better than to accuse me of writing an extension because I do not want to solve some bugs :-) Have a warm beer! I am suggesting this because some one else (my company) paying my invoice is functionally something different than a soft credit. If I would solve my issues in core I would get all exceptional soft credit functionality saying: do this is the soft credit is actually not a soft credit. I think we are better off then with another solution.
    – ErikH - CiviCooP
    Jan 31, 2018 at 7:36
  • So to be even more precise: the term soft credit is confusing my back end users. So I would almost have to make a change like "if the soft credit is actually some else pays then change the label to someone else pays". That does not feel entirely correct. I am not going to interfere with any of the tables or core processes, just display it in a more user friendly way and print the stuff on an invoice too.
    – ErikH - CiviCooP
    Jan 31, 2018 at 15:53
  • Hey @ErikH-CiviCooP, I would be the last one to accuse anyone to write an extension and my badly formulated point was that we have already a feature creep, with lots of things do roughly the same thing and confuse everyone (eg tag vs group vs contact type vs custom fields...), and "let's add a new one" is a scary proposal. and civicon is in belgium this time, we'll have a proper beer ;)
    – Xavier
    Jan 31, 2018 at 23:45
  • Ah got it, "soft credit" is a wording that has never convinced my users either. Isn't is "only" a ui issue and clarify what soft credit means on specific context (eb paid by someone else)?
    – Xavier
    Jan 31, 2018 at 23:47
  • IMO it is a little more as there will also be some requirements to do with what appears on invoices which is different. So I will indeed probably just update some UI stuff and invoicing. I will not change anything to DB schema or internal processing. And you are on for that beer in Brussels!
    – ErikH - CiviCooP
    Feb 1, 2018 at 8:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.