Unpaid Orders and Ticket History-based lists/output set elements

In smartening up the deferred payment set up for our School ordering system from the Finance perspective, we have realized we face a new challenge: unpaid orders do not generate Ticket History. 

Obviously there are many ways to see sales and who's coming to what in Tessitura, but most of our commonly used queries for Extractions and List Manager rely heavily on the Ticket History set of elements--and it's integral to many Output Set elements as well. I understand *why* there's no Ticket History until an order is paid in full, but this isn't logic that is going to help convince teachers pay sooner. Some of them absolutely deal with balances by passing along the kids' plastic baggies of pennies as the groups stream into the theater. In particular, I'm concerned about how I continue to run accurate performance reminders in advance.

Off the top of our heads here, we're thinking we're going to have to commission new Extraction/List/Output elements that instead look to Order details, assuming that's possible.

Has anyone seeing this tackled this general challenge already and have ideas/advice to offer? Thank you!

Jamie O'Brien
jobrien@new42.org
Assistant Director of Digital Services
The New 42nd Street

  • Former Member
    Former Member $organization

    Could you pay off the orders using an invoice? Then the tickets would show as paid so they'd generate history for your extractions and output sets. 

  • Thanks, Dorothy, for the thought. Unfortunately, the whole benefit of the switch from the financial perspective is that we do not have unpaid orders showing as paid.

    Worked great for communications the last two years, but wrecked havoc on show closes!

  • Perhaps you could approach from the other direction and build a custom ticket history update procedure to run? It looks like the canned TP_UPDATE_TICKET_HISTORY pulls in SLIs with statuses of Seated/Paid and Ticketed/Paid, so perhaps it could be tweaked to pull in Seated/Unpaid lines as well. Might be a cleaner fix than delving into new custom elements, as long as everyone's on board with Ticket History data behaving a bit differently!

  • Hm, I realized this sort of tweak may have further implications, especially around rollover time when a ton of new seated/unpaid orders may get created. Perhaps you'd only want to pull seated/unpaid SLIs into ticket history within a specific MOS that school orders use, or some other similar filter?

    I'm speaking more from speculation than experience, so hopefully someone with more SQL chops will give a shout if there's any huge pitfalls down this line of thinking!