Version 6.76.07

This update contains an important fix for the checkout confirmation code that addresses an issue where people using certain browsers might adversely interrupt the checkout process of another user. The browsers causing the issues were based on the Mozilla engine, FireFox or Safari. Internet Explorer or Opera do not seem to cause these issues.

Version 6.75 • Updates

Released April 17, 2006

Key changes:

Fix of checkout process on internet
Added general admission ticket number to cart during checkout
Enhanced cart tracking to support same person on multiple browsers at multiple machines.
Added support for FDR merchant provider in PC charge.
Fixed an issue with EOD and transfer of deferred to earned revenue

Note: Read prior release notes for any mandatory web pages changes. There are no mandatory web page changes for this version. There is one new web error message and one possible notification message for web sales

Preparing for the Update

Theatre Manager will

do nothing to the database

The user will need to

Before upgrade	Read the release notes for any version prior and follow the directions Stop web sales and close all shopping carts. Then manually release any left over 'i' holds in any events that you need to do this in 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
After upgrade	None required
Optional Steps	Download the new web pages and copy in the TMError.txt file and/or the tmEmailWebNotify.html page
Time Required	Updating the database from 6.75 is very short.

Web Sales

An issue was discovered where the user, with certain browsers, could navigate backward to cause their card to be resubmitted and/or interrupt some other user successfully completing their shopping cart. We have discovered that this only appears to affect users that were using Netscape, Firefox, or Safari. Those people using Internet Explorer or Opera are not able to cause this condition to occur.

The exact steps to cause the issues are:

User finished buying and checks out
They receive the confirmation web page
They view the historical cart detail
On one of the browsers named above, they use the back button which causes the checkout process to re-initiate itself.

Various things could happen, mostly the user would checkout nothing and receive a second email confirmation that said nothing was bought. In the right circumstances, unpredictable results could occur.

Other changes to Web Sales:

The cart is now updated with the ticket number of the checked out pages for reference for general admission tickets. This does not affect any sales. It is for future informational purposes.
The bar code routine was altered to display '*Tampered*' as the bar code if the ticket has been exchanged and the user is viewing the historical shopping cart. Note that viewing upcoming performances always shows the correct bar code. The historical shopping cart is different - it is a record of what was purchased at the time, not what the user currently has.
The expired holds are no longer touched while the listener is in the middle of checking out a patron and waiting for authorization status.
Provides better support for the same user accessing the web listener from multiple different kinds of browsers simultaneously on the same (or different) machines (e.g., user trying to buy anonymously using Explorer, Netscape, Safari, and Opera at the same time). Why somebody would do this - don't know, but we tried it during testing and it seems to work.
If a user tries to buy using multiple tabs in the same browser or multiple windows of the same browser, the behavior is as before - they all act as if they are using the same shopping cart.
Fixed an issue where a new anonymous browser would create 2 carts instead of one. The first cart was never used - just created. It no longer does this (this bug introduced in 6.75.00)
All tickets in a cart belonging to one 'reserve' are now sorted by date and time of performance. This really only affects all tickets purchased as part of a subscription. All remaining tickets are sorted in order of them being added to the cart. Eg: single tickets will show up in the order that the user reserved them.
Enhanced the notification for online sales - if something is sold on the internet (ticket, donation, gift certificates) - if there is a notification set up, then an email will be sent as appropriate, based on the notifications set up for each event, etc. The notification will be the complete purchase for the patron. To set this up for notifying for ticket purchases done online:
1. create a notification that is for internet only
2. add the staff you want notified
3. use the new email notification file called 'tmEmailWebNotify.html' from the web pages
4. attach that notification you set up to the event you want it to apply to. Ticket notifications only work for web purchases.
Fixed 4 issues with subscription component of web sales that may affect some users:
1. The section/row/seat information displayed for a renewing subscriber was found using the seat codes. if somebody had duplicated a theatre map and kept the same seat codes, then the incorrect description of the seat might show up - it might pick a prior description. This is fixed
2. If the subscription used different tax rates for each performance, the tax was not being calculated correctly to display a price for the user to pick from. The final price in the shoping cart was right - just not the interim selection where the seats were offered. This is fixed.
3. The subscription renewal process assumed that only final - all taxes and fees in it - price was going to be displayed. If a venue wanted to do calculations to show the price components for each fee and tax, that was not available. This has now been added.
4. Fixed a problem where subscription tickets would get released right after the tickets were added to the shopping cart. This problem was introduced in 6.67.00 as a byproduct of making sure that tickets were released if the back button was used

Upgrading the Web Pages

You can update your pages to match the template pages by:

Download the latest version of the sample web page folder for Mac or Windows
Install the sample web pages into a directory of your choice. You will need to specify the password you were previously given.
Find the file called TMerror.txt and copy that to your WebPages folder on your web listener.
Find the file in the NotifyEmails directory and copy 'tmEmailWebNotify.html' to the same directory on the web listener. This is a sample email file useful for sending an entire web purchase made online and notifying internal staff (e.g. in the case of purchasing tickets for a class where additional follow up is required).

NOTE: if you have previously changed the contents of this file, you will want to open the file and copy the error message # 10120 from the new file to the old file and change the message text if need be. This new message occurs if the user uses the back button on the browser to the point where the cart information could be submitted again.

Credit Card Authorizations

Found an issue where a 'ticket' number was not being sent to PC charge for purchases done via the web listener. This could affect the discount rate for some service providers like VisaNet. It has been fixed. Ticket number is now the 'order number' for all purchases done via the box office. The Ticket Number is the shopping cart number for all purchases done through the web listener

Misc Changes

The shopping cart detail window from the patron screen now shows you if tickets bought in the cart are still assigned to the patron. If they are and the price has been changed by the box office, the web cart display shows what the price was when purchased and what the price/promotion/price code now is for reference purposes.
Closing the shopping cart detail now re-finds the patron record to address an issue where the patron name would be blanked out inadvertently.
Revenues by Promotions - Detail Breakdown. This was calculating the final line containing the total % of house incorrectly when multiple events were picked - fixed.
Changed the copy of price codes and descriptions to save to disk right after the copy function
Changed the enable/disable promotions to allow setting/clearing of for multiple performances for all filters (e.g. active promotions, inactive, box office, etc.). Previously you could only do this if the filter was set to 'All Promotions'
Added a new transaction type to track when changes are made to each price code and promotion when applied to an event.
Added batch response checking for PC charge and merchant provider type FDR
Fixed rollover of deferred to earned revenue if the accounting preference was to rollover after on the day after the last performance. There were two issues: if you did an EOD on day of last performance, it could rollover the entire event before the last performance occurred -and- if you did not do a rollover on the day of the last performance, the event would never be rolled over. This has been fixed.
Plug in code now supports count of memberships/GC's in determining if a person gets a discount
Fixed an issue with donations where those marked as 'hard pledge' did not have all the donation campaigns/funds available to that donation when it was being changed.

Reports

Changed the 'GL Entry Summary' and 'GL Entry' reports so that the GL Description does not over print the GL date for long GL descriptions.
Added a new report that shows the favorite seats, the cost of the subscription, the current order status and the donation associated with that order which looks like below. It is derived from the existing favourite seat report. There are 3 columns of interest:
- Calculated subscription cost - which is what we would have offered the subscription to the customer for based on the seats in the package. This value should be the same as the renewal notice value. If, after sending out the renewal notices, you change promotions in a package, or change prices of tickets (e.g. from early bird price offering to normal subscription price), then this column will change to reflect the new seat pricing.
- Order Tickets $ - which is the value of the renewed subscription order - if they have renewed. If they have not renewed, this is zero. If the patron was renewed using the subscription module, I get this value from reading the total dollar value of tickets in the subscription order. So, if they renew straight across - the values should be the same. If there were some adjustments and exchanges later on in the season, then the value of this might be different
- and for reference, the value of the donation on the subscription order in anticipation of venues wanting to know renewal rates and donations along with it.
The report prints the current subscription status in the last column. You may need to print this report using criteria for one or two status codes at a time (e.g. a report for 'New' and a report for 'Renew' & 'Renewed with Changes' kind of thing) to break out the detail and get the totals you want.