Our local jurisdiction recently passed an arts/culture millage. One of the benefits that local residents will receive is a percentage off tickets to our performing arts center. This is essentially a subsidized ticket program similar to many we have done in the past through grants, contributions, etc. For past programs we have used a separate payment method for the grant to pay down a portion of the order and the remainder is paid by the patron. The difference with the current program is that we we need to be able to sell these discounted tickets online. We have not offered subsidized tickets online prior to this.
I have written some custom code to apply a constituency to those constituent records that the discount applies to. This allows use of pricing rules to switch to the appropriate price type. This works as intended online or in person new constituent or existing. That is the "easy" part.
Herein lies the issue - I need to be able to report the ticket sale at the full price instead of the discounted price for settlement. Contractually this would be a "non-approved" discount and would need to be fully funded. For this current program, I need to be able to offer the discounted tickets for sale online yet report the sale at settlement at full price.
I would really like to have a separate price layer for the subsidized portion of the ticket and have it automatically paid for with a specific payment method. I haven't yet figured out a way to handle this online without delving into a major custom coding project.
Any thoughts?
Todd T
Hi Todd,
I'd be interested in your code for making the price type change happen. Have you considered doing your reporting on base price instead of the discounted price?
All the best,
Sara
Not sure how my posting ended up in Education. It was meant for ticketing.
Sara,
The price type change is handled by a pricing rule. The custom code looks at primary address, queries a local table and then determines if a constituent lives within the proper geographic area. If so, it adds a constituency to the record. The pricing rule(s) use constituency to change the price type.
Have you tried using the Performance Revenue Gain-Loss report.
This will show a breakdown by price type for/by season, production season or performance.
It shows the number of tickets sold and the amount taken, but it then also shows the variance from both the original price of that ticket (Home) and also compares it to the Base Price (usually your standard price) for each of those it shows the Potential money you would have got and the Variance.
The Potential being what money you would have made if you sold the discounted tickets at Full Price and the Variance being what you lost due to this, which should be the amount you are subsidised for.
The report itself may not be something you want to share externally but at least it has all the relevant values in for you to report on.
Mark
Thanks for the suggestions, however I cannot use base price in this instance. The subsidized portion of the ticket is taken off an already discounted ticket at various levels. So the "full price" of the ticket may be one of 6-7 different prices.
My line of thinking on this for settlement is to use a local price type matching table to get the "full price." This would remove the subsidized portion of the ticket by reverting back to the original discounted price type. I can then report on the "swapped" price type.
Assuming I understand the conundrum correctly, I have one thought, but it is not a pretty one, and it is a "major custom coding project" like you said you were hoping to avoid. I do not particularly love this solution, but I just wanted to throw it out there as it DOES seem like it would work. Also, this problem intrigues me, so I was hoping to see if anyone had any better ideas.
For the sake of argument, let us pretend that these tickets are being sold in this Special price type at $20 each while they are supposed to report as $30 total sold resulting in an additional $10 that is the subsidized part. Now let us also say that you have the performances that you can build with the 2nd price layer that you want for this additional subsidized $10 for this particular Special price type and that the subsidized $10 will be paid for using a special internal payment method.
With a LOT of careful testing first, for functionality and accuracy, what I would propose is to create this 2nd price layer AS included on this price type but with a Price = $0.00. Then you can have a scheduled procedure (and you may have to be careful about allowing Print at Home and/or when you print tickets with this method) which would essentially add $10.00 per ticket to that layer as you would when editing through "Price Details". You could then have this procedure then also add payments for these price amounts via your specific internal payment method (assuming it is set up like some On Account payment method and NOT some credit form of payment; I would not even dream of trying such a thing). I would use profiler in TEST and run the process manually to see what is actually being accomplished to make your code for this match and utilize the standard code as much as possible.
Assuming these are sold online only, you should not have to then worry about any unpaid orders, but if your Box Office is also accepting these, then you would want to consider that, as well as verifying that none of them had already added the $10.00 change via the "Price Details" section in the order.
If you are on TNEW, rather than using a scheduled procedure, if you wanted immediate updates on this to facilitate ticket print, you could also potentially play around with using these as Auxiliary events with some sort of custom form data (even some form of "I agree" checkbox would work) which you then set up in the custom form save data using a stored procedure and call this procedure.
Lastly, you could set this up as a trigger on one of the tables affected by the initial purchase, but setting up triggers and modifying standard Tessitura tables is highly discouraged.
Feel free to let me know if any of this does not make sense or will not work for whatever reason.
John