Ticket History from v11 to v12

Hi Ray,

We haven't gone Live with V12 yet but I have been working with it in our Test environment. We also have many years of legacy data that we didn't want to disappear. My solution may not be the most elegant one but it seems to do the trick.

Basically, prior to the upgrade process I put all of our legacy ticket and package data into new local tables (one for each). I performed the Standard Ticket/Package Upgrade provided by Tess. After this was complete I inserted the data from my local tables into the new Ticket and Package history tables.

That being said, there were a couple things I noticed and questions I haven't answered yet (so I'd love to hear what others are doing as well!):

1) As long as I've been on Tess I've been told to NOT mess with tables that aren't local. So naturally, I have hesitation with simply adding our legacy data to the new Tess table structure. On the other hand if I create new local tables I have to create new local procedures to update those tables and mess around with InfoMaker to point to the new tables. I'd also have to re-point all of the new Ticket and Package history list/output set criteria to the new tables. It sounds unpleasant. Have any Live V12 organizations dealt with this issue? Did you create new or stick with the Tess supplied stuff?

2) The new ticket and package history tables have additional columns. Some of which will not accept NULL values. So you have to add those columns to your legacy data holding tables with some sort of generic value before you can import it to the new history tables. For package history I believe the only new required column is Role. For ticket history it requires order_no (can be 0 but not null), role, theater_no, MOS and pkg_no (again, 0 is appropriate).

I think that covers what I've noticed so far. I'd love to hear from other organizations (especially if they have a much better way of doing it!) and am also happy to chat more about the method I tried if anyone has questions about it.

Hi guys

We haven't looked at it in detail yet, but our first thought is that we would keep our existing, heavily customised, ticket history, and not move to the new standard ticket history at all. I believe that's possible, although strongly un-recommended. We would add the new role-y stuff into our localised version, as per the What's new notes:

NOTE: If you do not use the new, standard histories, you will need to update your customized histories to include initiator and recipient data if you want that data to be available for lists and extractions. Some instructions and examples for updating custom histories will be included in the v12 upgrade documentation.

Apart from legacy system data, we also have a lot of imported external venue and agency sales, which we bring in on an ongoing basis, and for them we keep a chunk of specialised data, plus some other very local fields (for example a field which marks a sale record as available to SOH for marketing purposes, a legacy of a complicated contract change that didn't mesh with Tess ways of doing things.) 

So I don't think we have any option other than to modify our custom tables to work with the new v12 stuff, and continue to use them. We'll see how we go.

Ken

In general if you are planning to adopt the standard ticket history, as we reccomend, then I would plan to convert your legacy data from your old ticket history to the standard history table.  This would be similar to the process that you would use when you installed Tessitura originally.  As long as you are mapping similar columns from your old ticket history to the standard ticket history the conversion should be fairly easy.  If you would like some advice or assistance feel free to contact our consulting department to discuss the options; they are available to give you advice on how you might move your data and/or to take on the project for you.

Best,

Anna

In general if you are planning to adopt the standard ticket history, as we reccomend, then I would plan to convert your legacy data from your old ticket history to the standard history table.  This would be similar to the process that you would use when you installed Tessitura originally.  As long as you are mapping similar columns from your old ticket history to the standard ticket history the conversion should be fairly easy.  If you would like some advice or assistance feel free to contact our consulting department to discuss the options; they are available to give you advice on how you might move your data and/or to take on the project for you.

Best,

Anna

Hi folks

Having looked at some more detail on this - I would like to move to the new standard ticket history, particularly because I assume that Tess will continue to develop new functionality based around this model; but I can't see how we could do it, and maintain our ability to import external ticket history. 

The ideal solution, obviously, would be to import orders instead of ticket history, and that's certainly a target, but may be a lot of work away for some non-tess venues, and won't work for existing non-tess data in any case.

One way to enable us to keep using our existing local functionality, but still use standard tables, would be for Tess to extend the table with a clutch of custom fields that sites could fill with whatever data they needed - say

• 10 varchar(50) fields called text_0 through text_9; 
• 10 int fields called int_0 through int_9, and 
• 10 datetime fields called dt_0 through dt_9, 
• plus a hook in the update proc to call a local proc to fill them. 
• Maybe some other data types (Money?) as well. 

Presumably they wouldn't be visible in the history screens, but we don't really care about that, I think - they're mostly used in List elements or reporting, or just for admin purposes.

Does that sound possible? Is that a v14 enhancement request? What does Anna think?

Just as a f'rinstance, these are our current fields that we wouldn't want to do without:

• [hist_source] [char](1) , whether the data came from Tess, one of the legacy systems, or an import ,
• [Source_no] [int] , Tess source number (sometimes we get that from external venues)
• [Hist_Source_System] [varchar](50) , The alien system that we imported from (eg "Enta - QPAC")
• [Hist_Source_Cust_id] [varchar](50) , the customer's id in that system
• [Hist_Source_Description] [varchar](50) , a description of the particular import ( eg "ACO 2014 Tour 2 QPAC")
• [Import_Session_id] [int] , link to the specific import session
• [Hist_Source_Row_id] [int] , and the row in the import data
• [soh_access] [int] , the funny one for SOH access purposes

 

 

I've started to think about how we can move back to the standard ticket history table as we migrate to v12, and so far my plan is to create a separate table as an extension to the standard table, to hold the columns that we want that are extra. That way we can use the standard tables and functionality that Tessitura provide, but also report out on the extra bits when we want to.

Christine

Having dug into this a bit more, I agree with Ken re: "mov[ing] to the new standard ticket history, particularly because I assume that Tess will continue to develop new functionality based around this mode", and also agree with him re: adding some "standard custom" columns to the new history tables, much as they are in T_ORDER and T_CONTRIBUTION, would be a good idea, as he described below:

Unknown said:

• 10 varchar(50) fields called text_0 through text_9; 
• 10 int fields called int_0 through int_9, and 
• 10 datetime fields called dt_0 through dt_9, 
• plus a hook in the update proc to call a local proc to fill them. 
• Maybe some other data types (Money?) as well. 

In our case there is unconverted, historical data from a legacy ticketing system that will never have Tessitura perf_no's or price_type ids, for example, but could be fit into the standard history table if it had the columns described above.