Answers.Body: <p>Here's how we get someone else to pay! This is an Example of an Event Registration:</p>
  
  <ol>
  <li>Primary Contact -> and 4 Participants; Key is: register each Contact separately;</li>
  </ol>
  
  <p><a href="https://i.sstatic.net/iG8bs.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/iG8bs.png" alt="enter image description here"></a><a href="https://i.sstatic.net/drKoe.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/drKoe.png" alt="enter image description here"></a></p>
  
  <ol start="2">
  <li><p>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; </p></li>
  <li><p>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. </p></li>
  <li><p>Example: KarinG will register Karin G:
  KarinG has paid - but has no Events:
  <a href="https://i.sstatic.net/B32wf.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/B32wf.png" alt="enter image description here"></a></p></li>
  <li><p>Karin G is the Participant but has no Contributions:
  <a href="https://i.sstatic.net/YwuWw.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/YwuWw.png" alt="enter image description here"></a></p></li>
  <li><p>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)<a href="https://i.sstatic.net/d3GkB.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/d3GkB.png" alt="enter image description here"></a></p></li>
  <li><p>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; </p></li>
  </ol>
  
  <p><a href="https://i.sstatic.net/rpRZl.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/rpRZl.png" alt="enter image description here"></a></p>
  
  <ol start="8">
  <li><p>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: <a href="https://i.sstatic.net/mQCKu.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/mQCKu.png" alt="enter image description here"></a></p></li>
  <li><p>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);</p></li>
  <li><p>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.); </p></li>
  </ol>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-30T18:54:14.577Z
Answers.Text: Clever, but appears to be a Drupal-based solution, no?
Answers.UserDisplayName: Evan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-30T19:15:24.023Z
Answers.Text: It’s effectively an API solution (webform civicrm is really an extension - one that does not create any tables)
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-31T07:38:18.967Z
Answers.Text: 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?
Answers.UserDisplayName: ErikH - CiviCooP
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-30T16:30:16.813Z
Answers.LastActivityDate: 2018-01-31T15:38:38.023Z
Answers.LastEditDate: 2018-01-31T15:38:38.023Z
Answers.UserDisplayName: KarinG - Semper IT
Answers.Body: <p>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?</p>
  
  <p>See for instance <a href="https://civicrm.org/blog/eliet-henderson/improving-civicrm%E2%80%99s-soft-credit-functionality" rel="nofollow noreferrer">this blog post</a>, 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.</p>
  
  <p>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"</p>
  
  <p>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.</p>
  
  <p>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)?</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-31T07:36:28.063Z
Answers.Text: 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.
Answers.UserDisplayName: ErikH - CiviCooP
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-31T15:53:49.500Z
Answers.Text: 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.
Answers.UserDisplayName: ErikH - CiviCooP
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-31T23:45:30.853Z
Answers.Text: 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 ;)
Answers.UserDisplayName: Xavier
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-31T23:47:14.647Z
Answers.Text: 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)?
Answers.UserDisplayName: Xavier
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-02-01T08:24:06.920Z
Answers.Text: 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!
Answers.UserDisplayName: ErikH - CiviCooP
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-30T07:54:31.557Z
Answers.LastActivityDate: 2018-01-30T07:54:31.557Z
Answers.UserDisplayName: Xavier
Body: <p>We are thinking about creating a native CiviCRM extension Someone Else Pays.</p>
  
  <p>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. </p>
  
  <p>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.</p>
  
  <p>At this point in time our thinking would be to:</p>
  
  <ul>
  <li>generate a new table (sep_contribution_payer) where the contribution_id and the paying contact_id are stored if there is a different payer</li>
  <li>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</li>
  <li>create API's (get, create, delete)</li>
  </ul>
  
  <p>Any comments, suggestions, tips, offers to co-fund?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-29T18:52:25.883Z
Comments.Text: 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.
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-30T07:57:11.350Z
Comments.Text: 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 ;)
Comments.UserDisplayName: Xavier
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-30T20:40:14.563Z
Comments.Text: There is a blog post from @ErikH-CiviCooP with interesting discussions https://civicrm.org/blog/erikhommel/someone-else-pays
Comments.UserDisplayName: Xavier
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-03-07T14:35:56.133Z
Comments.Text: 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?
Comments.UserDisplayName: Rose Lanigan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-03-11T07:19:21.087Z
Comments.Text: @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?
Comments.UserDisplayName: ErikH - CiviCooP
Tags: <civievent><civimember><extension><payment>
Title: Idea for extension Someone Else Pays - any feedback?
ThreadText: # Idea for extension Someone Else Pays - any feedback?
  
  (Asked by: username_0 on 2018-01-29)
  
  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?
  
  **Tags:** civievent, civimember, extension, payment
  
  > **Comments:**
  > **username_1**: 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.  
  > **username_2**: 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 ;)  
  > **username_2**: There is a blog post from @username_0 with interesting discussions https://civicrm.org/blog/erikhommel/someone-else-pays  
  > **username_3**: 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?  
  > **username_0**: @username_3 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?  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_4 on 2018-01-30. Score: 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 here](https://i.sstatic.net/iG8bs.png)](https://i.sstatic.net/iG8bs.png)[![enter image description here](https://i.sstatic.net/drKoe.png)](https://i.sstatic.net/drKoe.png)
  
  2. 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;
  3. 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.
  4. Example: username_4 will register Karin G:
     username_4 has paid - but has no Events:
     [![enter image description here](https://i.sstatic.net/B32wf.png)](https://i.sstatic.net/B32wf.png)
  5. Karin G is the Participant but has no Contributions:
     [![enter image description here](https://i.sstatic.net/YwuWw.png)](https://i.sstatic.net/YwuWw.png)
  6. Receipting? Does it work? Almost -> the person who paid (username_4) gets a transaction receipt showing those who have been registered (Karin G) [triggered via the API - sendConfirmation to be exact)[![enter image description here](https://i.sstatic.net/d3GkB.png)](https://i.sstatic.net/d3GkB.png)
  7. 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](https://i.sstatic.net/rpRZl.png)](https://i.sstatic.net/rpRZl.png)
  
  8. 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 username_4 paid for Karin G to go to the Conference - username_1 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](https://i.sstatic.net/mQCKu.png)](https://i.sstatic.net/mQCKu.png)
  9. 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);
  10. 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.);
  
  > **Comments:**
  > **username_5**: Clever, but appears to be a Drupal-based solution, no?  
  > **username_4**: It’s effectively an API solution (webform civicrm is really an extension - one that does not create any tables)  
  > **username_0**: Thanks @username_4, 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?  
  
  ---
  
  ### Answer by username_2 on 2018-01-30. Score: 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](https://civicrm.org/blog/eliet-henderson/improving-civicrm%E2%80%99s-soft-credit-functionality), 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)?
  
  > **Comments:**
  > **username_0**: Whooaa @username_2, 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.  
  > **username_0**: 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.  
  > **username_2**: Hey @username_0, 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 ;)  
  > **username_2**: 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)?  
  > **username_0**: 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!  
  
  ---
  
  