Version 6.74.06

Theatre Manager will

• Reorganize the database
• Find all patrons with updated their own account via the internet and add in any events to the 'bought for event' list that are not on that list.

The user will need to

Credit Card Authorization

The CID or CVV2 numbers have been optional in prior versions of Theatre Manager. You would only get a discount from your service provider if the numbers were entered and you were using PC charge for credit card authorization.

In this version, you can now specify if the CID/CVV2 numbers at the back of the credit card must be entered - on a credit card by credit card basis. If only your Visa/Master cards require the CID numbers, then you can specify that they must be entered and then they will be ignored for other cards.

NOTE: making the fields mandatory only forces them to be entered in Theatre Manager. They will then be sent along with the card for credit card authorization. Theatre Manager is fully PCI compliant - meaning that it does not store the CID information in the database (and it does save cards in encrypted format). Because of this, you can only receive a discount if you authorize cards at time of payment. You will NOT receive any benefit from entering the CID/CVV2 number if:

• if you take a credit card for later authorization because the service provider is down at the moment
• the payment is a post dated credit card payment for ongoing donations -and/or-
• your service provider is not certified for CID/CVV2 with PC charge (you may need a later version)
• or, you are still using PC authorize.

NOTE: you may still receive a discount if the address information and zip code is sent and you get an address match.

NOTE: your service provider, if they do not accept CID/CVV2, may give you an error or a decline on the credit card authorization. If this is the case, turn the CID/CVV2 mandatory field for that card OFF and contact your service provider to ensure that they accept that information.

NOTE: if you elect to make the CID/CVV2 number mandatory, it will ALWAYS be required on the web site for that card. If it is not entered at the box office, the user will be forced to get permission from a supervisor who can accept cards without the CID number. This is a preference in employee data.

Turning on 'CID/CVV2 required' edit

To make CID/CVV2 mandatory for any payment method that is credit card, go to Setup->System Tables->Code Tables and edit each credit card. Near the bottom, there is a checkbox (set to NO in this example) that says 'Require CID/CVV2/CVCS'. Please set that to yes for the cards that accept this information.

Payment Window

The payment window will show the field for CID/CVV2 entry if it is accepted for this card. The first picture shows what a portion of the payment window will look like when the CID number is accepted for the specified credit card.

If the card does not accept CID information, it will appear as below. If you see this, please follow the instructions for turning on that CID is mandatory and accepted for a card.

Employee Window

You can allow a user to optionally enter CID information when it is required for a specific credit card. To do so, they must have the privilege highlighted below 'Payments-allow empty CID even if required for card'. This is only applicable for sales at the box office (sales on the internet require the CID is specified for the card).

Web Sales

• Addressed an issue where if a credit card timed out on the authorization process, the web listener could behave unpredictably after running for sufficiently long time.
• Properly addresses the email to the patron or the spouse's email address, depending who was buying - in the case where the spouse and the patron have both email addresses on their patron record.
• fixed a potential issue updating data on the patron record from the web site.
• If the user enters an invalid card number or bad CID number, the card information remains on the screen.
• Fixed an issue where the 'patron bought for events' was being reset incorrectly when a patron updated their own patron record via the web.

Web Sales Holds

• Added a hold expiry date to tickets sold on the web. We now tag each seat held on the web with a future hold expiry date and the cart that the ticket was held under. The web release seat routine still checks for shopping cart timeout as a preference to releasing seats. However, should a seat get missed by this routine, it also checks for seats that have gone past their 'hold until' date. If it finds one, it checks the shopping cart to see if the patron is still active. If they are, the seat is kept, if not, the seat is released. This timeout is set to 60 minutes, or 4 times the shopping cart inactivity timeout; whichever is greater.
• The hold status message on the sell window and the play & dates window has been enhanced. If the ticket:
  • is a normal hold, the message simply reads that the seat is on hold.
  • However, if the seat was held by a patron purchasing on the internet, the message is augmented with the current cart number, status, patron and when the ticket hold is to expire. If this is a
    • future date and the cart is any one of the active status codes, then you can assume the hold is still valid.
    • However, if the hold expiry is in the past and the cart is not active, you can probably usurp the hold for your own use. A seat could be in expiry in the past if you've closed down web sales for any reason and it is no longer scanning for expired holds.
      
      
• Releasing expired holds can be done in three ways:
  • You can manually sell that hold at the box office by 'option/ctrl-clicking' the seat and sell it right way.
  • You can start up the web listener and it should release any past due (expired) ticket holds
  • You can go to Default Data on the web tab and there is an additional button. This is called 'Clean Up Expired Holds' and will perform the exact same function that the web listener would do on startup. It is here for convenience in case you do not want to start up the web listener.
    
    Note: The clean up of expired holds will never affect a hold placed by the user recently and where the date on the hold is in the future.
  

  Re-Processing Credit Card Batches

  • If, for some reason, at the credit card server, you delete the credit card batch information completely for the current batch, you can now reset the authorization status on all pending credit cards for that merchant account - and then reauthorize those cards in end of day process. This can only be done if:
    • your merchant account setup is 'terminal capture'
    • you are using a master user account or outlet administrator
    • you are sure the credit card data is not present in the batch information.
    • and your service provider does not have that information held on their servers as well
  • Examples where this may be used is:
    • your batch totals for the day is empty and you know cards have not been authorized
    • you are using Global Payments as a merchant provider and authorization that is over 7 days old has rolled off their server -and- you were able to balance the recent authorizations to batch totals - but the old information was not authorized.
  • Resetting the card information is done by going to Setup->System Tables->Merchant Providers as a user with permission and clicking on the 'Reset Authorization Status' . You will need to confirm approximately 5 dialogs to ensure you want to do this. (This is a scenario that should almost never happen - never -and so this procedure should almost never be done).

  

  End of Day Deposits

  • Changed the maximum batch number that Theatre Manager can handle to a 17 digit number
  • Provide correct batch settlement response for NOVA processor systems that provide a numeric batch response
  • Changed the order that 'Transfer of Deferred to Earned' postings occur to address an issue with outlet version posting
  • Fixed a bug where the incorrect date could have been used for rolling over deferred to earned revenue. It now uses the date entered by the user for sales postings.
  • Added some more descriptive notes to each of the GL entries, especially for outlet version.
  • Fixed an issue in outlet version posting where an A/R entry could have been erroneously created for a transfer of deferred to earned revenue (outlet version only)
  • Fixed an issue where the EOD would erroneously report that it was in use. This would only occur if the user had disabled all their merchant provider accounts completely and tried to go into end of day and received the message that 'there were no merchant accounts'. The flag EOD in progress flag was left set inadvertently.

  Thermal Ticket Printing

  • printing tickets for any order that is set for 'reservation only' will now clear the flag and the tickets will be posted in the next end of day. The reason for this change is that any tickets printed for a customer indicate that they now owe you something for the tickets.
  • When printing a batch of tickets from the 'attendance' tab on play & dates, the ticket printing options dialog (asking for ticket cutting, receipts, address tickets, etc.) is now displayed by default to make it easier to manage will call ticket printing.
  • Fixed batch printing tickets from the play and dates window so that it now cuts tickets and prints credit card receipts properly.
  • Revised ticket printing options to support specific IP based ticket printers.
  • For IP ticket printing,on specific printers, Theatre Manager tests the status of the printer and will return a diagnostic to the operator if there is an issue with the ticket that is about to be printed (e.g., out of tickets, not turned on, not in proper state, ticket jamb, etc.)

  Year End Rollover

  • For year end rollover, added a feature to speed up the process if done in single user mode. To invoke single user mode when doing the rollover, you will need to hold down the 'Option', 'Shift', 'Alt' or the 'Ctrl' key PRIOR to invoking the year end rollover. If you do so, you will get asked if you want to do it in single user mode. Doing so means no other users will be allowed to log on. We recommend only doing this on the server.
  • Fixed an issue with the consolidation of GL entries older than 5 years. The description of the GL entry was incorrect by one month. It is now fixed.
  • Subsequent to the fix above (version 6.74.05) the consolidation of year end entries older than 5 years no longer happens. This also means that transactions associated with the G/L entries are no longer archived automatically. This then means that the year end rollover should be faster than in prior years because it is doing much less work.
    
    Why this change? We made it for two reasons. First, in anticipation of version 7, we can keep transactions for much longer without affecting the performance of the database. Size is also no longer an issue in version 7. We had heard from a number of clients that they wished transaction and ticketing data saved for much longer than just 5 years - and this has been accommodated. Note: if your database is getting full now, you may need to archive some events, even though version 7 is just around the corner.

  Misc Changes

  • Changed the behavior when creating the TMDB.txt file during startup to make it more friendly for users on OS-X with multiple login id's set up on a machine. If the file exists, it is now emptied and then updated, instead of being deleted (which would reset the permissions on the file and affect other users).
  • Some changes to address a redraw problem on the patron screen and show proper data.
  • Addressed crash when person starts TM on a PC and then clicks quit on the logon window without logging on
  • Added the address verification and CID verification responses to the transaction detail window
  • Added a new report that prints all the address verification responses for payments taken in a time period. This can be used to verify if you are receiving the proper credit card discounts from the bank.
  • Added a separate date format for all letters being merged. During the update, this defaults to a long form of a date like 'December 25, 2005' and can be changed by going to the 'Misc' tab in default data.
  • Fixed a display issue on the G/L entry detail window where the account number would only show the first 8 digits if the column was expanded.
  • Fixed an issue in the dialog that allows a user to give permission to another user to performa a task. All passwords in this window were being converted to upper case by accident - which affected those sites that are using mixed case passwords. This is fixed. For sites that only use upper case passwords, any text entered is set to the proper case so that they do not need to hold the Cap Lock key down - in other words, they should not see any difference to how TM behaves.
  • On some revenue reports where we put the price codes on the report in columns, we've added a small feature that lets you pick the price codes that you want displayed. This is valid for any of the revenue or ticket count by price code reports (affects 9 reports in total). The data is specified on the parameter window. In the example below, the user has 2 choices for the field 'Display only Following Price Code Columns'
    • Leave the values blank. If so, then Theatre Manager uses the existing price codes for each venue and displays them on the report columns in alphabetical order - as it did in the past. For events in venues with different price codes, you'll see the price code columns change.
    • Enter your choice for price codes. They can be in any order you wish and you can leave some out. If you do this, the columns in the reports reflect ONLY those price codes selected. See sample report.
      
      
      
      Note: a caveat about the report is that the 'Total' column will always show the final totals for all price codes. (It does not show only the totals for the selected price codes). It does show the price codes in the order that you put the columns.