Hello all!
What I am trying to show: Information based on package sales, such as # of packages, # constituents, # tickets, etc.
What I am having an issue with: # constituents who purchased a package and package counts. The problem arises when I have patrons who purchased a package, but then later ended up exchanging all of their original package tickets to other performances, so now in the package order all of the sub line items have a status of VOO. It would seem that when this happens, I can't use the Package Season filter, because then those packages are no longer included in the counts. Even though the original tickets were exchanged, we still count that patron has having an active subscription and thus they should still be counted. Does anyone else have this problem? How can I still show # patrons that no longer have active tickets from their original package order?
Am I just unable to use Package Season as a filter and have to go by season and price type instead?
Thanks,Sara
Sara, Are you trying to show this information season over season or for just one season?
Probably eventually both, but for now just one season.
Here's a quick dash I pulled for someone the other day - this gives us the number of constituents and it has no impact whether they have exchanged all their tickets or not. I hope it helps!PackageSalesforBrandon.dash
Thanks Madeline! Unfortunately it's that package season filter that's causing the problem. It would seem that for the scenario I referred to where a patron has exchanged all of their package tickets, they are no longer included with package season. I think this is because we use flex packages and we had to make a custom procedure to update package history for the same reason. We saw it as a feature, but it was a defect in v12 that they fixed in v15 that for flex packages, when all the tickets within the package were returned, the package would still show as a line in package history. I suspect the same principle is applied to Analytics as well, but for us we do still want that patron to have that package history record.
Regarding Sarah’s 3rd comment, what if you were to add a new order Category (or categories) to the orders that had this issue. Order category is available in Analytics. You could use that as a way to segment the orders. You would need a way to change the order category(ies) in SSMS (SQL). Once you’ve made the changes in SSMS and Analytics has reloaded overnight, the data would be available in Analytics; and you could use it to segment your data. You just need a way to segment it in Analytics. Does that make sense?
Maybe? Although I'm imagining that will require some upkeep to go back through and mark every order like that, and then remembering to add the category to any new order that falls into the situation. It might just be easier to use price type and season filters.
If the price type and season filters idea does not work, you could also try using a List as a way to filter the data. You may be able to use the List manager to identify orders or constituents with these issues. Then after Analytics reloads, that List would be available in Analytics.
The reason I mentioned changing the order category is because that is what we did to track orders related to COVID-19 issues. There is generally always another way to get to a solution for a problem.
If those ideas do not work, I could send you our SQL update statement that we use to change the Order Category on orders that ended up converting their daily admission towards a membership (contribution). Someone from your organization would need access to SSMS and would have to change the logic a bit, but it would be a good start for them.