Page 1 of 1

U.S. Address Certification CASS stage and # pound sign

Posted: Tue Jan 30, 2018 4:03 pm
by qt_ky
Has anyone run into this behavior before and can it be explained?

I have whittled down a sample address with 4 variations, and am only showing the relevant lines 1 and 2. The differences are whether or not there is a space after the # sign and whether or not the # sign part (the secondary unit) is separate on line 2 or combined on line 1. The test job used to demonstrate this behavior only reads a file -> cass stage -> file (no other processing).

Code: Select all

Input (Line1|Line2):
100 W Main St|#200
100 W Main St|# 200
100 W Main St #200|
100 W Main St # 200|

CASS Stage Output (CASSLine1|CASSLine2|DPVMatchFlag|DPVCode1|DPVCode2):
100 W MAIN ST # # 200||D|AA|N1
100 W MAIN ST RM 200|# 200|Y|AA|BB
100 W MAIN ST RM 200||Y|AA|BB
100 W MAIN ST RM 200||Y|AA|BB
For all practical purposes, the 4 input variations look equivalent, but the CASS stage has an adverse reaction to the first one. Problems on the first record:

1. CASS output doubles up the # sign.
2. CASS output gives a DPVMatchFlag of D, meaning that "The address is a default. For example: A high-rise building with no apartment indicated or a rural route without a box number."
3. CASS output gives a DPVCode2 of N1, meaning that "the input address primary number matches, but the address is missing the secondary number."

Furthermore, in the second record, CASS output duplicates the RM 200 and # 200 part across lines 1 and 2.

The customer data is coming in the form of the first variation, generating some complaints. I'd love to tell the customer that the output is USPS-compliant but it does not appear to be the case. When I enter the first variation into the usps.com web site, its output looks like variation 3 and 4.

Posted: Sun Feb 18, 2018 6:03 pm
by rjdickson
Looks likes this deserves a PMR...

Posted: Mon Feb 19, 2018 7:57 am
by qt_ky
Yes... The PMR response so far was to ask if I can strip off the # sign before the CASS stage. That is an easy workaround but I don't think it is a resolution.