Ticket Limits on the Web

I don't have any code to share, but I think I know how it could work. There are a couple of ways to get there, but it is essentially the same idea.

You could create a keyword and apply it to specific performances that you want to limit tickets beyond the global limit in the config file. For instance:

Keyword 1: Custom Ticket Limit / 2

Then, it would just be a matter of a bit of custom code on your 'number of seats' selection element on the web. Basically - if X performance has keyword = 'Custom Ticket Limit' then limit the number of tickets purchased to 2. You could add and remove the keywords and values at will and it would effectively be dynamically driven from Tessitura.

I haven't fully read up on the v9 enhancements / fixes, but the other way would be by using Offers for the particular mode of sale. There is a parameter named Limit. Orignally, I believe the Limit was to be a restriction on the total number of tickets that could be sold via this particular offer (ex: only 50 tickets at this price type / promo code) - but, the last I knew, there wasn't functionality in the API to increment the value and actually disable the offer once the limit is reached. But - the value IS returned via GetPerformanceDetailsWithDiscount and you could do something similar to the first example, however, instead of an overall limit (50) - put the per performance limit (2) and base your front end case statement on that.

Good luck!

I don't have any code to share, but I think I know how it could work. There are a couple of ways to get there, but it is essentially the same idea.

You could create a keyword and apply it to specific performances that you want to limit tickets beyond the global limit in the config file. For instance:

Keyword 1: Custom Ticket Limit / 2

Then, it would just be a matter of a bit of custom code on your 'number of seats' selection element on the web. Basically - if X performance has keyword = 'Custom Ticket Limit' then limit the number of tickets purchased to 2. You could add and remove the keywords and values at will and it would effectively be dynamically driven from Tessitura.

I haven't fully read up on the v9 enhancements / fixes, but the other way would be by using Offers for the particular mode of sale. There is a parameter named Limit. Orignally, I believe the Limit was to be a restriction on the total number of tickets that could be sold via this particular offer (ex: only 50 tickets at this price type / promo code) - but, the last I knew, there wasn't functionality in the API to increment the value and actually disable the offer once the limit is reached. But - the value IS returned via GetPerformanceDetailsWithDiscount and you could do something similar to the first example, however, instead of an overall limit (50) - put the per performance limit (2) and base your front end case statement on that.

Good luck!

Regarding Nathan's post, that could work, but there's nothing to keep someone from coming back to the website and purchase more tickets for the same performance.

Gloria, are you looking to limit the number of tickets per-performance globally, or just the number of tickets per-performance per-order?

   -Morgan

Good ideas.

Morgan, you're right. We need to limit the ticket per performance per order. I believe this is the new functionality in version 9 that allows you to limit tickets by the offers. But that functionality is not carried over to the API so I need a work around.

Gloria

Gloria, Like Morgan we also restrict tickets by membership type. We created a custom procedure that does the following:

1: Figures out how many tickets a particular member is allowed in total (based on membership level)

2. Checks perf_no and shows how many tickets already purchased.

3. Shows how many remaining tickets can be purchased at discount.

So, when you run execute local procedure through API, you send in customer_no and perf_no and what is returned is:

Allowed = 5, Redeemed = 3, Available = 2

By doing this, you can't fool the website by placing an order and then placing another one (used t have this problem, and smart members used to take advantage.)

Hope that helps.