Version 6.64.14

This is an enhancement release for Theatre Manager.

The primary new feature is support multiple credit card merchant accounts. This means that Theatre Manager can support as many merchant terminals as you wish; such as one for internet sales, one for box office and one for development.

Version 6.63 • Updates

Released May 20, 2005

Key changes:

added the ability to set up multiple merchant accounts
each employee can be assigned a primary merchant account
you can indicate if the employee can change their primary account when taking a payment.
revised the best seat search algorithm for priority seat searching to give better results

Note: Read prior release notes for any mandatory web pages changes. There are no web page changes for this version.

We suggest reading the prior release notes completely from version 6.48 on (and certainly from your currently installed version)

Theatre Manager will

Reorganize the database (transactions, payments, employees and code tables)

Move the merchant information in default data into its own merchant record

Assign permissions to each employee to disallow them to use multiple merchant accounts

Attach the merchant account to each transaction, payment, GL entry and employee as needed.

The user will need to

Before upgrade	If upgrading from a version before 6.48, read version 6.48 release notes Complete your end of day. Deposit all funds, create all sales entries and post to the GL. Verify the database using data utilities and ensure that everything is ok. Make a backup copy of the database Make sure that there is some free space in the database (10%). These new fields should not take much space
After upgrade	Verify any permissions regarding editing merchant account information (it is a separate permission under 'data') Verify which employees may change from one merchant account to another
Optional Steps	Decide if your merchant service provider requires you to have a separate merchant account for internet sales and implement if need be. You can, if desired, also want to implement a separate merchant account for development or other departments. Run the report 'Check Order and Patron Balances' under the 'Utility Functions and Database Analysis' and ask TM to fix any errors reported automatically. This corrects values in the database set incorrectly if you had previously recalculated your giving levels for donations.
Time Required	It will take a long time from version 6.48 (see release notes) From version 6.60 or later, it probably take 60-120 minutes if the upgrade is run on your server.

Before upgrade

If upgrading from a version before 6.48, read version 6.48 release notes
Complete your end of day. Deposit all funds, create all sales entries and post to the GL.
Verify the database using data utilities and ensure that everything is ok.
Make a backup copy of the database
Make sure that there is some free space in the database (10%). These new fields should not take much space

After upgrade

Verify any permissions regarding editing merchant account information (it is a separate permission under 'data')
Verify which employees may change from one merchant account to another

Optional Steps

Decide if your merchant service provider requires you to have a separate merchant account for internet sales and implement if need be. You can, if desired, also want to implement a separate merchant account for development or other departments.
Run the report 'Check Order and Patron Balances' under the 'Utility Functions and Database Analysis' and ask TM to fix any errors reported automatically. This corrects values in the database set incorrectly if you had previously recalculated your giving levels for donations.

Time Required

It will take a long time from version 6.48 (see release notes)
From version 6.60 or later, it probably take 60-120 minutes if the upgrade is run on your server.

Web Sales

Fixed a small bug in Online Subscription sales - The web page now only shows subscription promotions that are enabled for the internet.

Added some conditions to the 'best seat' search for internet subscriptions. Since the subscription process checks the control house, and then when a seat is found available in the control house - Theatre Manager looks at all other events in the series and tries to book them. If it cannot, it would abandon the search for tickets. Now it marks those seats as on hold in the control house (expect to see some extraneous holds) and then it goes on and looks at the next available seats. It will do this a maximum of 5 times until Theatre Manager gives up and tells the user to try another section. This helps work around the scenario where the box office booked some 'flexible' subscriptions seats in another area and did not mark those seats as being held in the control house.

Made a significant change to the best seat search algorithm when searching for seats based on priority. It now caches all the seats at that priority and steps through them so that a user will see all possible tickets. An incorrect assumption had been made that the 'best seat' mirrored the 'best priority' order (which, in fact, may not be true).

Merchant Accounts

This is a new feature in Theatre Manager - the support of multiple credit card merchant accounts (or credit card servers). A merchant account is the information required by Theatre Manager to authorize a credit card. It contains the name of the credit card server software, the merchant provider (eg visanet, MAPP, paymentech, etc.) and some parameters that theatre manager uses to interface with the merchant account.

Each venue that authorizes credit cards will need at least one merchant account. It is our recommendation to try to keep to only one.

If your merchant provider requires you to have a separate terminal id (or merchant id) for web sales, then you may need a second merchant account to satisfy their contractual obligations.

You may also wish a separate merchant account for some departments like development so that they can do credit card authorization into a separate account, if desired.

If you decide to change your merchant provider when you change banks, we recommend:

Creating a new merchant account
inactivating the old account so that you know what a payment or GL was posted to in the past.
associating all your employees with the new merchant account.
This also allows you to switch back and forth between merchant accounts during the transition period if there are issues with the setup at the bank.

You can access the merchant information by 'Setup->Merchant Account'. This data was formerly in Default Data under the 'Credit Card' tab and is now its own window. It has the same functionality as when the data was in the default data window.

Code Tables

You can now specify which merchant account each credit card can use. If you accept the same credit card for different merchant accounts, enter it twice with separate posting accounts and separate credit card fees so that it gets posted to your G/L using different accounts.

To associate a merchant account with each payment type, go to 'setup->Code Tables->payments'. Double click on the payment (must be a credit card) that you want to change.

Click on the 'Merchant Charge' tab and pick the merchant number you wish to use.

Employees

Each Employee record can be associated with their own merchant id. This means that box office could use a different merchant/terminal id than development (for example). The merchant setup for an employee is located on the 'Level' tab of the employee detail window. You access this by 'Setup->Users & Access->Employee Setup'.

During the upgrade, this is defaulted to the main merchant account that was formerly in Default Data.

Also, on the 'Functions' tab, there is a new permission that indicates if the employee can change their merchant account from one merchant to another during a payment. Normally, this is turned off. It does not matter what the setting is if there is only one merchant account.

Default Data

Moved the 'Credit Card' to a new record called 'Merchant' record.

Payment Window

One the payment window at the top/middle, there is the ability to pick a merchant account for each payment. This is shown in the example as a field called 'Merchant ID' with the value of 'Nova Test' in it (I'd set up this as the name of one of my test merchants).

Note: if you have multiple merchant accounts, but only one is active, then this field does not appear because the user will have no choices to make. This was done to keep data entry and change to the user simple.

If there are multiple active merchant accounts, you can change from one merchant to another by switching the 'Merchant ID' on each payment. Thus, part of a credit card could go to one merchant and the rest to another.

If your setting is to 'not allow' selection of a different merchant id (from your default), then you will be asked for a supervisor over-ride for this payment to go through.

If you select the merchant account here, it also becomes the merchant account that is used for post dated payments.

Changing the merchant account may change the payment options available. For example, once merchant account may not accept Amex. If so, the Payment Method list changes and Amex will not appear.

Going to the 'Prior Payment' tab and selecting any payment that is a credit card - this will check that the currently selected merchant is the same as the merchant in the prior payment. If not, you will not be allowed to refund a payment to a different merchant account than it was authorized on.

Deposit Process

The Deposit process has been modified to handle multiple merchant accounts.

When the deposit window is opened, ALL merchant accounts are disabled from authorization until the deposit window is closed.

The deposit list shows each payment and the merchant number that it is associated with.

When the 'deposit' button is clicked to begin the settlement process, the confirmation window shows the status of each merchant provider - showing if it matches with the payments for the merchant account. A warning is given for each non match.

Also, beginning the deposit process checks for the total payments/refunds for a patron to see if they net out to zero. If so, a warning is given that perhaps they should be removed. (previously, the only check was for a debit/credit in the same amount).

Each merchant/credit card combination results in its own GL entry line being created. So, if you accept Visa with two different merchant accounts, there will be two 'visa' lines in the G/L entry detail with an indication if which one is for which merchant.

End of Day - 'A/R' tab now has an extra total line at the bottom that shows the Total A/R (inclusive of debits and credits) so that you can compare this to the A/R on the upper left of the End of Day screen.

Completely revised the search for outstanding orders in End-Of-Day wizard. It is now many times faster if there is a lot of orders containing receivables. The new search is based on orders with no final payment date (i.e. outstanding).

If a user attempts to finalize a deposit containing a post dated payment, Theatre Manager now asks for the user initials/password of a person permitted to do this action. This prevents any deposit from occurring if there are posted dated credit cards. This permission setting is in the 'Employee Record' and defaults to off for all users except the master user. See the example below.

Outlet Version Changes

Fixed the 'Promotion/Price' worksheet report that is printed from the 'promotions' tab on the play & dates window to show only the sales promotions that belong to the outlet that the event belongs to. If a site is using the outlet edition, this report erroneously displayed all sales promotions from all outlets.

Changed some code tables from being common across all outlets to be unique to each outlet. Some of those changed to be unique to each outlet were 'Reasons to buy', 'Notifications', 'Letter Types', 'Volunteer codes'

In reports, added the ability to see the outlet that any saved criteria belongs to. You can now use criteria from other outlets as a template. Be aware that some of the specific values in the criteria that pertain to information in the outlet may not work for you and might need changed. (eg, the criteria may refer to a specific mail list. That wont work for your outlet, but by changing the mail list, the criteria will work for you).

Added a check to only allow a person at an outlet to change their own criteria in the saved criteria window. Master Users and Outlet Administrators can no longer delete the criteria belonging to another outlet.

Fixed a bug in the 'Receivables as of a specific date' report for outlet edition. In some cases, the order would appear twice in the report. This has been fixed.

Gift Certificate/Passes/Memberships

Added the ability to 'duplicate' gift certificates on an order. Under certain conditions, you can enter a gift certificate, pass or membership on the 'member' tab on the patron window. Once entered, there is a button at the bottom of the window called 'Duplicate'. Clicking it will ask you how many more of the same pass is to be added to that order for that patron and will automatically add that amount more. Passes will be added under the following conditions:

Any type of Pass except those that could be renewed. (these cannot be duplicated - they are usually renewed, so this avoids confusion)
It is set up so that Theatre Manager creates the control number for the pass. If the control number is manually entered, Theatre Manager will not allow it to be duplicated.
It is still allowed to be sold.

Added support to '$Dollar Average' gift certificates to allow them to be sold for less than the value that could be redeemed. For example; you could now set up a $ average redemption gift certificate that can be sold for $0 and redeemed for up to $60 for 2 tickets, with any ticket costing more than that being charged the upgrade fee.

Miscellaneous Changes

Changed a number of reports to deal with multiple merchant accounts.

The sales process will no longer start if the merchant account is disabled for the employee.

You can search the deposit G/L entries by a new field called 'Merchant Id' - and find out which payments were authorized against each merchant. This should help on Bank Reconciliation's for multiple merchant accounts.

Fixed a recently noticed bug in creation of nick names during the addition of a new patron. If your setting in default data is to create a nick name that is the patron & spouse (eg joe & betty) -AND- you enter 'Joe & Betty Smith' in the first name field; Theatre Manager, when trying to help you, would split apart the first name and last name. The first name was further split and part of it copied to the 'spouse' first name field. The result was that the nick name, based on this setting became 'Joe & Betty & Betty' until it was changed. This has been fixed.

Made a change to the donor window to allow notification of a hard pledge to go out.

Fixed a bug in the sales posting where the comment showed the same 'Show Code' for all tax lines posted in the GL. The tax was being allocated to the proper show - just the description was wrong.

Fixed a small bug when two or more computers were adding events simultaneously. Theatre Manager would erroneously report that there was a problem creating the tickets. You would only ever see this bug if your venue was larger than 550 seats and two people commenced creation of reserved seats in the play & dates window simultaneously.

Fixed an issue in the volunteer management window for the outlet edition where it did not find the appropriate records for the patron for that specific outlet.

Fixed a bug that was calculating the donor balance on each donation incorrectly. If you rebuild the giving levels, the donor balance was set to the value of the donation in error. Upgrading will recalculate the giving level for all donations that are not historical and determine the balance properly.

Fixed an issue when printing 'Membership' invoices via the member detail window letter button. TM was not loading the proper order that was associated with the membership/gift certificate

Fixes an issue for printing Order Invoices (via the payments window letter button) - it was also not loading the correct order to merge into the letter.

Added a check to prevent people from being removed from a mail list while on the patron list window - if the mail list is 'not active' and/or the employee is 'not authorized' to remove people from that mail list.

The 'Order-Patron balance' debug report now reports orders with an invalid final payment date (i.e. where the order balance =0 and the final payment date should be filled in, but is blank for some reason). This allows these to be set properly which fixed searching for orders, and 'receivables as-of' report.

Correctly calculate the Order Final Payment date on deletion of a pass/gift certificate/membership.

Added a feature on the 'Membership' window to duplicate an existing Membership/Gift Certificate/Pass as many times as you wish into the same order. This makes it very easy to sell a pass to a person, then sell them a number of duplicates of that pass from the 'member' tab on the patron window.

Fixed a bug in season subscriptions where 'on account' was not showing up as a payment method.