address verification removes part of address : Fixed - Version 1.2.8.4

[finnstyle]

I've just noticed that if an address contains both a street address and a PO Box number (this is not uncommon in rural addresses, I see a few a month), the address verifier, which we have set to run automatically, will delete the street address part. For example,

123 Pennsylvania Avenue
PO Box 75545
Mount Carmel, PA 17851

becomes

PO Box 75545
Mount Carmel, PA 17851-0075

This often means we'll end up sending them an email saying we can't ship UPS to their box, when really UPS does deliver to most of these rural boxes. Is there any way to prevent this, short of not verifying all my other addresses?

[David Johns]

We'll look into this...

[finnstyle]

Today I got an error message when verifying an address... "Unable to load XML file. Whitespace is not allowed at this location."

What's that mean?

[David Johns]

finnstyle,

This means the response from the dial-a-zip server was either corrupted in transit or not "well-formed".  Did it repeat if you tried it several times?  If so, it would be the latter.

[finnstyle]

Yes, it repeated, despite my attempts at re-formatting the address. Do you have a better definition of "well-formed"?

[David Johns]

There is an industry-wide specification for how XML files are written.  It seems that dial-a-zip does not follow the rules in the response it sends for this address for some reason.  Can you send me the address for the one that did this and I'll see if I can repeat the problem and do anything to fix it?

Thanks,
David

[finnstyle]

Well, I can't find another address that has that XML whitespace error, but I have discovered another issue with this same type of half-PO/half-regular address. They refuse to export to UPS! I have to delete the PO Box and re-add it later... after already re-downloading the order to get the rest of the address, that's quite a workaround!

Anyway, if you could change the PO Box block so that it allows PO Boxes with another line of address, that would be cool.

[David Johns]

finnstyle,

It is true if the address1 line includes the PO Box it will skip the order altogether.  The trick would be to put the PO Box to the address2 line.  So I beleive as long as you swap the order of the lines it should work.  We can think about what the automated solution for this would be.  Obviously we could try to automate swapping the address1 and address2 lines.  It is just more difficult for SuperManager to detect if for sure the address2 line contains an actual street address and not something else.  It can certainly determine if it has some information or is blank, but beyond that it becomes difficult to determine if it is a valie street address or just something else (I don't know what off hand, but I think you get the point).  I just want to make sure before we make a change that we come up with robust rules for it.  I'm open to your suggestions on this.

Thanks,
David

[finnstyle]

Ok. Since I have address verification turned on automatically, I will still have to re-download the order, but putting it in address2 lines will be helpful to at least get it into UPS.

But yeah, if the address verificator automatically put it into that format instead of just deleting the other line, that'd be mad cool. I can't think of anything that would be put in the other line of address besides the physical address, so if address1 was a PO Box, and address2 existed, I think it would be safe to swap them. There might be exceptions of course (someone putting their business name in the address2 field? seems unlikely. a "c/o" maybe) but these would probably be noticed and manually corrected. (I have to notice all the PO Boxes now to make sure they get re-downloaded anyway)

[finnstyle]

I emailed you an address that got the XML whitespace error. Can you give me a better idea how to avoid it?

[David Johns]

Kyla,

I found the error.  It seems that the server that SuperManager pings to get the address information is sending reserved characters in their response.  Specifically, in the one you sent the server sent "&"s.  According to the XML specification this is not allowed.  You have to instead send them as "&" to be compliant.

We'll see if we can implement a workaround.

Thanks,
David

[David Johns]

Kyla,

We did implement a workaround fix for the whitespace error.  We'll work on the other initial issue at the top of the post.

Thanks,
David

[finnstyle]

This is still a really big issue for me. I'm really considering turning off automatic address verification after today's snafu.

1100 E 10th Ave  #8
Denver CO 80218

became

1100 E 108th Ave
Northglenn, CO 80233

That's completely unacceptable. There really needs to be some sort of safeguard against the street name, city name, and zip code all changing. That's not verification, that's invention.

[David Johns]

Finnstyle,

We have just been informed that the verification server has problems with '#'.  We'll get on replacing '#' with 'Apt' and see if that fixes extreme cases like the one you showed.

Thanks,
David

[David Johns]

Finnstyle,

These issues have been corrected in a new version 1.2.8.4 out today.

Thanks,
David