Hi all -
I'm testing some processes here to use a pricing rule to upsell someone who has bought tickets to two distinct performances a third show which we then convert into a 3 show package. I can get through the order steps just fine - but when I try to print the order (to test exchanging them and such) i get the attached error.
Anyone know if this is a proc i need to call after updating the order to get some table I'm not seeing in synch with the updated order? Any advice is appreciated. Thanks!
How are you turning the single tickets into a package?
I created a new lineitem with the appropriate information needed, inserted it into the order (T_LINEITEM), updated the existing lineitems to reflect the new information then updated T_SUB_LINEITEM with the new package numbers. T_ORDER didn't look like it needed any updates but I'm also getting the error so maybe there's something I'm missing there?
Ah, so is this a SQL Stored Procedure or the like making these changes? I think there's a lot more going on behind the scenes with order creation than just the handful of tables we usually go to for reporting after the fact. Have you looked at what the TP_UPDATE_ORDER_TOTAL and TP_UPDATE_REAL_ORDER_TOTALS are doing? There might be a hint there, but I'd still be worried that there might be other obscure items that might not get set correctly but aren't being checked. This is definitely do-able: we commissioned a TNEW customization that was effectively taking single ticket reservations and transferring them into a package, but I've never learned enough about that process to be comfortable doing it myself.
It is indeed. It's just testing to see if it can be done and I'm sure there's got to be more to it or TNew would have done it already. I'll comb through the procedure to see if there's anything in there I can decipher but i was sure someone has either tried this already or just flat out done it. Thanks!
As I say, I know that Tessitura Consulting has (for us at least), and probably some other community members have. Do you have access to the developer's Slack channel? That might be another place to bring this up.
One piece of advice I know you'll get is to turn on a full trace in your client, take the actions you want to mimic (i.e. buy a package), then read through the trace for all the stored procedures being executed, then check out what each of them is doing.
Seconding this approach by Gawain Lavers. There ARE ways to add things to packages using SQL; I have a customization of my own that uses some of the stored procedures in that way. But every step of mine definitely uses the procedures that were written by Tessitura and are called as part of the normal carting processes. Manually adding to/editing/deleting the line items and sub line items in the database with a procedure that I write myself still scares the heck out of me, and I have been shaping our database for a decade now.
I hear you. After going through the procedure that was erroring out I discovered that once my proc was done, the T_SUBLINEITEM table entries changed from paid to unpaid (the paid_amt column data was reset to zero) which is causing the order to show paid while the sub_lineitems in it show as unpaid. Not sure why T_SUB_LINEITEM would update paid amounts when the table isn't touched in my proc but I'm going to test it a few more times to confirm that for whatever reason, updating T_LINEITEM seems to reset T_SUB_LINEITEM payment amounts...
Might have to do with the relationship between T_SUB_LINEITEM and T_SLI_DETAIL.