Directly and Distinctly Relate Payments and Ticket Layers.

Dear All,

Our Finance department has asked me to do the one thing that you never want to do and tie every payment to every ticket layer part of every ticket so that you can run payments against a performance at any specific pricing level or levels and know exactly how much revenue goes to each payment method for the ticket level or the facility fee or what have you.  I tried to tell them that this is a bad idea because if you are, for example, halfway through the season and half of the performances have already passed and you have reported on them, the payment methods for the money going to those performances can still change if a patron calls in, their subscription order is loaded and that patron just adds one more ticket to that order because the money will shift around a bit.  But they still want to be able to run this anyway, so I am at least trying to do it.

Anyway, I have gotten very close.  I am able to link things such that all direct payment methods are accounted for 100% exactly.  The problem is exchanges (because of course).  And specifically the real issue is caused by those exchanges where there is a change between two performances but there is no payment because the prices are equal.  To sum it up, the performance number does not get updated in T_TRANSACTION because there is no change in T_PAYMENT so you have a transaction originally assigned to and maintaining performance # 1 in the table while the transaction revenue itself has actually shifted to performance # 2.

If you have any ideas and/or would like to see the code I have thus far, let me know!  I would be just fine to go back to the Finance people and tell them that it is impossible, but I said I would try, and thus here we are.

Thanks!

John

Parents
  • Now...don't get angry at me for suggesting this...but....you could adjust the way you process exchanges (except for web exchanges of course). You could exchange out the ticket and put that money to an on-account payment method called Exchanges or something and then click done on the order. Click load last order, go back in and then add the new performance and pay it with the on-account payment method. This would than give you distinct transaction with a "payment" attached to the exchange. I know that's not optimal but if that's what your finance team is asking, it is an option. This would not affect web orders, unless you want to create some really crazy interceptors and code that do all that work for the transaction.

    - Chris

  • No anger, but yeah, there is pretty much zero chance our Box Office and/or Finance department would go for that, and I cannot say that I really blame them.

    For the time being, I am more than happy to accept Emily's response of "not possible" as the answer.

    John

  • As she points out, Tessitura doesn't track pennies through the system.  Money goes into buckets and comes out of buckets.  I think maybe some systems require a single payment for each transaction, but Tessitura necessarily has to accept multiple payment types on one purchase (i.e. credit card and gift certificate).

    This also means you have to be very careful about reporting on payment methods, as you can quickly get inflation when more than one payment method maps to a single order.

Reply
  • As she points out, Tessitura doesn't track pennies through the system.  Money goes into buckets and comes out of buckets.  I think maybe some systems require a single payment for each transaction, but Tessitura necessarily has to accept multiple payment types on one purchase (i.e. credit card and gift certificate).

    This also means you have to be very careful about reporting on payment methods, as you can quickly get inflation when more than one payment method maps to a single order.

Children
No Data