Commercial destination should not be treated as residential

[dmytrokaplin]

Description (*)

The UPS REST rate request builder in \Magento\Ups\Model\Carrier always includes the ResidentialAddressIndicator field in the ShipTo.Address section, even when the destination type is commercial (49_residential = "02").

According to UPS API behavior, the mere presence of the ResidentialAddressIndicator tag (even with an empty value) makes the shipment be treated as residential, which results in “Demand Surcharge - Residential” being applied and higher rates being returned for commercial destinations.

This pull request updates the REST request payload builder so that:

• ResidentialAddressIndicator is only included when 49_residential === "01" (residential).
• For non-residential (e.g. "02" commercial) requests, the ResidentialAddressIndicator field is not added to the payload at all.

This aligns the REST implementation with the existing XML implementation, which already adds ResidentialAddressIndicator conditionally based on 49_residential.

Manual testing scenarios (*)

Scenario 1: Commercial destination should not be treated as residential

1. Configure UPS shipping in Magento with valid UPS credentials and enable the REST API integration (US → US shipment).
2. Create a quote/cart with:
   • Origin in the US (e.g. Miami, FL 33127).
   • Destination in the US with a commercial destination type (49_residential = "02").
   • A package weight of approximately 20.8 lbs.
3. Request shipping rates (via storefront checkout or REST API).
4. Before the fix:
   • Inspect the UPS REST request (debug/logs):
     • ShipTo.Address.ResidentialAddressIndicator is present with an empty value.
   • UPS returns rates that include “Demand Surcharge - Residential is applied on Package 0” and higher total charges.
5. After the fix:
   • Inspect the UPS REST request again:
     • ShipTo.Address does not contain the ResidentialAddressIndicator field for 49_residential = "02".
   • UPS returns commercial rates (no “Demand Surcharge - Residential” message), and totals match expected commercial pricing.

Scenario 2: Residential destination still behaves as residential

1. Using the same configuration, create a quote/cart with a residential destination (49_residential = "01").
2. Request shipping rates.
3. Verify that:
   • ShipTo.Address.ResidentialAddressIndicator is present in the UPS REST request.
   • UPS returns rates that include residential surcharge (e.g. “Demand Surcharge - Residential is applied on Package 0”).
   • Behavior matches previous residential handling and the XML-based UPS rates.

Resolved issues:

1. resolves [Issue] Commercial destination should not be treated as residential #40314: Commercial destination should not be treated as residential

[m2-assistant]

Hi @dmytrokaplin. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[ct-prd-pr-scan]

The security team has been informed about this pull request due to the presence of risky security keywords. For security vulnerability reports, please visit Adobe's vulnerability disclosure program on HackerOne or email psirt@adobe.com.

[lbajsarowicz]

✅ Great, simple change.

Could you add Integration Test to cover both variants of this scenario?

[engcom-Hotel]

@magento create issue

[ct-prd-pr-scan]

The security team has been informed about this pull request due to the presence of risky security keywords. For security vulnerability reports, please visit Adobe's vulnerability disclosure program on HackerOne or email psirt@adobe.com.