CiviCRM Community Forums (archive)

 I’ve been getting some feedback from customers about price sets in conjunction with events. The points she’s making seem to me to be valid & I’d like to get your feedback (not sure whether this will lead to any immediate implementation or not but I’d appreciate confirmation or otherwise of the situation & best approach to fixing).

Basically I think the situation is that price sets are being used for things like workshops where there are multiple workshops within one event. This seems like a different, but valid, use case compared to what was originally planned for. Here’s what seems like a simple example to me

•   Event can take 50 participants
•   Each participant chooses a morning & afternoon workshop - there are two options for each & each can take a max of 25 participants (ie. so between the 50 people they choose 100 workshops).

In this use case Price sets currently allow you to manage the number of participants in each option OR the number of participants contributing to the event.

i.e each price_field_value lets you determine the ‘max_value’ – the number that can subscribe to that option and ‘count’ – a Boolean that determines whether or not the item counts towards BOTH the option AND the event count. So, because you want each person to select 2 options you will count each person twice towards the event participant.

A related issue (which also ties in with the ‘is_deductible’ / financial code issue) is that if you use a check box rather than a select type field you don’t get the option to specify the ‘max_value’, ‘count’ (or in future the financial_type);

It seems that we either need to add another column ‘count_participant’ to differentiate from ‘count towards max value’ or introduce options on ‘count’ other than BOOLEAN. I’m thinking this won’t be too big a change.

Is my logic right? Is there something I haven’t considered?

Eileen - before we look at solutions, we need to get on the same page in term of how the current code and schema work. See inline comments below.

In this use case Price sets currently allow you to manage the number of participants in each option OR the number of participants contributing to the event.

i.e each price_field_value lets you determine the ‘max_value’ – the number that can subscribe to that option and ‘count’ – a Boolean that determines whether or not the item counts towards BOTH the option AND the event count. So, because you want each person to select 2 options you will count each person twice towards the event participant.

My understanding is that civicrm_price_field_value.count is an integer whose purpose is to determine whether to "increment the number of registered participants per unit against the maximum number of participants allowed for this event. For example, if this price field is for a table at a fundraiser which seats eight people, you would set Participant Count to 8." So this is not a boolean, but a "multiplier".

I might be thinking about this incorrectly, but for the use case described it seems to me that you could set Participant Count (count) = 1 and Maximum Participants (max_value) = 25 for each workshop, and that would work as desired (caveat - haven't tested this).

A related issue (which also ties in with the ‘is_deductible’ / financial code issue) is that if you use a check box rather than a select type field you don’t get the option to specify the ‘max_value’, ‘count’ (or in future the financial_type);

I'm not seeing this issue. I get Count and Max Participants input fields for Checkbox price set fields (as well as the other field types).

Do they care about the 100 total for the event in this case? Seems like the important thing is that there is room for up to 25 in each workshop session. If so, then I "think" you can not set max=100 at event level but just use the max participants at the price_field_value level to make sure each workshop only allows 25.

Ok - what happens if you don't enter a value in the Participant Count field. Lobo thinks this will result in each purchased option (workshop) being decremented against it's own Max Participants but not against the event max. The event max would be affected only by the number of registered participants (which is what you want). Have you tested this?

I am one of the customers Eileen referred to.  I am afraid I have led her astray.  I had always assumed I had to put a value in "participant count" in a price option if I wanted to to set a maximum number of participants for that option, but having just done some testing I can see that I don't need to. This means that the current logic works fine in terms of both a maximum number for a price option and for a price set as a whole - if you know how to use it.  I obviously didn't.

So, a couple of suggestions:

• Can the comment icon explaining the use of the Participant count field be added to the Edit window for a price option (I was in this window when I first tried to set this up and incorrectly extrapolated what I new from v3.2) 
• Could something like the following be added to the comment:
  If you do not want this option to increment the participant count for the event you can still restrict how many times this particular option can be chosen.  Leave this empty and enter a value in the adjacent Max Participant box.  For example, if you leave this empty and set the adjacent Max Participant = 20, only 20 registrants can choose this option before it becomes unavailable to online registrants.

A couple of observations:

• The receipts will be a little confusing as someone could choose an option and be charged for that option but will have 0 in the' total participants' column for that option.
  
• My receipts will no longer say 'total participant count = 3' when one person has chosen options in 3 different sessions.( A big plus)

 
And a comment:
Perhaps I have at last found a contribution I can make - I will have a go at revising the section of the Floss manual that deals with Price Sets as I do not think it is very clear (perhaps this section hasn't been revised since the ability to set a maximum number on the price option level was introduced.)