New feature: Added support for UPS Rest APIs

[fballiano]

3rd of June 2024 UPS will shut down their SOAP APIs as stated on their website here:
https://developer.ups.com/oauth-developer-guide?loc=en_US

All the websites using UPS will stop working on that date

This PR is aims to port what M2 did to implement UPS Rest APIs with:
https://experienceleague.adobe.com/docs/commerce-knowledge-base/kb/troubleshooting/known-issues-patches-attached/ups-shipping-method-integration-migration-from-soap-to-restful-api.html

Most of the changes in M2 as in these 2 files:

• https://github.com/magento/magento2/blob/2.4-develop/app/code/Magento/Ups/Model/Carrier.php (most complicated changes are here)
• https://github.com/magento/magento2/blob/2.4-develop/app/code/Magento/Ups/Model/UpsAuth.php

[fballiano]

I have something working

[fballiano]

it kinda works now:

at least until creating an order, in the backend is shown correctly:

I don't know what other tests are needed after the order.

[fballiano]

@Flyingmana I think we should add a notification in the the backend for all the users about this

[ragnese]

Don't we also need to do getTracking for Rest?

[fballiano]

About this PR, I'm waiting for some tests results by a customer, it seems to be working fine (for sure it's not perfect but it is what it is).

Since 3rd June is near the corner, in case I don't get any feedback from the community here, I'll still merge this PR and release 20.7.0 with a note about this particular feature.

And after june we'll remove the code about XML and re-release.

[fballiano]

It's 7th may, regardless of the tests results I think it's time this PR gets merged and released to give merchants a few weeks to test it out and give feedback.

I'll merge and release 20.7.0 with a clear statement about this UPS module.

Let's hope for the best.

[ragnese]

I know it's a little late now, but I just thought of something while I was working on bringing this change into our production system: Should we have used the "live" URLs (onlinetools.ups.com) for the defaults in config.xml, instead of the testing URLs (wwwcie.ups.com)?

Do you think it would be worth doing a quick patch for that?

[fballiano]

@ragnese if you configure it in "live" mode it uses the live URL right? I think it does

[fballiano]

I've received this:

[fballiano]

if I click here:

I get

[ragnese]

First about the config params: The way we have it now, it'll use what's set in the config if it's there. Then it'll fallback to either the live or default URLs if the config value is falsey.

I'll look at the tracking error. It looks like the request is actually returning an error response and we're just not handling that correctly. So, we need to handle the bad response better, but we also need to figure out what the actual issue is with the request. I'm looking into it now.

[fballiano]

what if we remove the configuration of the API URLs? I don't even know what it was done that way :-\

[ragnese]

I agree that making them configurable was always a weird choice. But, that could turn into a breaking change for anyone who might be pointing to some custom proxy to escape a firewall or something... who knows what weird things people may be doing...

On the tracking error, it looks like you might have the error response string in that screenshot, but it's cut off (the "#1" line of the stack trace). Could you post what that response actually says? I bet it's that we don't have tracking permission on the auth. I noticed that the Admin panel config for the clientId and clientSecret list the permissions to acquire when setting up a UPS app, but it doesn't list "tracking" as one of the needed permissions, so that's probably it.

[fballiano]

@ragnese the error is

Array ( [code] => TV0011 [message] => Missing transactionSrc )

[ragnese]

Okay, that's an easy fix. We just need to add any kind of identifier that is "us". For other code I've used, we used our UPS merchantId, but since that's not something we ask for in the config, we could just put something like "OpenMage" and I think that'll be fine.

[fballiano]

@ragnese I started to post something at #3976 let's use that new PR for the new addition :-)

[sebadiginet]

HI

There is one bug/problem - currency change is not working. Our calculation from UPS we get in PLN. We have same result in debug shipping_ups.log in PLN and EUR currency websites so its proper answer from API UPS. But checkout in website EUR currency we have not available any shipping method by UPS. Normally its working without problem with exchange made in magento for both previous version of UPS and for Fedex.

[sebadiginet]

Probably i found reason - line in Ups.php - $allowedCurrencies = Mage::app()->getStore()->getAvailableCurrencyCodes(); is wrong because it should be $allowedCurrencies = Mage::getModel('directory/currency')->getConfigAllowCurrencies();
Store view can have other currencies allowed then response from UPS. Calculation should be made by global allowed currencies for openmage. In such correction its working

[iamniels]

I ran into a bug, I got this error:

Code: 110548
Message: A shipment cannot have a KGS/IN or LBS/CM or OZS/CM as its unit of measurements

I checked the request and it contained:

"Package": [
                {
                    "PackagingType": {
                        "Code": "00",
                        "Description": "Packaging"
                    },
                    "Dimensions": {
                        "UnitOfMeasurement": {
                            "Code": "IN",
                            "Description": "Inches"
                        },
                        "Length": "5",
                        "Width": "5",
                        "Height": "5"
                    },
                    "PackageWeight": {
                        "UnitOfMeasurement": {
                            "Code": "KGS"
                        },
                        "Weight": "1.265"
                    }
                }

By removing the Dimensions the error has been resolved.

[sebadiginet]

I got error today when try to configure firecheckout extension :
looks that error with that line in Ups.php : $methods[$methodCode] = $methodData->getText();

Fatal error: Uncaught Error: Call to a member function getText() on string in /opt/lampp/htdocs/hpc/app/code/core/Mage/Usa/Model/Shipping/Carrier/Ups.php:1344 Stack trace: #0 /opt/lampp/htdocs/hpc/app/code/local/TM/FireCheckout/Model/System/Config/Source/Shipping/Allmethods.php(31): Mage_Usa_Model_Shipping_Carrier_Ups->getAllowedMethods() #1 /opt/lampp/htdocs/hpc/app/code/core/Mage/Adminhtml/Block/System/Config/Form.php(463): TM_FireCheckout_Model_System_Config_Source_Shipping_Allmethods->toOptionArray(false) #2 /opt/lampp/htdocs/hpc/app/code/core/Mage/Adminhtml/Block/System/Config/Form.php(229): Mage_Adminhtml_Block_System_Config_Form->initFields(Object(Varien_Data_Form_Element_Fieldset), Object(Mage_Core_Model_Config_Element), Object(Mage_Core_Model_Config_Element)) #3 /opt/lampp/htdocs/hpc/app/code/core/Mage/Adminhtml/Block/System/Config/Form.php(164): Mage_Adminhtml_Block_System_Config_Form->_initGroup(Object(Varien_Data_Form), Object(Mage_Core_Model_Config_Element), Object(Mage_Core_Model_Config_Element)) #4 /opt/lam in /opt/lampp/htdocs/hpc/app/code/core/Mage/Usa/Model/Shipping/Carrier/Ups.php on line 1344

[fballiano]

@sebadiginet already solved here: #4013

please open new issues because it's much more difficult to track comments on old PRs

[sebadiginet]

There is possibility to add estimated delivery time for new version of ups ? I have it ready working for fedex also with newer wsdl RateService_v31.wsdl which support new shipping methods like fedex regional - i can share with openmage to make upgrade for new version. Its described for example here https://magento.stackexchange.com/questions/147208/ups-api-estimated-delivery-date