Okay -- we have had Tessitura for over a decade and never updated the zip code table. Needless to say we have areas of the city that are not in the table. So we got zipcode.com and began to load the table.
It is really AWFUL for single listing that should say New York - the options are Manhattan, NYC, NY City, Business Reply, Ny. AND there is no way to know which City display is going to be picked by Tessitura. In Scanton Pa -- I have one zip that could be Scanton but system returns United Parcel Service.
If we had the additional 4 digits this might not be a problem but we don't? Short of having to manually edit the table each time to clean odd ball names is there something our IT folks need to know?
Tessitura, or more accurately, TR_CITYSTATE can't deal with Zip + Four data.
The data from zip-codes.com should include a PrimaryRecord column. PrimaryRecord = 'P' should translate to default_ind = 'Y' in TR_CITYSTATE.
That will determine which city among those available for a particular Zip will be chosen by default by Tessitura.
Hi Leslie,
We periodically refresh the TR_CITYSTATE table with the data we get from zip-codes.com as well; in fact, we just replace the entire contents of TR_CITYSTATE with the latest zip-codes.com data. As Chris pointed out, we set tr_citystate.default_ind to 'Y' if PrimaryRecord = 'P' and this seems to work well for us.
Best of luck to you!
David