Our accounting software requires us to breakdown which GLs are being credited when posting revenue to a bank account. For example, if $1,000 was debited to the cash bank account GL number on the Tessitura Posting report, which GLs were credited to total the $1,000 (e.g., ticket sales, annual fund, fees, etc.). Same is true for our credit card bank account GL number.
Unfortunately, none of the standard reports provide this level of drill down and I haven't yet been able to figure out how to write a custom report that will either. Any guidance is greatly appreciated. Thanks!
Someone else should confirm, but I believe this is not possible. That is, there is no hard link between an individual cent taken as payment, and the revenue line to which that cent is assigned.
This makes a little bit more sense when you think about how order payments work. If I have three products in my order with three different GLs, and I pay off that order with a combination of cash and card, nowhere in the client do you say that payment x is for product y. Instead, the products put the order value out of balance, and payments bring that balance to 0.
Of course, 90% of the time you can guess accurately: If an order only has a single payment, then you can unambiguously say where every cent of that payment is assigned. But, if more than one payment occurs, it becomes ambiguous which payment is for which product. Deciding how you will deal with that ambiguity is why this is a custom reporting issue and not built-in.
Hi Sara et al
Actually, it is theoretically possible to associate particular payments with the specific items they paid for, sort of.
When you take partial/multiple payments against an order, Tess applies the payments to actual items on the order in a specific sequence. (I don't recall what it is, but it's documented somewhere.) You can recover the associated payment/order item/s by linking at the transaction sequence / payment sequence / (sli detail/fee/contribution) level.
But it's a bit random - you have no control over which payment pays for what - and the code needed to pull the data reliably is not for the faint-hearted. The linking is not intuitive, and gets pretty complex. And there are a couple of caveats, as usual -
If my finance system insisted on that explicit link being made, I'd be looking for a new finance system, I think. It's unpleasantly inflexible, and not the accounting-correct way to do things. But I suppose that's not an option for you, Sara?...
Ken