UPS Shipping using RESTful/OAuth API [Support Thread]

lat9:

Yep, that was previously reported. I've got a correction staged here for the 1.4.1 release: https://github.com/lat9/upsoauth/issues/56

Thank you. It works perfectly.

UPSrest v1.4.0. zen cart 2.1.0

Not sure if anyone reported it before. I can get a valid UPS quote in the checkout page (OPC). But I cannot get a shipping quote in "Estimated Shipping" in the shopping cart page. I have entered the state and zipcode. In the past / previous API, it could display a UPS rate. Now it only shows "UPS (image for) UPS No shipping is available to XXXXX XX United States, please re-enter."

njcyx:

UPSrest v1.4.0. zen cart 2.1.0

Not sure if anyone reported it before. I can get a valid UPS quote in the checkout page (OPC). But I cannot get a shipping quote in "Estimated Shipping" in the shopping cart page. I have entered the state and zipcode. In the past / previous API, it could display a UPS rate. Now it only shows "UPS (image for) UPS No shipping is available to XXXXX XX United States, please re-enter."
The state/zipcode combination needs to be valid, i.e. you can't enter a Florida Zipcode for California. The details of why no shipping is available will be in a ups trace-log if the shipping module's debug is enabled.

lat9:

The state/zipcode combination needs to be valid, i.e. you can't enter a Florida Zipcode for California. The details of why no shipping is available will be in a ups trace-log if the shipping module's debug is enabled.

I did some tests and I found out the result is very random. Under the "Estimated Shipping" tool, sometimes I can get a quote but sometimes I cannot. Yes, the state and zipcode I used are matched/valid.

Assuming my store is located in TX 75201 (which I set in the plug-in, not sure if it is related). Here are some data points:

For the following combinations, I can get a quote:
WI 53105
HI 96769
GA 30303
FL 32819
MN 56181
CA 92595

For the following combinations, I cannot get a quote:
VA 22630
GA 30097
FL 32128
MN 55987
CA 90275

In the log file, if I cannot get a quote, here is the response

    "response": {
        "errors": [
            {
                "code": "111542",
                "message": "Invalid Destination."
            }
        ]

I'm guessing (keyword) that the fail-to-quote on some of those state/zip combinations is that UPS now requires a City to further determine whether an address is valid to quote.

I ran a test with a zipcode near me in Florida (34957) that spans a couple of counties (fun for sales tax). On the shipping estimator, I was met with the same message/UPS return code. When I signed in with a full-up address that included a city "Jensen Beach", quotes were supplied.

I'm not sure at this time how to "deal with" that, other than possibly modifying the message to indicate that the customer might try signing in so that their full address is presented for the quote.

I just downgraded this plug-in back to v1.3.8 using the old API in my testing site. This issue was resolved. So it should be related to the API.

Not sure if UPS will fix it in the nearly future.

Yeah, this issue is not very critical, since I can get a valid quote during the checkout.

Update. I just modified UpsOAuthApi.php file to use the old API. The "Estimated Shipping" issue was resolved.

Around line 26, change

    const API_RATING = 'api/rating/v2409/Shoptimeintransit';    //- Gives *all* UPS shipping methods for a given From->To address.
    const API_RATING_SUBVERSION = '2409';

to

    const API_RATING = 'api/rating/v1/Shop';    //- Gives *all* UPS shipping methods for a given From->To address.
//    const API_RATING_SUBVERSION = '2409';

Around line 288, comment out this line.

'SubVersion' => self::API_RATING_SUBVERSION,

The old API still works today, but not sure when it will be retired by UPS.

I've got a question about the Customer Classification Code. I was using 01: Daily Rates but just changed it to 00: Rates associated with your Shipper Number

The rates returned did not change. Is there something else that needs done to get the negotiated rates?

On this site, we're using v 1.3.5. In reading the release notes for the newer versions, none mention this as a fix.

jeking:

I've got a question about the Customer Classification Code. I was using 01: Daily Rates but just changed it to 00: Rates associated with your Shipper Number

The rates returned did not change. Is there something else that needs done to get the negotiated rates?

On this site, we're using v 1.3.5. In reading the release notes for the newer versions, none mention this as a fix.

UPS' returned rates leave me baffled at times as well. All I can suggest is to enable the shipping-module's debug so that you'll get a debug-log of the rate-request and the associated response to see what's going on.

Thanks for the quick reply. Log shows:
"Code": "119084",
"Description": "Missing / Invalid Shipper Number. Returned rates are Retail Rates."

Looks like I need to check or re-create the credentials.

I checked the set-up and confirmed the shipping number is correct: https://i.imgur.com/Be6DZR2.png

Is there anything else I can check or is this another case of 'baffled'?

jeking:

I checked the set-up and confirmed the shipping number is correct: https://i.imgur.com/Be6DZR2.png

Is there anything else I can check or is this another case of 'baffled'?

one might think that the client id and the client secret might we wrong for the shipper id.

but that is pure conjecture on my part!

good luck.

jeking:

I checked the set-up and confirmed the shipping number is correct: https://i.imgur.com/Be6DZR2.png

Is there anything else I can check or is this another case of 'baffled'?

You might try contacting UPS directly; perhaps their support personnel have some answers.

lat9:

jeking:

I checked the set-up and confirmed the shipping number is correct: https://i.imgur.com/Be6DZR2.png

Is there anything else I can check or is this another case of 'baffled'?

You might try contacting UPS directly; perhaps their support personnel have some answers.

That was my next step. Thank you!

I updated to version 1.4.1-beta1 (includes/modules/shipping/upsoauth.php), but the message in admin -> Modules -> Shipping Modules still shows - NOTE: A NEW VERSION OF THIS PLUGIN IS AVAILABLE. [Details]

Am I missing something?

dml73:

I updated to version 1.4.1-beta1 (includes/modules/shipping/upsoauth.php), but the message in admin -> Modules -> Shipping Modules still shows - NOTE: A NEW VERSION OF THIS PLUGIN IS AVAILABLE. [Details]

Am I missing something?

You're not missing anything. The notice comes from Zen Cart core, not the module. plugin_version_check_for_updates() compares the Plugins Library version to yours with strcmp(), which compares text instead of numbers. If the library listing is typed as "v1.4.0" (or anything else that doesn't sort like a plain number), it always looks "newer" than the installed version, so the notice never goes away.

Until it's fixed in an official release, you can patch includes/modules/shipping/upsoauth.php. Find this line:

$new_version_details = plugin_version_check_for_updates(self::ZEN_CART_PLUGIN_ID, $this->moduleVersion);

Right after it, add:

if ($new_version_details !== false) {
    $listed_version = '';
    if (preg_match('/\d+(?:\.\d+)*/', (string)($new_version_details['latest_plugin_version'] ?? ''), $matches) === 1) {
        $listed_version = $matches[0];
    }
    if ($listed_version === '' || version_compare($listed_version, $this->moduleVersion, '<=')) {
        $new_version_details = false;
    }
}

This re-checks the listed version numerically and shows the notice only when the library version really is higher. A genuine future release will still trigger it.

If you'd rather not edit the file, setting the module's Update Check to "Never" hides the notice. You just won't get update alerts for this module.

The attached upsoauth.php is 1.4.0 with this fix applied. I haven't looked at 1.4.1-beta1, so if you're on the beta, add the snippet above to your file rather than replacing it with this one.

dml73:

I updated to version 1.4.1-beta1 (includes/modules/shipping/upsoauth.php), but the message in admin -> Modules -> Shipping Modules still shows - NOTE: A NEW VERSION OF THIS PLUGIN IS AVAILABLE. [Details]

Am I missing something?

Nope, you'll receive that because 1.4.1-beta1 is different from 1.4.1 (which is the most recent version posted in the plugins).

dml73:

I updated to version 1.4.1-beta1 (includes/modules/shipping/upsoauth.php), but the message in admin -> Modules -> Shipping Modules still shows - NOTE: A NEW VERSION OF THIS PLUGIN IS AVAILABLE. [Details]

Am I missing something?

The issue persists. I just downloaded 1.4.0 & this

mprough:

dml73:

I updated to version 1.4.1-beta1 (includes/modules/shipping/upsoauth.php), but the message in admin -> Modules -> Shipping Modules still shows - NOTE: A NEW VERSION OF THIS PLUGIN IS AVAILABLE. [Details]

Am I missing something?

The issue persists. I just downloaded 1.4.0 & this

Since the shipping-module's version-to-compare is 1.4.0 as is the most-recent version uploaded to the Zen Cart plugins, this is an issue with the plugin_version_check_for_updates function. What Zen Cart version is in use?

Update: I'm not seeing this behavior on Zen Cart 2.2.2.

lat9:

mprough:

dml73:

I updated to version 1.4.1-beta1 (includes/modules/shipping/upsoauth.php), but the message in admin -> Modules -> Shipping Modules still shows - NOTE: A NEW VERSION OF THIS PLUGIN IS AVAILABLE. [Details]

Am I missing something?

The issue persists. I just downloaded 1.4.0 & this

Since the shipping-module's version-to-compare is 1.4.0 as is the most-recent version uploaded to the Zen Cart plugins, this is an issue with the plugin_version_check_for_updates function. What Zen Cart version is in use?

2.2.2 PHP 8.5.11