USPS API changes announced for May 12, 2008

[dmorris]

I am running zencart 1.38a and having a usps shipping problem. I have uninstalled the shipping module and reinstalled with the new May 12th v13.
* @version $Id: usps.php 8516 2008-05-13 01:56:07Z drbyte $

error that I am receiving

United States Postal Service
We are unable to find a USPS shipping quote suitable for your mailing address and the shipping methods we typically use.
If you prefer to use USPS as your shipping method, please contact us for assistance.
(Please check that your Zip Code is entered correctly.)

Any help would be appreciated.

Thanks

[DrByte]

United States Postal Service
We are unable to find a USPS shipping quote suitable for your mailing address and the shipping methods we typically use.
If you prefer to use USPS as your shipping method, please contact us for assistance.
(Please check that your Zip Code is entered correctly.)

That means exactly what it says ...

Using the Zip code configured in your store settings and the zip code of the customer's address, combined with the shipping options you've selected in your USPS module settings, and the package count and weight, it could not find any available options.

So, either you've got a bad zip code set in your admin under Configuration->Shipping/Packaging or you've unchecked too many options in your USPS module settings. Or maybe the address you're shipping to is bad.

You could turn on the debug emails in the module and see what the USPS response is from every attempted shipping quote.

Also, there are articles in the FAQ area which talk about related issues:

FAQ on proper configuration of USPS module: https://www.zen-cart.com/tutorials/i...hp?article=327

FAQ on dealing with unexpected USPS results: https://www.zen-cart.com/tutorials/index.php?article=86

[judyinspokane]

I had that same problem too (error message from USPS). Mine was resolved when reducing the number of heavy weight items in my cart. It worked fine after that. I now have "Call For Price" on the heavy weight item listings. Maybe this is your problem also?

[zilog357]

In my case, I switched to the Production Server after a call to the USPS. When doing the tests, International ratings work OK, but for some reason, US Domestic rates don't.

I found later, looking at the USPS programming Guides, that the API call for the ShippingAPI.dll for Domestic (US) rates is now "RateV3" and no longer "Rate". So the request must be changed to "RateV3Request USERID..." instead of the "RateRequest USERID..." used in the May 12, 2008 version. For International rates, "IntlRateRequest" is still used.

After doing the changes, Domestic rates are still not working. Seems like somehow, the module is stuck with "IntlRate" and not doing the switching when a Domestic rate is requested as the debugging function keeps returning an error with the IntlRate request as if the module didn't "realize" that a Domestic request was issued instead of an International one.

The error is listed bellow, and is typical, as when requesting a Domestic rate, and it is processed by the IntlRate request instead, the Country name is not transmitted.

And yes, I have the correct settings for the zip code and Country of origin in [Configuration] [Shipping/Packaging], which are Puerto Rico and 00985. All other parameters, like weight, service, etc are also set.

I'm really having a hard time at this

error returned when requesting a DOMESTIC (US) rate (NOT International):

<?xml version="1.0"?>
<IntlRateResponse><Package ID="0"><Error><Number>-2147219080</Number><Source>;IntlRate.UnpackIntlRateNode</Source><Description>Missing value for Country.</Description><HelpFile></HelpFile><HelpContext>1000440</HelpContext></Error></Package></IntlRateResponse>

Regards,

Richard

[zilog357]

Ok. I changed "Rate&XML" for "RateV3&XML" and "RateRequest..." for "RateV3Request..." in the whole USPS.php module. Still no luck.

Then, I changed "Country of Origin" from "Puerto Rico" to "US". International requests still work and even when Domestic requests still show nothing on the pop up window, it did a positive change: now error messages from Domestic requests are returned by "RateV3 Respond" and NOT by "IntlRate Respond". I guess that the module "doesn't know" that Puerto Rico is an US Territory.

The first error was about the package container. Since it is an optional parameter, I took it out from the request string by putting a "//"

Ex:

'<Ounces>' . $this->ounces . '</Ounces>' .
// '<Container>' . $this->container . '</Container>' .
'<Size>' . $this->size . '</Size>' .

Now, it still doesn't show Domestic quotes on the pop up window, but the debug function sends two emails; one with all the package parameters and the correct quote for the request done and a second one with the info listed bellow. So now it calculates the rate ok, but doesn't display because of the error described on the second email.

Now I'm more clueless than before...

error:

<?xml version="1.0"?>
<Error><Number>-2147219085</Number><Source>Rate_Respond.;SOLServerRates.RateV3_Respond</Source><Description>Invalid XML Element cannot be empty according to the DTD/Schema.
line= 0 pos= 1147</Description><HelpFile></HelpFile><HelpContext>1000440</HelpContext></Error>

[DrByte]

The module is not written for the v3 API. Just changing the request type is not sufficient.

Your problem is not in the API call. Your problem is likely due to USPS treating Puerto Rico differently than you expected ... namely country vs state/territory. You'll likely need to change your Zen Cart setup so that Puerto Rico is seen the same way USPS wants it, not necessarily how the International Standards (ISO) see it.

[Ajeh]

If you are using USPS you want to remove the US territories and Islands that are also defined as countries ... as they are listed as states of the US, to work with USPS and the rules they follow such as, if we own it, then the Country is obviously United States ... country 223 ...

If you are using UPS you want to remove the US Territories and Islands that are also defined as states ... as they are listed as individual countries as UPS doesn't look at who owns what but wants to make sure the package gets there on time ...

If you use both USPS and UPS ... you are doomed ...

... or, you can just accept that some people will not be able to use one shipping module or the other depending on "how" they create their account and whether they defined themselves as a Country or a State ...

[Ajeh]

NOTE: one of the first things I am doing when I have nothing better to do is write a dang translator to magically figure out who is who in the zoo ... I hate those dang quirks ...

[zilog357]

Ok, I see...no wonder...

Thanks for your prompt and enlightening reply guys. Will see what can I do to solve it in a way that I am more or less satisfied with.

[cjmarley]

Just so y'all know...I just checked out the USPS website and they are no longer listing First Class Intl Package as an option for international shipping which would explain why our cart is not showing that as an option for shipping overseas anymore.