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.

Hi,

I have a few customers using my OctoTools to create billing forms with
Postnet codes for their subscribers. OctoTools is not computing the
Postnet, but taking the value and creating the appropriate bar code
(including the check digit). Recently, mail-merge has been added to
OctoTools and can accommodate just about any input, vas well as possibly
bring in the zip code values from other sources and merge/map them to your
document. I am not an expert on the Postnet, but might be able to bring
this all together for a workable solution. OctoTools is designed as a very
cost effective solution for medium to high volume throughputs, batch
processing, and automated operation, but as a commercial software it is not
intended for smaller volume, one-at-a-time desktop processing. Call or
e-mail for additional information if you'd like to pursue this farther.
Thanks, larry at jbmsystems dot com (978) 535-7676.

Larry T.

Though I'm not in the U.S. so do not use these things, people in this
newsgroup have mentioned that the USPS now do things differently from the MS
implementation, and I passed this info. to the right people (I hope) at MS.
However, what they will decide to do about this is difficult to tell.

I think the only way you could make Word do what you needed would be so
convoluted it could hardly be worth it - you would need a bit of software
that looked up the CASS database, found out which digit needed to be used,
then construct a fake address with whatever street address would cause Word
to generate the correct digits.

The people responding in this newsgroup are only volunteers, not MS people,
so I would also suggest that you contact MS as customer support and see if
they have anything to say about it.

Peter Jamieson
"Lee Gillie" wrote in message
...
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.