Web Subscripton Rollover Order

The ability to change the MOS in an order after line items have been added is a securable object (Ticketing Change MOS is the name of the security object).  I believe that it is turned off by default.  If you have the appropriate security rights, though, you can change the MOS once line items have been added to the order. 

When you change the MOS there are a few things to keep in mind.  Everything currently in the order (packages, prices, etc.) must be valid in the new MOS.  The one that trips people up is delivery method.  Modes of sale and delivery methods are associated in the TX_MOS_SHIP_MEHTOD system table, but the Hold at Box Office delivery method is always displayed, whether or not it is associated with the MOS.  When you change the MOS, though, if the Hold at Box Office delivery method has not been explicitly associated with the new MOS it will give you an error.  The moral of the story is, if you are going to let people change the MOS on orders after line items have been added, make sure all your delivery methods are associated with all of your modes of sale.

Personally, I think Channel is the best option for tracking how a renewal was processed.  First, that’s the intended purpose of the field.  And second, it’s a required field so your operators can’t forget it.  So you would set up a Web Subscriptions MOS, which you’ll use for the Rollover, and not set a default Channel for that MOS.  If the order gets renewed on the web, the API will select the default web channel.  If it’s processed by a person, the operator can select whichever channel is appropriate; if they forget to pick a channel they will be reminded when they attempt to save the order.  Changing the MOS works pretty well (if you have everything set up), and may be better depending on the type of reporting you want to do, but nothing is going to remind the operators to make the change.

The ability to change the MOS in an order after line items have been added is a securable object (Ticketing Change MOS is the name of the security object).  I believe that it is turned off by default.  If you have the appropriate security rights, though, you can change the MOS once line items have been added to the order. 

When you change the MOS there are a few things to keep in mind.  Everything currently in the order (packages, prices, etc.) must be valid in the new MOS.  The one that trips people up is delivery method.  Modes of sale and delivery methods are associated in the TX_MOS_SHIP_MEHTOD system table, but the Hold at Box Office delivery method is always displayed, whether or not it is associated with the MOS.  When you change the MOS, though, if the Hold at Box Office delivery method has not been explicitly associated with the new MOS it will give you an error.  The moral of the story is, if you are going to let people change the MOS on orders after line items have been added, make sure all your delivery methods are associated with all of your modes of sale.

Personally, I think Channel is the best option for tracking how a renewal was processed.  First, that’s the intended purpose of the field.  And second, it’s a required field so your operators can’t forget it.  So you would set up a Web Subscriptions MOS, which you’ll use for the Rollover, and not set a default Channel for that MOS.  If the order gets renewed on the web, the API will select the default web channel.  If it’s processed by a person, the operator can select whichever channel is appropriate; if they forget to pick a channel they will be reminded when they attempt to save the order.  Changing the MOS works pretty well (if you have everything set up), and may be better depending on the type of reporting you want to do, but nothing is going to remind the operators to make the change.