UPS Shipping using RESTful/OAuth API [Support Thread]

njcyx:

Hi @lat9, any plan to support Saturday delivery option?
This is the first request I've heard. How about creating an issue on https://github.com/lat9/upsoauth for tracking?

I am running 1.3.7 of the module on zc 1.5.7c. I have noticed a problem when I use my shipper number to try to grab the discounted rates it does not calculate things properly with multipackage orders. I am not sure if this is module side or something with ups. If create a heavy order (49.40 lbs) and set my max package weight to 200 lbs the estimate is 1 pkg x 49.40 lbs and the cost is $27.60. If I change the max package weight to 35 lbs in zc then the module shows 2 pkgs x 27.17 lbs and the total is $22.46. So somehow the estimate for two boxes is less than in a single shipment which of course is not what I actually get charged. Anyone else seeing this if you try to use discounted rate?

spyderrobotics:

I am running 1.3.7 of the module on zc 1.5.7c. I have noticed a problem when I use my shipper number to try to grab the discounted rates it does not calculate things properly with multipackage orders. I am not sure if this is module side or something with ups. If create a heavy order (49.40 lbs) and set my max package weight to 200 lbs the estimate is 1 pkg x 49.40 lbs and the cost is $27.60. If I change the max package weight to 35 lbs in zc then the module shows 2 pkgs x 27.17 lbs and the total is $22.46. So somehow the estimate for two boxes is less than in a single shipment which of course is not what I actually get charged. Anyone else seeing this if you try to use discounted rate?
Two packages of a lesser weight tend to cost less than a single package that's twice the weight.

It might be that the 2 box you actually sent are not weighting 27.17 lbs. Do you have an invoice from UPS with the actual weight and shipping cost of each box? Comparing this information could help spot the origin of the problem.

lat9:

Two packages of a lesser weight tend to cost less than a single package that's twice the weight.

I am using shipstation if that makes a difference. I am using my ups number that shipstation gives me.

Here is another sample shipment:

So if I have it set up with a max of 200 lbs and I have a cart with 36lbs of product the cart shows 1 box @ 36lbs ($23.18)

If I set zc to 30lbs max then the cart shows 2 boxes @ 19.8 lbs. ($22.62)

The weight difference is because it adds the 10% per the zc default setting.

When I do a rate check in shipstation 1 box at 36 lbs would be $23.18

Two boxes of smaller size at 19.8 lbs each would actually be $15.91 per box. $31.82 total.

So single package seems to work fine and grabs the right rate.

Double gets wonky. I am not sure if this is because of trying to grab the rate they have worked out with shipstation or if its something in the module.

lat9:

Two packages of a lesser weight tend to cost less than a single package that's twice the weight.

in my experience, this is not the case. especially if the package does not meet the overweight surcharge, typically 50 lbs or 70 lbs depending on the service.

spyderrobotics:

I am using shipstation if that makes a difference. I am using my ups number that shipstation gives me.

Here is another sample shipment:

So if I have it set up with a max of 200 lbs and I have a cart with 36lbs of product the cart shows 1 box @ 36lbs ($23.18)

If I set zc to 30lbs max then the cart shows 2 boxes @ 19.8 lbs. ($22.62)

The weight difference is because it adds the 10% per the zc default setting.

When I do a rate check in shipstation 1 box at 36 lbs would be $23.18

Two boxes of smaller size at 19.8 lbs each would actually be $15.91 per box. $31.82 total.

So single package seems to work fine and grabs the right rate.

Double gets wonky. I am not sure if this is because of trying to grab the rate they have worked out with shipstation or if its something in the module.

ship station seems correct. those numbers are what i would expect.

best.

I know it was stated that package dimensions were planned for a future release. Just checking to see if there was any progress with this? I appreciate the hard work in making the module.

Thanks

n8pbm:

I know it was stated that package dimensions were planned for a future release. Just checking to see if there was any progress with this? I appreciate the hard work in making the module.

Thanks
No progress, other that I've now created a GitHub issue to remind me of the request: https://github.com/lat9/upsoauth/issues/52

Version 1.4.0 of the UPS/Restful shipping module is now available for download: https://www.zen-cart.com/downloads.php?do=file&id=2374

Note: The update might work on Zen Cart versions 1.5.4 through 1.5.6, but I have no means of testing so no guarantees. PHP versions prior to 7.0 will result in PHP fatal errors!

This release contains changes for these GitHub issues:

#49: Conditionally issue curl_close, it has no effect since PHP 8.0 and is deprecated in PHP 8.5.
#36: Don't load 'legacy' language file on zc158 and later to avoid duplicate-constant errors.
#53: Update UPS API version from v1 to v2409.
#54: Modify configuration-value access, using zc300's zen_config function, if present.
#47: Re-factor code determining error message to be displayed (thanks, @retched).
#52: Include dimensions; based on the contribution from @popupparts. This change includes two additional configuration settings.
#48: Display a message indicating that UPS doesn't ship to USPS P.O. Boxes. This change includes an additional configuration setting.

ZC 158 w/ php 8.2

After upgrading to 1.4.0, admin page keeps saying: "NOTE: A NEW VERSION OF THIS PLUGIN IS AVAILABLE. [Details]"
The storefront can't get the correct quote.

The debug log:

    "response": {
        "errors": [
            {
                "code": "111580",
                "message": "Missing or Invalid account number for Payment Details."

Rolling back to 1.3.8 and works well

siliconbug:

ZC 158 w/ php 8.2

After upgrading to 1.4.0, admin page keeps saying: "NOTE: A NEW VERSION OF THIS PLUGIN IS AVAILABLE. [Details]"
The storefront can't get the correct quote.

The debug log:

"response": {
    "errors": [
        {
            "code": "111580",
            "message": "Missing or Invalid account number for Payment Details."

> 
> Rolling back to 1.3.8 and works well
I've corrected the version number in the Zen Cart plugins (I'd submitted with a leading 'v').

For that error message, would you enable the shipping module's debug and create the log with that error. Then send it (possible zipped) via PM.

A screenshot of your UPS settings would help, too.

lat9:

I've corrected the version number in the Zen Cart plugins (I'd submitted with a leading 'v').

For that error message, would you enable the shipping module's debug and create the log with that error. Then send it (possible zipped) via PM.

A screenshot of your UPS settings would help, too.
The UPS API v2409 is much more strict than the initial v1 (no surprises there). In @siliconbug's case, the site's setup requires use of a Shipper Number that's not associated with the site's API credentials. While UPS REST API v1 provided quotes with a nagging warning message, v2409 returns a hard error with no quotes.

I've seen another case of the API's hardening. If the Origin Postcode doesn't match the origin country/state/city, v1 would still give quotes (with no message) while v2409 returns a hard error with no quotes.

Hi @lat9, is there a way we can still use new ups plug-in (v1.4.0) but with old UPS API (v1) instead of new API (v2409)?

njcyx:

Hi @lat9, is there a way we can still use new ups plug-in (v1.4.0) but with old UPS API (v1) instead of new API (v2409)?
That might work, but you'd be on your own if it doesn't.

lat9:

That might work, but you'd be on your own if it doesn't.
... and might I ask: Why do you want to go back to the v1 API (which is already deprecated by UPS)?

lat9:

... and might I ask: Why do you want to go back to the v1 API (which is already deprecated by UPS)?

Hi @lat9, I saw the recent discussion (posted by @siliconbug), saying new API is more strict than the previous API. It looks like to me that, under some special cases I can still get a quote with V1 API but error with new API.

I haven't tried new API yet and hopefully it still works on my case. But if it doesn't work well, I have to go back to the V1 api (since my old plug-in is working fine).

njcyx:

Hi @lat9, I saw the recent discussion (posted by @siliconbug), saying new API is more strict than the previous API. It looks like to me that, under some special cases I can still get a quote with V1 API but error with new API.

I haven't tried new API yet and hopefully it still works on my case. But if it doesn't work well, I have to go back to the V1 api (since my old plug-in is working fine).
@siliconbug's case is a pretty special one. The only issue I've found with clients updates is that the city/state/zipcode/country must match with v2409; one client had moved to a location nearby ... but it turned out to be a different "official" city for the updated zipcode.

Hi @lat9, I just made the new plug-in/API work. My case is the same as @siliconbug' case. Our UPS account was hacked before so a new UPS account was assigned. I haven't added the new UPS acct number to our developer account. I only put the new UPS acct in zen cart settings. I can still get a shipping quote today when using the previous API, but no quote when using the new API.

I checked our developer acct today, there is no UPS acct number in my app (the previous hacked one could be deleted by UPS already). Anyway, I added the new, valid UPS account to my app and I can get a shipping quote now using the new plug-in & API.

I just noticed an issue (v1.4.0). After I updated the module, every time when I entered Admin--Modules--Shipping--UPS, I can see a notice on the top "The UPS RESTful/OAuth shipping module was automatically updated to v1.4.0'.

I did some tests and I changed the line 166 back to the previous version and this top notice doesn't show up any more...

$messageStack->add_session(sprintf(MODULE_SHIPPING_UPSOAUTH_UPDATED, $this->moduleVersion), 'success');

to

$messageStack->add(sprintf(MODULE_SHIPPING_UPSOAUTH_UPDATED, $this->moduleVersion), 'success');

zen cart 2.1.0. php 8.2

njcyx:

I just noticed an issue (v1.4.0). After I updated the module, every time when I entered Admin--Modules--Shipping--UPS, I can see a notice on the top "The UPS RESTful/OAuth shipping module was automatically updated to v1.4.0'.

I did some tests and I changed the line 166 back to the previous version and this top notice doesn't show up any more...

$messageStack->add_session(sprintf(MODULE_SHIPPING_UPSOAUTH_UPDATED, $this->moduleVersion), 'success');

to

$messageStack->add(sprintf(MODULE_SHIPPING_UPSOAUTH_UPDATED, $this->moduleVersion), 'success');

zen cart 2.1.0. php 8.2
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