1) A report linking payment types to shows.
Which boils down to: directly linking individual payments to individual tickets.
Oh, I understand why a finance dept might ask for it. Especially a finance dept that usually deals with invoices and BACS payments. This ticket has been bought, so it must have been paid for. Which payment paid for it?
But.
It is possible to have a mixed basket with split payments.
I know that it hardly ever happens, but it's designed into the system, and I can't take it out, and I can't do anything that's fundamentally incompatible with the fact that you can have tickets for Show A and Show B in an order, and pay for them with Payment 1 and Payment 2 of different payment types.
If I have an order with 2 tickets for Sooty in Space (£10 each) and 2 tickets for The Importance of Being Ernest (£15 each) totalling £50, and it's been paid for £5 gift voucher and the balance (£45) by card, there isn't an easy answer to the question "Which ticket was paid for by the gift voucher?".
The only sensible thing to do is split the gift voucher between the shows based on face value; £2 to Sooty and £3 to Importance. So the £45 of card payments is assigned £18 sooty and £27 Importance.
Suppose now we cancel the Sooty tickets and refund £20 back to the card.
Suddenly the proportions have changed. The £2 of gift voucher that was paying for Sooty is now paying for Importance tickets: our original assignment must have been incorrect, and we now need to go back and change it to £20 card against Sooty (so that we can refund it) and £25 card + £5 gift voucher against Importance.
The means that that amount of money in the "credit card income" column for Importance has gone DOWN, as the result of an unrelated cancellation. No Importance tickets have been cancelled, and the promoter of Importance might be very strict about not allowing refunds, and is going to need a lot of explanation as to why their numbers have retrospectively changed.
The only way I can see to actually make this work is to treat every single ticket like its own account ledger. There's a £10 debit on the Sooty ticket and then a £9 card credit and a £1 gift voucher credit, and then for the refund there's a £1 gift voucher debit and a £1 card credit (matching with the Importance ticket, so the first phase of doing a refund is doing an internal transfer between one ticket and another) and THEN a £10 card debit and a £10 cancellation credit, leaving the ticket's account balanced a £0. I've seen a bunch of ticketing system databases in the course of doing data conversions, and no one does anything as mental as this.
How does everyone else handle this? Should I just stop whinging and just split every payment down to every ticket?
The ticketing system we use (AudienceView) certainly does have built-in reports which gives a breakdown of payment methods by event. I didn't think this would be that hard to build. Payment simply gets allocated (either full or partial or not at all) to each item in the order, then gets reallocated when changes are made to an order.
ReplyDeletePerhaps I just have to do it then.
ReplyDeleteIt's just that my fundamental unit is the order. Orders have tickets and orders have payments and any report that runs on a whole order can have payment type breakdowns in it, but splitting the order is hard work.