Web sales and their default source

The source associated with the transaction would  still be the future season/campaign's source, even if you changed the source on the order. Of course, you could change the source on the transactions as well when you update the orders' sources. I am assuming in this scenario that you'd be running some sort of scheduled job that'd make the change regularly enough that you wouldn't be undoing any potential later, intentional change to the source that should not affect the source on the initial transactions. Subsequent transactions in the orders (after changing the order's source) I believe would use whatever source the order has at the time of the transaction. So it wouldn't require future upkeep after the initial fix.

Our marketing folks want to go out with a pre-sale open to the public on our first show of next season, which is obviously in a different fiscal year than what we're selling now. We use different source codes (based on season/FY) for the relevant entry in T_DEFAULTS, and as far as I know there is not a way in Tess to send different sources to the API to send back in an order.

Assuming that's correct, the harebrained scheme I'm thinking of involves changing the web source in T_DEFAULTS to that which we'll use for FY11, and run an Update statement on the orders containing the remaining FY10 perfs which changes the number in T_ORDER.source_no to reflect the older web source (making it the correct one relevant to the season.

My question is, are there any ramifications to changing source_no? Does that element get populated to anything else that would throw a firecracker into financial reporting or the like?

Thanks to all.

Thanks Amanda.

To follow-up: So if I included the source_no from T_TRANSACTION as well as T_ORDER when the update script  runs (yes, I'm thinking of a nightly procedure), that would resolve any potential reporting issues? (Sorry if I'm being redundant - parts of this is new ground for me, so I just want to be DoublePlusCertain.)

Why not use the API methods UpdateSourceCode and UpdateOrderDetails for that specific performance?

Yes, that should work. If you run the Revenue by Source and Appeal report there's also a parameter for Mode, the options being the order/cont source vs the transaction's source. So if you had doubts about mismatches, if you run that in both modes and see a difference where you don't expect one, you know right then.

The other issue to keep in mind is t_promotion. When the order goes through with the source the web gives, it'll record a response of order processed for that source. Changing the source won't remove that response in t_promotion. Any subsequent activity in the orders after the source change will trigger ANOTHER response in t_promotion for the new source, but the other won't go away. So reporting based on t_promotion would be skewed, unless you fixed that, which is a bit trickier because some of those people might have orders that need changing as well as orders that rightfully should have the future source  and you don't want to remove that from t_promotion.

So then you have the issue of making sure t_promotion is in sync with the changes you made so when your appeals are summarized the num_success are accurate.

Can a source code expiration date be used over more than one fiscal year, having the campaign and appeal from the previous fiscal year....or do I have to build all new source codes every year?