• Replies 3 replies
  • Subscribers 414 subscribers
  • Views 38 views
  • Users 0 members are here
Related

Pricing Rule for Access Customers

Kelly Enderwick
$organization
Hello, Wondering of anyone has come across this issue. We have a constituent triggered Pricing Rule for our Access customers based on a Constituency Code. They are entitled to a discount Price Type. However, this price isn't available on all events and customer then doesn't seem to be able to book. Also they do not get the option to override the rule and book at the standard price if the booking being made is not for them. Ideally we would like the Access Level price types to be exposed as an option only to people who have the right constituent types. Thanks in advance, Kelly
Parents
  • $organization

    I don't believe this is possible; we've been investigating similar things. At its core, the problem lies in the fact that pricing rules are triggered in the basket.


    Therefore; if nothing is added, the pricing rule cannot trigger. The behaviour you're describing (price type becoming available before things are added to the basket - and the customers being able to choose that price type or not depending on their circumstances) is best suited to an offer. But then, of course, it's not Constituency-driven.


    Please, hive mind, feel free to contradict me if I've fundamentally misunderstood things, but I've been trying something similar before now with no joy.


    C.//

    X.

    From: Tessitura Ticketing Forum <forums-ticketing@tessituranetwork.com> on behalf of Kelly Enderwick <bounce-kellyenderwick8274@tessituranetwork.com>
    Sent: 27 January 2017 14:18:31
    To: Chris Campbell
    Subject: [Tessitura Ticketing Forum] Pricing Rule for Access Customers
     
    Hello, Wondering of anyone has come across this issue. We have a constituent triggered Pricing Rule for our Access customers based on a Constituency Code. They are entitled to a discount Price Type. However, this price isn't available on all events and customer then doesn't seem to be able to book. Also they do not get the option to override the rule and book at the standard price if the booking being made is not for them. Ideally we would like the Access Level price types to be exposed as an option only to people who have the right constituent types. Thanks in advance, Kelly



    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Ticketing Forum. You may reply to this message to post to the Ticketing forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!
  • $organization in reply to Chris Campbell
    I did this at the National. However, it involved adding code to a standard Tessitura web procedure. Prior to Pricing Rules and when I was hoping they would allow the visibility of price types to be determined with rules I added extra code to WP_PERF_DETAIL . I set up a local table that allowed us to determine if a rice type was visible sing constituency, list of keyword/value. Then wrote a function that took in price type and customer number and returned a Y/N In WP_PERF_DETAIL i added customer_no as a variable and returned it fro the sessionkey lookup. After WP_GET_PRICES_PERF I added code to remove any price type from tw_get_prices where the visibility was set to N I was doing it so that ultimately I could get rid of the second MOS we were creating for Access, although we never got around to doing that. The main issue we had which we fixed in the new website was that availability for a performance on a MOS was now determined by customer (similar to using rankings on allocations) and our previous website was designed to do that. I did it because I was hoping the code would be made redundant with pricing rule and had to change the code with every upgrade as that sp gets updated regularly. Mark
Reply
  • $organization in reply to Chris Campbell
    I did this at the National. However, it involved adding code to a standard Tessitura web procedure. Prior to Pricing Rules and when I was hoping they would allow the visibility of price types to be determined with rules I added extra code to WP_PERF_DETAIL . I set up a local table that allowed us to determine if a rice type was visible sing constituency, list of keyword/value. Then wrote a function that took in price type and customer number and returned a Y/N In WP_PERF_DETAIL i added customer_no as a variable and returned it fro the sessionkey lookup. After WP_GET_PRICES_PERF I added code to remove any price type from tw_get_prices where the visibility was set to N I was doing it so that ultimately I could get rid of the second MOS we were creating for Access, although we never got around to doing that. The main issue we had which we fixed in the new website was that availability for a performance on a MOS was now determined by customer (similar to using rankings on allocations) and our previous website was designed to do that. I did it because I was hoping the code would be made redundant with pricing rule and had to change the code with every upgrade as that sp gets updated regularly. Mark
Children
No Data