Hi, I'm trying to configure my web site to allow people to register for events. I know that the Availability module will allow me to put a cap on the number of attendees. However, our pricing model is based on seat number, so that the first few seats are discounted more deeply than later seats. I'm pretty sure that I could modify the price with the Charges module if I could just reach in and find out how many seats are left (how much inventory is left), or which seat number the person is trying to purchase. I'm thinking that if I could access this data as a token in the Additional Charge > Calculations interface, this would all work out so very magically. So, my first question is, does this sound like it would work out the way I think? My second question is, how would I go about making this token available to the Charge module? I see the following on line 296 in ec_availability.module which looks like it has variables with the sort of thing that I want:

$avail['current'] = $avail['available']-($avail['reserved']-$avail['temp']);

Thanks for any guidance!

Comments

gordon’s picture

gordon commented

Yes this is exactly how you would do it. This is the reason why I built the additional charges that way I did so that any random charge/discount can be implemented without having to do any development. This was also why I hve always been reluctant to implement discounts directly into core. I would have never thought of implementing a discount based upon current availability, and I have never been asked to implement one. Additional charges means I don't need to develop hundreds of random discount methods.

I could turn the values into tokens but depending on how your calculation works I may need to add in filters as well. Can you detail your formular a bit more. I think I know how I need to implement this but having a basic understanding of your formular will help me.

Also this will be a product only tokens, as I am not sure if you or how you would do this across the entire transaction.

I will add this in for you as it will not take long to do. If you want to take a stab at it take a look at ec_charge/module/*.inc which has all the different componets that would be there.

When I implement this I will add it to ec_availability module directly, as most of these modules will end up with thier own charge componets added.

Sorry if I went on a bit, but additional charges has blown me away, and has exceeded all my expectations. What you want to do is easy and new componets can be added to core without causing bloat. Also any of the contrib modules can also add their own componets as well.

Gordon.

gordon’s picture

gordon commented

Just look further I would just use ec_availability_get_current() to get the current availability and then turn all the fields in that array into vars.

Also temp is temporily allocated, which is stock that is in carts or checkout. Also you may only want to use actual (available - reserved) since temp as not really been purchased.

abowers’s picture

abowers commented

I have been investigating the Ecommerce module as a replacement for our current event registration system for a couple of days now, and the entire Ecommerce module looks fantastic! I was very excited to see when you posted the new code with more updates to the Charges system because it was exactly what I was trying to figure out yesterday! Once I started really playing with the Additional Charges, I could see how cool it was! I'm already seeing more capacity for bundling, subscriptions, etc. than our current system has, and it is looking like a great way to tie a bunch of our stuff together into one system.

A little more detail about what I am trying to do: We basically have 3 types of events, Introductory, Experiential, and 5-Days. The Introductory events have a single price per actual event and may vary across city, but not usually. Easy enough, taken care of by the price on each event node, and the TermsID filter in the Additional Charges. The Experiential and the 5-day both have a pricing table based on which seat number the person is registering for, rather than the typical Early Bird Discount. So for example, we have the Experiential training, which has a regular price of $695. But, if you are registering for seat 1, then you get a $250 discount. Seats 2&3 get a $200 discount, seats 4&5 get $100, and after 6, it is full price. Additionally, a typical experiential may be capped at 20-40 people depending on the venue.

So, it seems to me that two options for this are: Use a product token to either figure out a formula across an event type that changes the discount by availability, put the formula into the calculation using some sort of "availability token", and not using any additional filters. Though, this can lead to wacky modified prices, like $273. The other option is to create a straight up discount per seat number in the calculation (e.g. -$200 for seat 1), and somehow filter it by availability, or seat number, or whatever I can get in the token. The second option is really more inline with how we actually calculate the pricing, and is preferable if possible.

As far as your offer to add it into the Availability module - that would be great as it will probably be better written and done faster than what I could do!

Thanks for all your help! Alexia

gordon’s picture

gordon commented

Hi,

I am glad that you see the potential of the new charges system.

From what you are describing I am wondering if you need a quantity sold filter. as opposed to a quantity available. The problem with that is that I see you having a number of charges for each product to determine choose the rate at which a product has been sold.

Also there is the potential race condition when you have many people buying at the same time and also a problem with non-payments, ie when using payment gateways like PayPal Basic where the transaction is created but the payment is canceled.

Let me know if that would be better.

Gordon.

abowers’s picture

abowers commented

Yes, quantity sold is even better. From our standpoint, we want the discount to be changed once the seat is actually sold and paid for. So, from a race condition standpoint for us, we can deal with several people getting the same discount if they happen to register at the same time. If a couple of people happen to get the largest discount with seat one, from our perspective, it means that people are rushing out to sign up, which works in our favor. Though, if the system doesn't work that way, then we can also deal manually with correcting the discounts as necessary in the case of race conditions. This system already practically washes the car, so processing manually here and there seems worth it! And, honestly, not any different from other systems I've seen.

Our main concern is angering customers by charging them differently than they think, or having a person buying a later seat pay less than someone who bought an earlier seat. So, in the case of refunds, it is better for us if the seat is considered to still be unavailable for discount purposes. That way, if someone buys seats 1-3, then seats 4-6 are sold, and then the first person cancels his registration for seats 1-3, then the person buying seat 7 would get the regular price as if seats 1-3 were still sold, not at a discount as if buying seat 4, even though seats 1-3 were refunded. The only issue with treating it as if it were sold even if it has been refunded is that it could screw up the inventory cap. Though, at least in our case, it is simple for us to just increase the cap appropriately, and I would think that anyone that is managing their pricing this way is probably very close their inventory available and when refunds are occurring anyway.

When you mention non-payments in the case of PayPal, do you mean that they've gone through the E-commerce checkout system but abort when it comes time to pay in PayPal, or did you mean that they've paid through PayPal but stopped payment or requested a refund at a later time? Both? I'm not completely familiar with how the modules work so far in regards to PayPal as I've been mainly playing with the charges system at this point.

Thanks! Alexia

gordon’s picture

gordon commented
Status: Active » Fixed

I have added a new filter by total items sold.

This only works on products only and not transactions. But I think you can do what you need.

Let me know if you have any issues.

Gordon.

abowers’s picture

abowers commented

Thank you so much! I can't wait to try it out!

Thanks, Alexia

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.