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.
Hi Kelly,
What is triggering waving of the fee? The only two ways I can think of are either when a member logs in the MOS is changed to one that isn’t included in the fee rules (based on ranking) or custom code on your website. If it’s managed with a rank based MOS shift, you probably just need to change your ranking procedure (which is always custom) to apply the member rank values to all the constituents in the household. If it’s managed with custom web code, you still might be able to fix it without getting your web provider to make changes, it just depends on what the code is looking at to determine that someone is a member. Hopefully it's just looking at a rank value, constituency, or attribute value, and then again you can just add whichever one of those it is to the individuals in the member household.
Kevin Sheehan
Senior Technical Writer & Consultant
Tessitura Network
+1 888 643 5778 x 329
ksheehan@tessituranetwork.com
Thank you Kevin.
I'm just reading through the documentation on Ranking. Would it be possible to set up a Automatic Rank update that adds the rank to all primary affiliated constituents when a membership of a certain level is added to a HH?
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.
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.
I now have the problem the other way round. Any help would be greatly appreciated.
The Problem:
Open to any other suggestions.
You could try adding the rank to the hhold that member belongs to in addition to the member. We do that in the case of staff (always an ind) to extend staff comp privs to the hhold, if they belong to one.
If a member logs in, who is part of a household, they don't have access to the same benefits. I.e. the MOS doesn't change based on the Ranking on the Individual record so they can access Priority booking.
I'd make sure you understand all the different permutations of login locations and TNEW behaviors: you can have logins on a Household or an Individual account, and the behavior is pretty complicated. All transactions certainly happen on the Household whether the login is associated with an affiliate or not), but other things happen on the specific account the login is on: for instance, Interests updated through the Interests page (account/interests.aspx) happen on the individual customer record. I haven't checked to be sure, but I expect that the Web Ranking also happens on the account of the login.
Putting the Membership on the Household makes the most sense as they probably share it any way - However, as we have a single membership option we can't put that as the Household level, our membership team, where a Single Membership exists, don't want both Affiliates using it.
The real question is how you rank customer accounts. Your ranking algorithm is necessarily custom, so you should be able to make this do whatever you want (not that it will necessarily be easy). So you could potentially have the ranking algorith look at affiliates when computing it's value, and you can choose which memberships it fires certain behaviors on (i.e. skipping Individual memberships altogether, or just not looking for those on an individual account when computing for a household.).
I've had a look at the ShiftContext API method, could this work? Not being too well versed in the API world I'm not too sure.
Not likely: if you have TNEW you have limited ability to fire customizations related to session. How were you going to go about implementing it?
I think that the Ranking on the HH would pose the same problem. The other 'non-member' affiliate would be able to access the same benefits, as they also will be transacting at the Household.