We recently rolled out N-Scan and I'm now working on getting PAH up and running. We cannot have PAH for all the performances we sell, though - we are a regional box office and sell tickets to other venues that do not have scanners. I see that I can restrict PAH by MOS but I’m not seeing a way to restrict PAH for certain performances or seasons. Am I missing something? We are not on TNEW. This will be a problem for us because we only have 3 MOS for web – a general public one (WEB) and 2 additional ones for different member levels. My concern is that if I turn on PAH for our WEB MOS, then it would appear as an option for all web orders, no? Even if I had a generic PAH template for all performances ready, we can’t allow PAH delivery for most off-site performances. What happens if there is no PAH template for one performance in the order – does it remove the PAH delivery method option in checkout? Or would that generate an error?
From my searches of the forum, it sounds like options are to use a content type or keywords that is performance-based and have custom code turn on/off PAH as a delivery method option for orders containing a performance that doesn’t have the keyword/content type. Have others tried these methods? is one better than the other (content type vs keyword)?
I hope I’m wrong and there’s some way around this without custom code. Any advice?
Odele
Hello Odele!
As to which is better, content type or keyword, I could not say, but as the person who wrote and implemented the custom procedure we used for delivery methods on the web, I cannot see why one would be inherently any better or worse than the other. It is simply a matter of having something set onto which to lock for the database to find about the performances you want to not have PAH as an option. We used a content type, but I do not see why a keyword would not work as well.
Once that was implemented, it worked like a charm (that was before we went TNEW last year, so we use something else now). Our Box Office Supervisors who build the performances have a build log that they use to compare against the build sheets they get from the leadership staff, and they simply check things off against that as to which performances do and do not get which things applied to them.
If you ARE indeed going to do something like this, I would suggest thinking about additional restrictions you might want to add in there, too. There are a few more things that you can very easily do with the same procedure. Like we put a rule in there to force Hold at Will Call for a specific Price Type Category of student ticket which allowed us to continue to let some student tickets be sold with Mail, PAH and Will Call as options while others getting Will Call so we could check for IDs. We also put an additional content tab allowing us to choose any additional price type per performance (we mostly used Single VIP for this, but it worked on any chosen one, for flexibility) to be forced for Will Call. We then also conversely removed Hold at Will Call as an option when the patron had a Valet Pass in their cart as our campus set-up does not really allow someone to pick up their tickets and THEN go to Valet to park their car.
We are making it all work with TNEW just fine now, too, but, of the problems we had with our custom site (and there were many), this certainly was not one of them.
Best of luck, and happy to answer more questions.
John
Thanks, John. This was great info and very helpful, especially those special cases to think about. We went with a new content type for PAH to control at the performance level, got it coded yesterday, and launched today. Works perfectly!