What is the best way of creating a constituency for those that purchase a subscription ticket?
When some purchases a subscription ticket we need to create a constituency so we are able to pull that information via the WebAPI.
THis would be something that happens regularly
Here at the ACO we have an overnight SQL job that runs every night that has a set of stored procedures to do various tasks. What happens for us is that LP_UPDATE_SUBS_HIST is run - it allows for a string of season numbers to be passed back and I'd be happy to share - it's really easy logic. This updates the LT_SUB_HIST table so that when the next script LP_ACO_AUTO_CONSTITUENCIES runs, it can just look at people who have a subscription package where the season has an fyear value of the year that the script is run.
Send me a message or something if you want more detail!
Martin
I am interested. The standard LP_UPDATE_SUBS_HIST will do the trick and add the constituency of "Subscriber" easy enough. Thinking long term, next year when subscriptions are new or renewed no problems as LP_UPDATE_SUBS_HIST will add them or leave them. BUT, if they are not renewed I want to terminate the "Subscriber" constituency.
This is the issue I'm trying to understand how also to solve.
We have a scheduled job that runs nightly after lt_sub_hist is updated. It removes all subscriber constituencies and then regenerates them all based on the sub hist at that moment. It does it for whatever we've defined as the "current" season. So people with cancelled orders, after a day no longer have the sub consituency, and when we start a new season, last season's subs no longer have the "current subscriber" constituency.