Open ntmhung opened 1 year ago
Hi all,
I have this issue on Magento 1, could I download this update or migrate guide UPS OAuth2 to Magento 1
https://github.com/magento/magento2/issues/37534#issuecomment-1741505152
@dazz397 Hi, could you please share this module?
you can download from here https://www.ecomplugins.com/magento2-ups-ground-with-rest-api
https://github.com/magento/magento2/issues/37534#issuecomment-1959108469
Hi @vipin12117 , is this plugin using UPS OAuth2?
yes it is using UPS OAuth2
@vipin12117 thank you
@vipin12117 currently i don't have plan to buy it.
Hello All,
I have a solution for the UPS OAuth2 Magento 2,
For seamless UPS integration with Magento 2.4.3 and beyond, consider using this comprehensive extension that supports UPS OAuth 2.0. It's compatible with all Magento 2 versions and ensures secure shipping integration.
Extension URL: https://expoundcoderz.com/ups-oauth2-magento-2-extension-secure-shipping-integration.html
This should resolve your UPS connectivity issue swiftly, allowing your website to process orders without interruption.
Please let me know If you have any questions or you can directly contact me at this: jatin@expoundcoderz.com
Thanks
Hello All,
I have a solution for the UPS OAuth2 Magento 2,
For seamless UPS integration with Magento 2.4.3 and beyond, consider using this comprehensive extension that supports UPS OAuth 2.0. It's compatible with all Magento 2 versions and ensures secure shipping integration.
Extension URL: https://expoundcoderz.com/ups-oauth2-magento-2-extension-secure-shipping-integration.html
This should resolve your UPS connectivity issue swiftly, allowing your website to process orders without interruption.
Please let me know If you have any questions or you can directly contact me at this: jatin@expoundcoderz.com
Thanks
Hi @ninja-jatin, can I apply this extension to Magento 1.9?
@glo05363 have started using this patch on a 2.4.5-p6 site and it appears that the rates returned are all residential-rated, they include the residential surcharge. Naturally this is not so obvious as the charges involved in the rate calculation are not returned in the data structure the UPS REST API responds with, as they are with the FedEx API responses. I happened to have an alternate e-commerce site (not Magento) that I was comparing rates against to notice it initially.
In the initial $rateParams assignment in _getRestQuotes()
, part of the array structure includes the element ['RateRequest']['Shipment']['ShipTo']['Address']['ResidentialAddressIndicator']
and assigns the value of $residentialAddressIndicator
to it. However, this is incorrect - according to the documentation for this available at https://developer.ups.com/api/reference?loc=en_US#tag/Rating_other (well... go the API catalog, go into the Rating docs, it's kind of wild in there), the value associated with that element is not what's important, it's the existence of that element which determines whether you are requesting a residentially-flagged request or not:
Residential Address flag. This field is a flag to indicate if the destination is a residential location. True if ResidentialAddressIndicator tag exists; false otherwise. This element does not require a value and if one is entered it will be ignored. Note: When requesting TimeInTransit information, this indicator must be passed to determine if Three Day Select or Ground shipment is eligible for Saturday Delivery at no charge. If this indicator is not present, address will be considered as commercial. Empty Tag.
Unlike the SOAP API that UPS is about to decommission, the value does not matter here, and including that parameter with every request with the associated value determined by whether or not it's to be rated commercial or residential is instead ensuring that every request is being rated as residential.
While I'm here, I would also like to point out that it would be much easier to work around this residential indicator issue (currently I'm hacking together my own version of the patch to "fix" this) if the creation of the REST request array was handled by a separate public function so that we could use DI interceptors with it to make adjustments to the request parameters, but everything's tied up in that protected _getRestQuotes() function as a whole, so you have to override the whole function to get anything done, or tinker with the patch.
I expect that there will be a lot of devs racing to get these patches applied in April/May as the deadline comes closer, and issues like this residential flagging thing will become a lot more important.
Hi @chernenm Is there any patch available for magento 2.3.5 ?
@magento give me 2.4-develop instance
Hi @fballiano. Thank you for your request. I'm working on Magento instance for you.
Hi @fballiano, here is your Magento Instance: https://ce2263a3554cc7ce369b711b0daf164b.instances-prod.magento-community.engineering Admin access: https://ce2263a3554cc7ce369b711b0daf164b.instances-prod.magento-community.engineering/admin_8b28 Login: 564b2123 Password: c920222c5672
Hello everyone, We have managed to enable UPS shipping methods through OAuth.
I leave you our experience updating UPS OAuth in Magento 2.4.4-p6.
With the official Magento patch provided at: https://experienceleague.adobe.com/en/docs/commerce-knowledge-base/kb/troubleshooting/known-issues-patches-attached/ups-shipping-method-integration-migration-from-soap-to-restful-api
We generate an application from the UPS page: You will need to register here: https://developer.ups.com/get-started Then go to "My Apps" > "Add Apps":
After that, it is updated from the Magento backend (shipping methods) UPS: Client ID (UPS APP) = username Client Secret = password
We have not found any problems in moving forward with this modification. I hope it is useful for you to resolve this update.
Regards, Francisco
When creating the UPS Integration App in UPS, what did you use as the callback url?
I tried to set this up and am now getting this error when I go to check out: Exception #0 (Magento\Framework\Exception\RuntimeException): Type Error occurred when creating object: Magento\Ups\Model\Carrier, Magento\Ups\Model\Carrier::__construct(): Argument #18 ($upsAuth) must be of type Magento\Ups\Model\UpsAuth, Magento\Framework\HTTP\ClientFactory given, called in /var/www/html/mydomain.com/vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php on line 121
Nevermind. I just needed to run upgrade and recompile Magento and now all is working.
I don't seem to be able to get this issue resolved, The UPS module asks for a login and password, I have updated to the new requirements on the UPS side and have a key and secret key, however I don't know where or what to do with them. I've tried using my normal login and password for the Magento UPS area, no luck, and I've tried different combinations of the keys with no luck. FedEx works fine, but I have better rates with UPS. This may have been answered somewhere else, I can't seem to find that solution. What am I doing wrong?
Hello everyone, We have managed to enable UPS shipping methods through OAuth.
I leave you our experience updating UPS OAuth in Magento 2.4.4-p6.
With the official Magento patch provided at: https://experienceleague.adobe.com/en/docs/commerce-knowledge-base/kb/troubleshooting/known-issues-patches-attached/ups-shipping-method-integration-migration-from-soap-to-restful-api
We generate an application from the UPS page: You will need to register here: https://developer.ups.com/get-started Then go to "My Apps" > "Add Apps":
- I need API credentials because: "I want to integrate UPS technology into my business"
- Choose an account to associate with these credentials: "Create a new account" And follow the steps.
- Finally, you need to add 'Products' to the 'Application'. (Has to!). This point was not clarified previously.
After that, it is updated from the Magento backend (shipping methods) UPS: Client ID (UPS APP) = username Client Secret = password
We have not found any problems in moving forward with this modification. I hope it is useful for you to resolve this update.
- If you need it for previous versions, please contact us at info@serfe.com. We will be happy to assist you.
Regards, Francisco
@Franciscof-Serfe I've followed your instructions, but I can still not receive any shipping rates. The default Gateway REST URL in Magento is https://wwwcie.ups.com/api/rating/ which is the dev environment, but even though I change it to the live url i don't receive any rates. Using Magento 2.4.7 (for testing purposes) Any suggestions?
@vipin12117 Respectfully, please stop advertising your plugin here. This is an open source project. Thanks
This new code contains an error when having EU (other options may be affected as well) as origin of shipping. Dimensions UnitOfMeasurement Code seems to be hardcoded to "IN" which will cause an error in the request in the file module-ups/Module/Carrier.php
"A shipment cannot have a KGS/IN or LBS/CM or OZS/CM as its unit of measurements"
1147 foreach ($rowRequest->getPackages() as $package) { 1148 $rateParams['RateRequest']['Shipment']['Package'][] = [ 1149 "PackagingType" => [ 1150 "Code" => "{$params['48_container']}", 1151 "Description" => "Packaging" 1152 ], 1153 "Dimensions" => [ 1154 "UnitOfMeasurement" => [ 1155 "Code" => "IN", <---------------------------------- 1157 "Description" => "Inches" 1158 ], 1159 "Length" => "5", 1160 "Width" => "5", 1161 "Height" => "5" 1162 ], 1163 "PackageWeight" => [ 1164 "UnitOfMeasurement" => [ 1165 "Code" => "{$rowRequest->getUnitMeasure()}" 1166 ], 1167 "Weight" => "{$this->_getCorrectWeight($package['weight'])}" 1168 ] 1169 ]; 1170 }
This new code contains an error when having EU (other options may be affected as well) as origin of shipping. Dimensions UnitOfMeasurement Code seems to be hardcoded to "IN" which will cause an error in the request in the file module-ups/Module/Carrier.php
"A shipment cannot have a KGS/IN or LBS/CM or OZS/CM as its unit of measurements"
1147 foreach ($rowRequest->getPackages() as $package) { 1148 $rateParams['RateRequest']['Shipment']['Package'][] = [ 1149 "PackagingType" => [ 1150 "Code" => "{$params['48_container']}", 1151 "Description" => "Packaging" 1152 ], 1153 "Dimensions" => [ 1154 "UnitOfMeasurement" => [ 1155 "Code" => "IN", <---------------------------------- 1157 "Description" => "Inches" 1158 ], 1159 "Length" => "5", 1160 "Width" => "5", 1161 "Height" => "5" 1162 ], 1163 "PackageWeight" => [ 1164 "UnitOfMeasurement" => [ 1165 "Code" => "{$rowRequest->getUnitMeasure()}" 1166 ], 1167 "Weight" => "{$this->_getCorrectWeight($package['weight'])}" 1168 ] 1169 ]; 1170 }
Great @sanmic ! I'm glad you managed to resolve it. Can you update the fix?
@chernenm @engcom-Bravo @ihor-sviziev Can any of you review the official patch to update it with this fix?
Regards!
@sanmic how did you solve it?
For Open source 2.4.6, Tried to apply the patch.
I have left all my configurations the same and just switched from UPS XML To UPS REST. (of course new credentials have been entered correctly).
My configuration is set to "Commercial" destination type. But shipping rate quotes returned from UPS are higher than before.
Something to do with the Residential Address Indicator as mentioned by @jaminion. (https://github.com/magento/magento2/issues/37534#issuecomment-1971635631).
In UPS REST, I believe the tag cannot be there at all, in the new REST call.
This new code contains an error when having EU (other options may be affected as well) as origin of shipping. Dimensions UnitOfMeasurement Code seems to be hardcoded to "IN" which will cause an error in the request in the file module-ups/Module/Carrier.php
"A shipment cannot have a KGS/IN or LBS/CM or OZS/CM as its unit of measurements"
1147 foreach ($rowRequest->getPackages() as $package) { 1148 $rateParams['RateRequest']['Shipment']['Package'][] = [ 1149 "PackagingType" => [ 1150 "Code" => "{$params['48_container']}", 1151 "Description" => "Packaging" 1152 ], 1153 "Dimensions" => [ 1154 "UnitOfMeasurement" => [ 1155 "Code" => "IN", <---------------------------------- 1157 "Description" => "Inches" 1158 ], 1159 "Length" => "5", 1160 "Width" => "5", 1161 "Height" => "5" 1162 ], 1163 "PackageWeight" => [ 1164 "UnitOfMeasurement" => [ 1165 "Code" => "{$rowRequest->getUnitMeasure()}" 1166 ], 1167 "Weight" => "{$this->_getCorrectWeight($package['weight'])}" 1168 ] 1169 ]; 1170 }
@sanmic While reviewing the following
I have also found out that the newly required RATE API payload fields on "DimensionUnit" were hard coded into the UPS/carrier file and we have made the changes for the same as per : https://github.com/magento/magento2/issues/38618#issuecomment-2066513710
Please find few details on above link and post. This will be delivered soon. Thanks
can somebody post the code they changed to fix it?
@fballiano If you need a quick and dirty fix you can change the code on line 56 -> "Code": "CM",
@sanmic actually no, I'm porting this functionality to OpenMage ;-)
Hi @sanmic,
We are addressing this issue into the following Github issue, Please find all the updates in here https://github.com/magento/magento2/issues/38618 Our internal team is working on the same we will be delivering the same soon.
Thanks.
@pnlinh there's already this for mgento 1.9 https://github.com/OpenMage/magento-lts/pull/3878
@coderz-expert spamming on github is not a good why of finding customers.
Hi @chernenm Is there any patch available for magento 2.3.5 ?
Hi Did you found answer for this version. We are also using same right now
@fballiano sounds good, let me testing
Can you please send me the code
Sent from Outlook for Androidhttps://aka.ms/AAb9ysg
From: Ngoc Linh Pham @.> Sent: Thursday, May 9, 2024 4:29:17 PM To: magento/magento2 @.> Cc: Rahul Dambare @.>; Comment @.> Subject: Re: [magento/magento2] UPS API Change Request (Issue #37534)
Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
@fballianohttps://github.com/fballiano sounds good, let me testing
— Reply to this email directly, view it on GitHubhttps://github.com/magento/magento2/issues/37534#issuecomment-2102441611, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHTGBV4IN2DYNYMX7HJJFKDZBNJILAVCNFSM6AAAAAAYNFKIW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBSGQ2DCNRRGE. You are receiving this because you commented.Message ID: @.***>
Can you please send me the code Sent from Outlook for Androidhttps://aka.ms/AAb9ysg … ____ From: Ngoc Linh Pham @.> Sent: Thursday, May 9, 2024 4:29:17 PM To: magento/magento2 @.> Cc: Rahul Dambare @.>; Comment @.> Subject: Re: [magento/magento2] UPS API Change Request (Issue #37534) Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. @fballianohttps://github.com/fballiano sounds good, let me testing — Reply to this email directly, view it on GitHub<#37534 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHTGBV4IN2DYNYMX7HJJFKDZBNJILAVCNFSM6AAAAAAYNFKIW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBSGQ2DCNRRGE. You are receiving this because you commented.Message ID: @.***>
@rahuldambare you can see here: https://github.com/OpenMage/magento-lts/pull/3878
Can you please send me the code Sent from Outlook for Androidhttps://aka.ms/AAb9ysg … ____ From: Ngoc Linh Pham @.**> Sent: Thursday, May 9, 2024 4:29:17 PM To: magento/magento2 @.**> Cc: Rahul Dambare @.**>; Comment @.**> Subject: Re: [magento/magento2] UPS API Change Request (Issue #37534) Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. @fballianohttps://github.com/fballiano sounds good, let me testing — Reply to this email directly, view it on GitHub<#37534 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHTGBV4IN2DYNYMX7HJJFKDZBNJILAVCNFSM6AAAAAAYNFKIW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBSGQ2DCNRRGE. You are receiving this because you commented.Message ID: @.***>
@rahuldambare you can see here: OpenMage/magento-lts#3878
Are these changes for Magento 2.3.5 version or 2.4 as per this link it shows for 2.4 version ? can you please confirm or provide the zip file for the module.
Hi @chernenm Is there any patch available for magento 2.3.5 ?
Hi Did you found answer for this version. We are also using same right now
Hi @rahuldambare,
Unfortunately we do not have a patch for a 2.3 versions, since it is no longer supported.
@chernenm Please connect us support@ecomplugins.com for magento 2.3.x support.
@Franciscof-Serfe Why flagged me ? why I can not help to other peoples ?
Does anybody have issues not receiving their negotiated rates after switching?
Yes, same issue here.
@jaminion @yomyyo You must check API logs in magento var/log/shipping.log
"ShipmentRatingOptions" => array( "TPFCNegotiatedRatesIndicator" => "Y", "NegotiatedRatesIndicator" => "Y" ),
Then check admin setting if negotiated rates enabled in ups plugin.
If still facing issues then contact us support@ecomplugins.com
you should check admin setting if enabled or check var/log/shipping.log if tag being pass ?
Admin settings are enabled, reviewing the log confirms that negotiated rates are being requested, but the returned rates are significantly higher than the rates the XML API is returning for identical shipments.
Can you share api logs?
Hey @jaywilliams if you are reviewing the log check and see if the "ResidentialAddressIndicator" is being passed in the request. In the new UPS REST API, they do not check the value of that parameter - they only check if it exists to determine if the request is residential or not. UPS also does not itemize out the residential rate adjustment in the data returned so it's difficult to determine if that's affecting you.
It looks to me like they are still putting that parameter in the request and setting the value of it based on whether it's intended to be a residentially-rated request, rather than only including the parameter if it is to be rated residential.
@jaywilliams i think issue with discounted rates.
$rateParams['RateRequest']['Shipment']['ShipmentRatingOptions']['NegotiatedRatesIndicator'] = "Y";
So need to confirm if above parameter being pass in request. Then need to review API response.
I've added the necessary lines to the API request, and am still getting significantly higher quotes on the REST API.
@jaminion the residential address indicator is being passed, which does increase the rates, but I am passing the same residential flag on the XML request so they should still be the same.
While debugging this issue, I've found that the stock M2 UPS REST patch sends "01" as the AddressLine
on the Shipper
and ShipTo
, which doesn't appear to affect rates but is definitely not the correct address and should simply be removed.
That's the really tricky thing about the residential indicator for rating on their REST API - they changed how it works (it's wild and awkward and I have no good things to say about it). It's difficult to get to the documentation as searching doesn't really work since they hide/show the content based on clicks. If you go the rating api, and look under Shipment->ShipTo->Address, there is a "ResidentialAddressIndicator" element, and their documentation there is:
Residential Address flag. This field is a flag to indicate if the destination is a residential location. True if ResidentialAddressIndicator tag exists; false otherwise. This element does not require a value and if one is entered it will be ignored.
Note: When requesting TimeInTransit information, this indicator must be passed to determine if Three Day Select or Ground shipment is eligible for Saturday Delivery at no charge. If this indicator is not present, address will be considered as commercial. Empty Tag.
If the rates are wildly off then yeah it's probably something else, but we were seeing differences from about $3 to $5.50 which were accounted for when editing the patch to change how that works (only include that entire element in that section conditionally).
I'm a little confused with the explanation regarding the negotiated rates with UPS. My rates are being correctly calculated when I use my UPS negotiated rates account number in the admin back end. I am unable to produce a shipping label when trying to save after my items were added to my package. If I go back in to the admin area and change the account id back to the standard six digit number I can create the shipment with the negotiated rate.
Description
My client has informed me that starting from June 5, 2023, UPS no longer issues new access keys. UPS is going to change to use Oauth 2.0.
I think the magento/module-ups module should be updated to meet the requirement. It needed to be done before June 5, 2023. This is the API document https://developer.ups.com/api/reference#operation/GenerateToken.
Expected behavior
The magento/module-ups supports using the OAuth security model from UPS.
Benefits
It will help new users planning to use the UPS shipping method connect to the UPS API after June 5, 2023.
Additional information
No response
Release note
No response