Hello,
I wonder if anyone has come across a similar issue and how they got around it:
1. We process memberships at the HH level (if one exists) as everyone in the HH can benefit from that membership.
2. When we process tickets we have that on the individual records as we want to see their individual ticket history and their online login is on their individual record also.
The issue we are having is members of a certain level do not have to pay ticketing fees, however when they book online it is not taking the fee off the booking as they are booking on the Individual record and the membership is on the HH.
Is this possible for the membership to be recognized in the individuals order? I feel it should be. Any advice greatly received.
Thanks
Kelly
P.S. Please don't say we have to get our web provider involved.
Yes, it’s possible. Since the ranking procedure is custom, pretty much if you can code it, you can do it. Just be careful with your coding if you are using LP_CUSTOMER_RANK to manage the ranking calculation. The procedure is called every time a constituent record is updated, so caution must be taken to ensure that the code is neither long running nor does it return any errors. If errors are generated by this procedure, then updates that take place in transactions (such as ticket orders and contributions) will fail and never be saved.
Kevin Sheehan
Senior Technical Writer & Consultant
Tessitura Network
+1 888 643 5778 x 329
ksheehan@tessituranetwork.com
Unknown said: Yes, it’s possible. Since the ranking procedure is custom, pretty much if you can code it, you can do it. Just be careful with your coding if you are using LP_CUSTOMER_RANK to manage the ranking calculation. The procedure is called every time a constituent record is updated, so caution must be taken to ensure that the code is neither long running nor does it return any errors. If errors are generated by this procedure, then updates that take place in transactions (such as ticket orders and contributions) will fail and never be saved.
Wise words. For exactly this reason, we don't update ranks via LP_CUSTOMER_RANK, but via a separate SQL agent job. At the moment, we have three different active ranks that modify what customers see on our web site, and they are important, but not so important that we would want to add to the execution time of every single constituent update.