TNEW + SUBs issues: handling packages w/o rollover

Hello, Tessitura braintrust!

We were JUST about to launch renewals and discovered what seems to be a pretty big issue that we flat out missed in earlier testing. (It's our first season on Tessitura, with all the COVID-related nonsense on top of it. What can ya do.)

Our standard year-over-year subscriber rollover went just fine.

But! There is another segment--essentially the subscribers who skipped FY21/COVID-season subs but whose seats we've retained--for whom we have manually populated renewal packages in their accounts. Today, we realized that (if we're reading the documentation correctly) the TNEW /packages/renewals page won't recognize them, since they weren't seated via the rollover. Not good! 

Are we missing something?? Is there a way to get them show up there? Failing that, any other ideas? Some sort of dummy performance scenario? Some way of tricking Tessitura into thinking they were rolled over?

Any thoughts would be greatly appreciated!

Hannah Grove-DeJarnett
Director of Marketing & Communications
Round House Theatre

  • Hannah,

    If anyone in your organization has SQL knowledge/database access, you should be able to make updates to the orders to do exactly what you suggest and sort of "reset" the orders which will "trick" Tessitura/TNEW into believing that they are rollover orders.  If you do not have that knowledge/access on staff, maybe someone with support would help with that?  It is not that difficult of an update to make.

    John

  • John,

    Thank you! That is very helpful and what I was hoping to hear. We don't have the SQL expertise in-house, but will take this suggestion to our consortium IT staff and see what we can figure out.

    Many thanks!
    Hannah

  • Hi John! Thanks for your reply. What do you mean by "resetting" the orders, and is this kosher? ;)

  • ,

    Well, I will admit, I cannot say that I ever asked if it was kosher, but suffice it to say that there have been exactly ZERO issues with it for us, and it seems to work just fine.  We used to have to do this for our custom site which handled subscription orders (pre-TNEW), so maybe that is why it never occurred to me that it might not be okay.

    In a nutshell, we found ourselves in the same situation as Hannah here.  For whatever reason, every season there seems to be at least one group of orders that we have to either manually create or manually edit after the rollover and, upon initial testing, after this creation and/or editing, they do not appear as renewal orders for patrons.  So, I literally just did the most obvious thing that occurred to me, I took a look at the order table for two orders, one normal rollover renewal and one manually created/edited and noted which columns were different (beyond the obvious, like customer_no, order_no, total_paid_amt, etc...) that could have possibly affected an order's ability to show as a renewal.  I updated them to match, and voila, it worked.  Nothing crazy, and, again, I did not ask, but I cannot see why there would be an issue with my doing that.

    FYI, the columns I update are as follows:  (I am not certain that all of these are necessary, frankly, probably just the two, but again, just for good measure, I went with the whole selection.)

    • solicitor = 'RollOver'
    • cno_req_ind = 'Y'
    • cancel_ind = 'N'
    • order_dt = NULL
    • accepting_rollovers = 'Y'
    • hold_until_dt = NULL

    My script is honestly as simple as declaring an order_no_str, throwing all the order numbers into there, and then making those updates on the order table where the order numbers are in that string, CHARINDEX-styles.

    John