Tips for front line users leaving batches held

Hi all, I know Tessitura does not recommend auto-closing or auto-posting of batches. We have multiple venues that the front line users close the batches at the end of the day, but do not post them. Finance does that the next business day. A couple of times we have had users leave their batch in held at the end of the day, then accidentally re-open that batch the next day and start using it again before Finance can get ahold of it. I'm wondering if any other front line/visitor services managers can shed some light on what they do to ensure all batches are closed at the end of the day. Thanks! Grant Offermann
Parents
  • If I'm not mistaken, the difference between a held and closed uncontrolled batch is fairly minimal — that is, it might just be the batch status column in T_BATCH. I would do a T-SQL trace to be sure that there are no other side-effects to closing a held batch, but if it does prove to be that uncomplicated, my approach would be to set up a database agent job to automatically close any remaining held ticketing batches at like 5am each morning.

    That hasn't been necessary at my org because our box office supervisor staff includes a check for unclosed batches as part of their box office closing procedure. So if your front-line ticketing staff always has a supervisor present at closing, you might look into granting those supervisors the manager right over the front line group so they have the ability to administer that group's batches.

  • Thanks for all the quick replies. Nick- I like that idea but I've been talking to Tess support and they do not recommend any auto-hold or auto-close scripts for non web batches. I'm wondering if I could put together a report that shows the current HELD batches. I could then schedule that report to email out nightly. Ill have to do some digging in the system tables to see if I can figure it out. We just have so many individual venues closing batches at the end of the day with only 1 Finance dept posting for all of them.
  • Former Member
    Former Member $organization in reply to Grant Offermann
    Hi Grant We have a report that lists all Open batches (for a particular Batch Type). Supervisors can run it at the end of a shift to check. Batches that are left Open are much more problematic than batches that are Held, and are the reason why TN recommends against closing them in the back end - which is itself basically simple (as Nick suggests, it's really just a matter of changing the status value on the Batch record) But if you Close or Hold a Batch in SQL which is still Open in a user session, and then that user continues working in the same session, the session will think that the batch is still open, and allow the user to keep transacting in it. It doesn't check.This will lead to Extremely Unfortunate Results. Which is why we would close a batch in the back end, but ONLY if the supervisor swears on a recent copy of a TLCC program that the offending PC (or RDP session) has been shut down in the interim, so that we know the session is no longer active. I've always thought that this was a bit of a Tess bug, but I also appreciate that having the session constantly checking to see if the Batch is still kosher would be a potentially significant performance hit. Ken
Reply
  • Former Member
    Former Member $organization in reply to Grant Offermann
    Hi Grant We have a report that lists all Open batches (for a particular Batch Type). Supervisors can run it at the end of a shift to check. Batches that are left Open are much more problematic than batches that are Held, and are the reason why TN recommends against closing them in the back end - which is itself basically simple (as Nick suggests, it's really just a matter of changing the status value on the Batch record) But if you Close or Hold a Batch in SQL which is still Open in a user session, and then that user continues working in the same session, the session will think that the batch is still open, and allow the user to keep transacting in it. It doesn't check.This will lead to Extremely Unfortunate Results. Which is why we would close a batch in the back end, but ONLY if the supervisor swears on a recent copy of a TLCC program that the offending PC (or RDP session) has been shut down in the interim, so that we know the session is no longer active. I've always thought that this was a bit of a Tess bug, but I also appreciate that having the session constantly checking to see if the Batch is still kosher would be a potentially significant performance hit. Ken
Children
  • Hi, We also had this issue where batchs were sometimes re-opened and used the following day. We implemented a solution where we have a script that runs each night and updates the owner of the batch to a designated Finance user. With the owner chagned the box office cant reopen the batch. Also, the Finance user can then close the batch the next day. This script also sends an email to the Finance user with a list of the batchs as a reminder and notification. Since implementing this a couple of years ago we have had no problems. I can post the script if anyone wants? cheers, Dara
  • Dara, This is exactly the kind of solution we are looking for. Would you mind emailing me with more info at grant.offermann@mnhs.org? I'm not too familiar with the tessituranetwork site but maybe there is a place you could post the script on here as well. Thanks for all the responses also. We are rolling Tessitura out to 6 more historic homes/museums across the state of Minnesota this year and are trying to make it as smooth of a process as possible.