We have a certain number of "dummy" payment methods that should only be used in certain scenarios. Such as they should only be used in a certain MOS, or for a certain price type. Right now the only method to restrict payment methods are by user group, and it's just not feasible to force our ticket sellers to have to log out and log back in under a different user group just for 1 sale and then have to do that all over again for their next sale.
Primarily what's happening is we have a voucher system where students can get any student priced ticket with a special voucher. Unfortunately it happens quite frequently that the ticket sellers will ring in a full priced ticket; and since the student does not have to pay anything, they don't check the price and pay out the full amount with the voucher. We only get reimbursed for the price of a student ticket, so if it's not caught till after the show, we are out that money. I know ultimately this comes down to user error, but if there was a way that the payment method wouldn't even be an option unless there were a student ticket in the order, then we could eliminate most user error issues. We have considered using a comp ticket system, but we have to be able to report this revenue to promoters at settlement. And we have another voucher system for faculty/staff where their voucher only covers a certain amount of a faculty staff discounted ticket and they are required to pay the rest, so it wouldn't work in that scenario either.
Has anyone implemented their own solutions, or gotten Tessitura consulting to develop a good customization for them?
To purpose is sounds like you need a Gift Certificate with restrictions, which I think a lot of people could use. To accomplish something similar we vend a "student pass book", which we set up as a 4 performance non-flex NFS package in Tessitura. When the student wants to spend one of their passes, we exchange the ticket for the flex pass "performance" for a flex pass price type ticket in the performance in question, which at least helps force the cashiers to choose the correct price type, as the money in the exchange has to match up.
Most students only get 1 or 2 vouchers and are not required to use them at the same time. But using this model we could in theory create a 1 performance package with just a single price type associated, with a performance group with all applicable performances? Then it's just a matter of training the staff to ring up the package instead of the unique performance. That would be an interesting idea, however sometimes students don't present their voucher till the end of the order. But in theory by then, they would have already rung it up with the correct price type if they are asking the student for payment, and they could just pay out the single ticket with that payment method instead.
The package actually just helped us group the "book" into a single purchase, but when exchanging we simply exchange out into single ticket purchases, so one buy one the original package "performances" are returned and replaced with single ticket sales.
Oh, I think I see what you're talking about. Unfortunately, we do not distribute the actual vouchers. Essentially the total number of vouchers distributed is "unlimited"; they're mostly just pieces of papers handed out to students by teachers. It's the total amount of money in the fund that is limited, and we simply stop accepting vouchers, once the fund runs out.
Jessie,
What instantly comes to mind is to use an On Account payment method maybe named Student Ticket Bank. You would put the amount you have for the year on account and use the Student Ticket Bank on account to pay for the student voucher tickets. You would need all ticket users to have access to the On Account but it would be a good way to see how much was spent and when it is gone it’s gone. It doesn’t stop them from using the wrong price type but it does stop them from over spending what is in Student Ticket Bank on account.
Terry Stevens said:You would need all ticket users to have access to the On Account
Doesn't that mean you'd have to know to do all of these transactions against the same constituent account? You can't use On Account money from one account to pay for transactions by another constituent, can you?
Not to my knowledge... You can certainly play around and move money from one account to another within the application by saving the order, getting out of it, getting back into it and then changing the constituent on the order, but I seriously doubt that you could manage that online without a fair amount of custom work.
Ah, you are right Gawain. I forgot the important detail.