Version 6.39

This version is a minor release with a few changes though-out Theatre Manager. They are mostly in the online help and to support our move to a new web service provider. Please read the release notes completely.

Version 6.38 • Updates

Released July 7, 2004

Key changes:

Minor fixes to web sales and the back button
minor change to email capabilities and ignoring certain errors returned by a server when sending out emails, as well as authentication of the email sender.
numerous tune-ups of reports and small issues throughout Theatre Manager.

Preparing for the Update

Theatre Manager will

Reorganize the database and verify any transaction create when a payment is transferred from one order to another. It will make sure that the POT an POF transactions are connected to the correct patron/order.

The user will need to

Before upgrade

Upgrade to version 5.72 if you are not already at that version. Refer to earlier release notes about the process.

Review release notes starting from the version you are currently using, up to and including this version. Previous upgrades may require you to perform additional steps before upgrading and/or after upgrading. They may also list areas of Theatre Manager you need to update with new data requirements before using the new version.

After upgrade

None

Optional Steps

None

Time Required

Minimal (less than an hour) if you are upgrading from version 6.37.

If you are upgrading from 6.38, time will depend on the number of POT and POF transactions. Normally, there are very few, so the upgrade should be fast.

Before upgrade	Upgrade to version 5.72 if you are not already at that version. Refer to earlier release notes about the process. Review release notes starting from the version you are currently using, up to and including this version. Previous upgrades may require you to perform additional steps before upgrading and/or after upgrading. They may also list areas of Theatre Manager you need to update with new data requirements before using the new version.
After upgrade	None
Optional Steps	None
Time Required	Minimal (less than an hour) if you are upgrading from version 6.37. If you are upgrading from 6.38, time will depend on the number of POT and POF transactions. Normally, there are very few, so the upgrade should be fast.

Web Sales

Fixed a problem searching for events that are next year in the current month. If the user asked the web listener to search for an event in the current month but for next year (instead of this year), the listener was incorrectly interpreting that as a search for events in the current year.
Added capability to the emailing routines to ignore non-existant email addresses on a server without stopping the email being sent. Previously, if you were sending an email to your own mail server (eg mail.yourorg.com) and specifying an email address on that server (eg bob@yourorg.com) that did not exist, the email server would respond with 'user not found' and Theatre Manager would abandon that email. Now it just ignores that address and continues on. (Note: this does not affect unknown email addresses being sent through your server such as bob@yahoo.com, only unknown email addresses that are supposed to reside on your server).
Updated the authentication capabilities for sending emails through an authenticated SMTP server.
Found and addressed a unique situation where held tickets were not being released if the user hit the back button on their browser in a very specific order.

Reports

Added a report for dinner table tent cards. This prints a patron's name and table number on the lower half of an 8" by 5" card that is suitable for folding and placing on a dinner table to welcome the patron to their seat at a dinner theatre event.
Made some changes to the database analysis reports to better manage events and performances when reconciling them at the end of an event.
Fixed a bug in the order transaction analysis report to calculat the tax total properly.
Added a subtotal of ticket quantity on the group sales invoices
fixed the display of account numbers in the code table and play detail reports to display in the same format as the account number display in default data.
The printing of bar codes on a mail label is now optional.
Enhanced the Accounts Receivable-as of a date report to take into account orders that were transferred from one patron to another. This report has been changed so that running it should now produce identical results to the A/R balance in the end-of-day wizard.
Made a change to the mass emailing routines to ask for extra verification before sending large numbers of emails. The verification level is set at 500 outgoing emails. If Theatre Manager detects that more than that number is about to be sent, you will be asked if you really want to send that many. This avoids mistakes in the merge processes made b a user from reaching the patron and bothering them.

Patron Window

Fixed a couple of instances where the first field being changes was on some of the marketing tabs and Theatre Manager did not recognize that a change was being made.
Also fixed a couple of instances where clicking the 'add tickets' button just after a patron had been edited would not save the changes to the patron record.

Event Setup

Sorting by the number of performances in the event list now sorts properly.
allow the performance year to be changed after events have been set up

Ticket Selling

made a change to the creation of ticket transactions and the date that they are to be posted to the G/L during an exchange. Previously, TM would use the date of the order as the date that the ticket should be journalized. Now it uses the later of the order date or the ticket purchase date. This scenario occurs when a 'reservation only' order receives its first payment and the order date is changed to be date of the payment. Previously, G/L entries would be created for the date the actual ticket was sold. However, 'reservaton only' means that the tickets are really only being 'held', so using todays date is better than a prior date when the hold occurred
revised the behavour of releasing held tickets on the sell window. Updated the security around who can/cannot release the hold and prompting the user for an over-ride if they did not have the proper authority over a hold.
Fixed an issue where a pass will now be allowed to be used to pay for a ticket when there used to be restriction on the pass (to only allow it to pay for certain events) and those restrictions were removed.
You can now change the credit card information for post dated payments. This was already allowed for non-deposited payments and has just been extended to post dated payments that are not yet deposited.

Transaction Window

Added the column showing ticket purchased quantity to the transaction list window. Normally this is always 1 (for sales) and -1 (for refund transactions). In some general admission events, this number could be something onther than one. Addign the quantity makes it easier to identify the transactions related to specific tickets
Transactions that are duplicated are now noted as being duplicated transactions along with the person and date/time that the transactions was duplicated.

Miscellaneous Changes

Changed the version number checking in the 'About Theatre Manager' dialog to search for version numbers on the new web site and download any updates from www2.artsman.com. This change allows us to support many generations of older installers.
Changed the help topic in a number of areas in Theatre Manager to be consistent with the help file names on the web server. This makes more contextual help topics available for instant help from the web site when accessed via the '?' on the tooolbar.
In addition, changed the contextual help routines to support the server side include help pages at our web site containing the help pages. This means that all help pages will display in our 'new look' web page style, hopefully making the links and text clearer to read.
Fixed a potential source of out-of-balance at the end of day. If a user revises an historical donation (i.e. one created during data import at initial setup of Theatre Manager), TM creates transactions that indicate the donation should be summarized in the daily sales summary. However, that donation would already have been included in the daily sales summary and should not be counted again. This affected the sales summary only and not the G/L entries being created.