discounts and promo codes

Hi Boann,

Promo codes are entirely separate from discounts (as far as I know). While promo codes can be used to give access to different prices, discounts are used to discount items already in the cart. And they are triggered by their own set of numerical codes -- "discount codes."

We've built a custom cross-reference table for discount codes, though, which might be what you're looking for. It allows the end user to enter a text-based code (instead of the raw discount code) and also adds the ability to limit discount codes by purchase date, rather than just performance date.

If that sounds like it would help, let me know. I can give a more detailed description of the business logic flow, too.

   -Morgan

Hi Morgan,

I would love to see more information on how this works for you.  I really want to start using discounts next season, as they would make so much of the  build/selling process simpler, but if we can't get them to work online the way offers work now there is not much point. 

If you don't want to share the details here, please email me at boannp@pcs.org.

Thanks so much!

Boann

Hi Boann,

Ok, let's see if I can write this all up in a way that makes sense.

First, in my previous message, I reversed which part controls the limitation on performance date vs. purchase date. The limit on purchase date is built in. When you setup a discount in Tessitura you can tell it between which dates the discount is valid. But, we also needed to control the range of performance dates for which a discount is valid. The easiest way for us to do that was to store those dates, along with the other info we needed, in a custom table.

(I'm not going to go into everything you need to do to create a custom local tables here. It's well documented, though... just search for "local tables.")

Here are the custom table's columns with example data and descriptions:

id:1 --local key (row number)
discount_id:5 --the discount id, as assigned by Tessitura's built-in discount functionality
discount_code:facebook09 --this is the text value that is entered by the customer on the website (it is required to be unique in the database to ensure there's only one set of related values per discount code)
start_date:2009-12-02T00:00:00-06:00 --start of the performance date range the code is valid on
end_date:2009-12-31T00:00:00-06:00 --end of the performance date range
inactive:N --simple way to inactivate a discount code, trumps everything else
created_by:someuser --who setup this discount code
create_dt:2009-12-02T08:10:41.167-06:00 --when this code was setup
last_updated_by:someuser --updated by
last_update_dt:2009-12-02T08:10:41.167-06:00 --updated date

So, how does this all work? Here's the logic that the web code goes through:

On a "view shopping cart" page, the customer can enter a discount code and click an "apply discount" button.

The discount code, for this example let's say it's "facebook09," gets submitted using GetLocalDataEx along with the LocalDataTableIndex value. A lookup is performed on the custom table using the "discount_code" column. If a match is found, the values from the matching row are returned (see above example data.) If it doesn't match, we display an appropriate error message to the customer.

Now, if it does match, we verify some more values: Is it set to "inactive"? And is the currently selected visit date within the valid range, start_date to end_date? (That part is probably only applicable to other Museum's or those with a similar ticketing model.)

If we get through all of that, now we can take the discount_id that was returned from the custom table and use it to apply a discount to the items in the shopping cart. We do this in two passes. First, we get the list of sub-line-items using GetCart, submit them to ApplyDiscount using the discount_id we got earlier, and set the VerifyOnly flag to yes. That will return a list of all of the sub-line-items with each one tagged whether or not the discount is valid for each. If there aren't any tagged as valid, we return an appropriate error message to the customer. If there are valid ones, we resubmit just those sub-line-items to ApplyDiscount, this time with the VerifyOnly flag set to no. The discount is applied to the appropriate sub-line-items. We call GetCart again to get the updated pricing info, and then send the customer back to the "view shopping cart" page to see their updated prices.

Hope that's not too much to take in at once. Let me know if you have any questions, or need clarification on anything.

   -Morgan

Hi Boann,

Ok, let's see if I can write this all up in a way that makes sense.

First, in my previous message, I reversed which part controls the limitation on performance date vs. purchase date. The limit on purchase date is built in. When you setup a discount in Tessitura you can tell it between which dates the discount is valid. But, we also needed to control the range of performance dates for which a discount is valid. The easiest way for us to do that was to store those dates, along with the other info we needed, in a custom table.

(I'm not going to go into everything you need to do to create a custom local tables here. It's well documented, though... just search for "local tables.")

Here are the custom table's columns with example data and descriptions:

id:1 --local key (row number)
discount_id:5 --the discount id, as assigned by Tessitura's built-in discount functionality
discount_code:facebook09 --this is the text value that is entered by the customer on the website (it is required to be unique in the database to ensure there's only one set of related values per discount code)
start_date:2009-12-02T00:00:00-06:00 --start of the performance date range the code is valid on
end_date:2009-12-31T00:00:00-06:00 --end of the performance date range
inactive:N --simple way to inactivate a discount code, trumps everything else
created_by:someuser --who setup this discount code
create_dt:2009-12-02T08:10:41.167-06:00 --when this code was setup
last_updated_by:someuser --updated by
last_update_dt:2009-12-02T08:10:41.167-06:00 --updated date

So, how does this all work? Here's the logic that the web code goes through:

On a "view shopping cart" page, the customer can enter a discount code and click an "apply discount" button.

The discount code, for this example let's say it's "facebook09," gets submitted using GetLocalDataEx along with the LocalDataTableIndex value. A lookup is performed on the custom table using the "discount_code" column. If a match is found, the values from the matching row are returned (see above example data.) If it doesn't match, we display an appropriate error message to the customer.

Now, if it does match, we verify some more values: Is it set to "inactive"? And is the currently selected visit date within the valid range, start_date to end_date? (That part is probably only applicable to other Museum's or those with a similar ticketing model.)

If we get through all of that, now we can take the discount_id that was returned from the custom table and use it to apply a discount to the items in the shopping cart. We do this in two passes. First, we get the list of sub-line-items using GetCart, submit them to ApplyDiscount using the discount_id we got earlier, and set the VerifyOnly flag to yes. That will return a list of all of the sub-line-items with each one tagged whether or not the discount is valid for each. If there aren't any tagged as valid, we return an appropriate error message to the customer. If there are valid ones, we resubmit just those sub-line-items to ApplyDiscount, this time with the VerifyOnly flag set to no. The discount is applied to the appropriate sub-line-items. We call GetCart again to get the updated pricing info, and then send the customer back to the "view shopping cart" page to see their updated prices.

Hope that's not too much to take in at once. Let me know if you have any questions, or need clarification on anything.

   -Morgan

This is very helpful!  Thank you so much for sharing with us.

Boann