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
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