AbleCommerce Shopping Cart Software

I've noticed a few errors in my ac7 log...

Error obtaining rate quote for shipping method 'FedEx Standard Overnight'

61468 : Recipient postal code does not match recipient state/province code

is this a setup problem in my store or just the visitor trying to do something that doesn't make sense? I only see this about once every 2-3 days.

I'm guessing that it is the customer using the wrong zip code if it's happening that infrequently.

I haven't looked, but maybe the AC Log needs to distinguish message levels, i.e. Error, Warning, Information, etc. It sounds like people may get carried away by entries that are simply for informational purposes only but are NOT errors in the store'ware.

NC Software wrote:I haven't looked, but maybe the AC Log needs to distinguish message levels, i.e. Error, Warning, Information, etc. It sounds like people may get carried away by entries that are simply for informational purposes only but are NOT errors in the store'ware.

The online log is for events that we felt the merchant should be aware of - unexpected problems to us. Then we will get things like this forum post. From that we can be more reactive to problems that otherwise might not be noticed.

As for the shipping quote error, yeah, someone probably entered a state and zipcode that weren't a match. If this starts to crop up a lot, we would want to investigate solutions on our end to validating this input.

Thanks Logan. It's been very infrequent so far. I'll post again if it appears to become a concern.

The error log feature is a great help for knowing something didn't go as planned. My last marriage could have really used one

I just ran across the problem in 5.5, so this might be why 7.0 has a problem.
Burlington, VT 04508.
That zip code is hardcoded in cbProvince.GetProvinceFromPostalCode to be a ME state, not VT.

I don't know if the USPS changed the zip codes, but if it is hardcoded in Able 7, I think it needs to be done a different way in case USPS changes codes.

Forget the above post, she was putting in 04508 when it should have been 05408.

jmestep wrote:That zip code is hardcoded in cbProvince.GetProvinceFromPostalCode to be a ME state, not VT.

I don't know if the USPS changed the zip codes, but if it is hardcoded in Able 7, I think it needs to be done a different way in case USPS changes codes.

I've been struggling with whether we should put that code back in. Do you get a lot of reports from customers who can't get their zip code / state to match? There is an algorithm that you can figure out the state based on the number, because certain blocks are supposed to be assigned to certain states.

This would be easy to put back in, but I was worried about changes as you point out.

There are zipcode databases you can subscribe to for API access. Its an extra cost, but it does takes all maintenance our of the equation.

I'm looking into one now because it also can do lat/long to timezone conversions. I desperately need that now for my product.

SolunarServices wrote:There are zipcode databases you can subscribe to for API access. Its an extra cost, but it does takes all maintenance our of the equation.

I'm looking into one now because it also can do lat/long to timezone conversions. I desperately need that now for my product.

We used to do that as well. We ran into the same kinds of problems due to changes and updates. That was years back though. With the advent of web services it's a problem with a solution.

What about running it off an xml file for the state/zip code definitions? That way if the USPS does make a change, we could access the file to change it. grzyweasel did that for his custom shipping wrapper for modifying shipping rates and it works very well and is easy to edit. When I looked in the source code for 5.5, it would have been easy to edit, but I wouldn't have wanted to change that unless it was absolutely necessary.
I would hate to see you go to an outside web service and have a possibility of the service being down, especially since I don't think there are a lot of Zip code changes.

jmestep wrote:I would hate to see you go to an outside web service and have a possibility of the service being down, especially since I don't think there are a lot of Zip code changes.

True, we have to be careful about slowing down the process. I was thinking of web service more along the lines of an easy way to check for / update your zip file. In the past, if we published an update you may or may not have downloaded it. If we did something like this in the future, it would have to come with an automatic update. (Also, I'd like to see something similar for geo-mapping IP addresses.)

I guess the question then becomes the goal.

Accomodating US zip code changes is a miminal issue as Judy noted, however in a international scale it might change more often than we realize.

Do we want it to be current for US zips only or handle the international scene as well?

I've looked at some web services too - I agree it's difficult to commit to them knowing they could go away, sometimes without warning.

I am using VERSION: 7.0.5.14135 and am consistently getting warnings with FedEx since 1/3/11:
Error obtaining rate quote for shipping method (any method FedEx) 61468 : Recipient postal code does not match recipient state/province code.

Is there a fix for this?

Thanks,
Karen