I'm trying to create a subscription report that can be easily pulled by coworkers who do not have TStats. The canned reports just aren't coming close to the figures TStats shows us (mostly because of flex packages).
I've found that the LT_Sub_Hist (or LVS_Sub_Hist) table is the closest to the totals TStat generates. Obviously, I'm here, they aren't exact. There seems to be a few cancelled/returned orders that are throwing numbers off.
For example, TStats says a Friday Evening Full season package should have $90 more in sales than is reflected in LT_Sub_Hist. I've been able to track down the patron and found that they had a single subscription that was returned and another double subscription was purchased with the money from the first in a different order.
I feel like it isn't correct for TStats to include this extra $90, but maybe it's meant to? There are a few additional cases I've been able to find that are similar situations (a returned order accounting for discrepancies) but I haven’t been able to account for everything.
Should TStats be include orders like this? Is it supposed to be the most accurate result? How accurate is LT_Sub_Hist really?
Thanks!
Hi Ashley,
T-Stats isn't designed to tie out to lt_sub_hist, or any of the ticket history tables. Most organizations have their conversion data in the history tables, and T-Stats, by default, only includes real orders. It can (and has been) customized by many organizations to also include conversion data (from history tables) but it does not do so by default. Likewise, even for the live orders T-Stats does include by default, it is not retrieving that data from the history tables. It's retreiving information from the lineitem and sub-lineitem.
In terms of your $90 question, it depends a lot on how you constructed your report in T-Stats, and the timing of the activity. T-Stats is not live, it is refreshed over night so there will often be small differences in reporting due to activity taking place in Tessitura since the load. History is also not live, but depending on your setup, may be refreshed more frequently than T-Stats is. Additionally, if you're looking at the Packages cube, it's important to keep in mind that a Package is not necessarily synonymous with a Subscription. The Packages cube does aim to quantify sales at the package lineitem level, whereas, for example, if you exchange a subscription ticket out of a package into a new performance, you might still use a subscription price type category prce type, but the new ticket would no longer be part of the package. The Packages cube does have a number of measures that deal with the original amount in the package vs the current value of the package. If you're using a localized subscription history, it may not be calculating value the same way the Packages cube would. It may be referring to subscription-categorized tickets, rather than explicitly packages. Neither is necessarily inaccurate, but they may have been programmed to reflect different things. Since you're using a local history table, I can't comment on its logic.
In general, we recommend using the following recipe to match packages in T-Stats to a standard Tessitura report: http://www.tessituranetwork.com/Community/groups/tstats/wiki/matching-package-sales-report-to-t-stats.aspx
This article also explains a different standard report that will not match, and why: http://www.tessituranetwork.com/Community/groups/tstats/wiki/why-doesn-t-t-stats-match-the-package-order-listing-report.aspx
If your goal here is to create a custom report for non-T-Stats users but that does match T-Stats, if you're creating a custom SSRS report anyway, you could use either the TStats data warehouse database, or the T-Stats SSAS database as the data source for your report. Then it could be run the users or scheduled to be emailed to them like any other SSRS report.
HTH.
Thanks for the responce, Amanda! Luckily, I'm working with data from 2014, so nothing should be changing over night.
After some additional digging, I think I might have a hickup of some sort that I haven't been able to find yet. Neither my original TStats report nor the one I built from "Matching Package Sales Report to T-Stats" match any of the data that comes up in the Package Sales Report (though, both T-Stats reports match, so that's good).
I wasn't here during our implementation, so I'm going to ask around if there was any customizations done anywhere.