When the price is calculated, it shows the total price based on the number of slots registered. When the registration is added to the order, the quantity is set to the number of slots, doubling the price a second time. This results in incorrect order totals. For example, I have a registration type festival_booth, and a module that implements hook_registration_commerce_calculate_price to calculate the price based on number of tables, chairs, etc. The price show on the registration page (path registration/XX) is $339, which is correct. The price shown in the order is $339 per unit, but quantity gets set to 2, and the line item total becomes $678, which is wrong.

Comments

lance.gliser’s picture

This is troubling me at the moment as well. I assumed I was going to be able to set the price for the entire registration including all spaces. My particular needs are to have a number of free spaces available per registration. So you can book up to 4, and the first is free.

hook_registration_commerce_calculate_price provides me with the power I need to push the price of events down to the individual event level, but with it affecting only the price of individual tickets, I have no way to satisfy the 1 free ticket type requirements. I'll be looking into options to move around this over the next week. Going the really long way around, I'm considering the following approaches:

  1. Issue a discount against the order via commerce somehow.
  2. Modify the module to provide a single line item, without quantity that uses hook_registration_commerce_calculate_price for the total price. This would require changing the module...

Maybe there are other approaches, but I don't see them yet.

lance.gliser’s picture

I solved my own problem here. You might be able to do the same.
Just approach it in the following way:

Total cost (of all spaces)
- discount
/ number of spaces
return that.

There's some rounding issues, but it's close enough.

$slots = (int)$data->count;
  $cost = $entity_settings['settings']['price']['amount'] * $slots;
  $discount = $entity_settings['settings']['price']['amount'] * $entity_settings['settings']['free_spaces'];
  $price['amount'] = round( ($cost - $discount) / $slots );
  return $price;
gcb’s picture

Status: Active » Closed (works as designed)

This is an odd one. I don't think it's a bug so much as a challenging use-case.

As lance points out, you can work around this with some extra intelligence in your price calculator.

Another thing we have done in the past is to add a field to our registration types for the number of attendees, and limit the "slots" on the registration configuration to 1, hiding that field. This way, the cart will only have 1 item in it even if you select 4 attendees. You can simply use your attendee count to calculate the price in your hook.

We usually have to override the commerce display in this case as well, as the "count" in the commerce cart becomes confusing. You can mess with it using hook_commerce_cart_line_item_refresh I believe.

I'm going to set this to "works as designed": if someone can come up with an elegant way to solve this problem (I just mean a sensible, intuitive behavior, not a coded solution), please turn it into a Feature Request and reopen, or just reference, this ticket.