L
Lee Gillie
We have been using MS Word to form the POSTNET code for merge mailings.
It takes the 9 digit zip in the address. We understand it ALSO
"computes" the 2-digit delivery point by scanning the street address,
and then of course computes the check digit, providing the 12 digits of
the POSTNET code.
The USPS has contacted us recently stating THIS METHOD of computing the
DELIVERY POINT is invalid. They tell us THE ONLY WAY TO DETERMINE THE
DELIVERY POINT code is by looking it up in a CASS database (which
ultimately are sourced by USPS). In NOT ALL cases, will the digits be
found in the street address. Case in point, is USPS may have assigned
code 17 to apartment building "A", and code 16 to building "B" and so
on. The digits needed are not in the printed street address, and MS will
in fact code them incorrectly according to CURRENT USPS REGULATION.
Indeed we find MS providing a very high percentage of incorrect DELIVERY
POINTS in our tests.
There are TWO PROBLEMS with incorrect DELIVERY POINT codes in the
POSTNET. One is that this will cause the mail to kick out of primary
automation to a secondary process, thus delaying its delivery by a
minimum of one day. And second, and the most serious to us, is that if
you are depending upon AUTOMATION DISCOUNTS for your mailing, the USPS
has said they WILL NOW REJECT THE ENTIRE MAILING BATCH for consideration
of discounts if the correction rate is above a certain percentage. NOT
JUST THE INCORRECTLY CODED ITEMS. It can be VERY EXPENSIVE to loose
discounts on just about any batch.
Apparently this is a recent regulation or policy change with the USPS
according to the people from there who have contacted us. I know
everyone who does mailings of any size will be slamming into this brick
wall also very soon.
Given all of this: Is there any way known to get "CORRECT" POSTNET
coding on a mail merge using Microsoft Word?
We have CASS software, but have NOT been able to find a way to get the
MS WORD POSTNET feature to take the 11 or 12 digits from a better authority.
It takes the 9 digit zip in the address. We understand it ALSO
"computes" the 2-digit delivery point by scanning the street address,
and then of course computes the check digit, providing the 12 digits of
the POSTNET code.
The USPS has contacted us recently stating THIS METHOD of computing the
DELIVERY POINT is invalid. They tell us THE ONLY WAY TO DETERMINE THE
DELIVERY POINT code is by looking it up in a CASS database (which
ultimately are sourced by USPS). In NOT ALL cases, will the digits be
found in the street address. Case in point, is USPS may have assigned
code 17 to apartment building "A", and code 16 to building "B" and so
on. The digits needed are not in the printed street address, and MS will
in fact code them incorrectly according to CURRENT USPS REGULATION.
Indeed we find MS providing a very high percentage of incorrect DELIVERY
POINTS in our tests.
There are TWO PROBLEMS with incorrect DELIVERY POINT codes in the
POSTNET. One is that this will cause the mail to kick out of primary
automation to a secondary process, thus delaying its delivery by a
minimum of one day. And second, and the most serious to us, is that if
you are depending upon AUTOMATION DISCOUNTS for your mailing, the USPS
has said they WILL NOW REJECT THE ENTIRE MAILING BATCH for consideration
of discounts if the correction rate is above a certain percentage. NOT
JUST THE INCORRECTLY CODED ITEMS. It can be VERY EXPENSIVE to loose
discounts on just about any batch.
Apparently this is a recent regulation or policy change with the USPS
according to the people from there who have contacted us. I know
everyone who does mailings of any size will be slamming into this brick
wall also very soon.
Given all of this: Is there any way known to get "CORRECT" POSTNET
coding on a mail merge using Microsoft Word?
We have CASS software, but have NOT been able to find a way to get the
MS WORD POSTNET feature to take the 11 or 12 digits from a better authority.