1

I've been working on a camp registration page where an adult registers one or more children for one or more events, with a single Pending contribution to tie it all together (per Xavier's advice here). My API calls successfully create the adult, contribution, children, relationships, participants, and participant payments (a connection to my contribution) without error. However the participants still don't seem to be connected to the payment. When I view a participant record, the total paid shows the full amount with a balance of $0, even though the contribution is $0. When I click View Payments from here, there are no payments to display. When I click Record Payment, I get the error "No payment information found for this record".

Here is a Gist showing just the relevant parts of my code. Any advice is greatly appreciated.

Improve this question
3
  • Hi, not sure I understand, are they for the additional participants that you have 0? Try to register multiple participants with a single payment via the UI and examine the differences with what you have created via the api
    – Xavier
    May 4 '15 at 12:56
  • I'm not setting a registered_by_id value for any of the participants, since the adult fills out the form (but is not attending). As best I can tell by looking at the participant BAO code, this should make it so that none of them are "additional participants", but are all considered primary.
    – Nicholai
    May 4 '15 at 13:06
  • Hi, The logic seems to be there is always the main participant, that is the one "paying", the other participants are linked to the main one (per the UI and BAO).
    – Xavier
    May 4 '15 at 13:20
1

when you create the "non main" participants, do you link them with the main participant registration?

As written, try to register multiple participants via the normal web interface and use it as a template, but it seems that you need to set participant_registered_by_id to the id of the first participant (BAO/Participant.php getAdditionalParticipantIds function should give you more hints)

Improve this answer
5
  • Using the front end, the primary registrant can't have a $0 fee while giving the additional registrants a non-zero fee. We also can't have multiple events in the transaction (to set which participants will attend which events). The end goal is to bring these disparate items into a single order/invoice; I think I am at a point where Civi doesn't yet have the business logic or db schema design to handle this concept.
    – Nicholai
    May 4 '15 at 23:59
  • 1
    Out of the box, you won't get it indeed, the point of using the UI was to verify how the link between additional registrations and the main one, as it seems to be the bit missing to display properly the registrations with the amount
    – Xavier
    May 5 '15 at 13:51
  • I've now seen how the DB saves it; primary record has registered_by_id set to null and additional records have registered_by_id set to the primary. We're going to change the approach to creating each participant individually as Pay Later, use a participant custom field where all participants created by the form share one php uniqid(), then create a custom token to pull them together for display.
    – Nicholai
    May 5 '15 at 14:21
  • you might be able to use the source or card_id to group them too. Not sure why you can't promote one of the participant as the main one and use the "standard" multi-participants still ;)
    – Xavier
    May 5 '15 at 15:03
  • In that setup, we are essentially asking a parent to choose their favorite child (or we are choosing it for them). The "primary" and "additional" concepts and workflows just won't work for this organization. I considered Source initially, but they are considering using that to determine which email/event/staff member/etc brought in the participant.
    – Nicholai
    May 5 '15 at 16:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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