Currently, when creating a DHL shipment with an export declaration that includes a customer reference, there is a misspelling of the field 'recipientReference' as 'recepientReference'. This causes validation errors when communicating with the DHL API.

In addition, the datetime format used for the planned shipping date and time does not conform to the expected format specified by DHL.

Steps to reproduce spelling issue:
1. Create a Sales Order with a customer reference and a deliverable product.
2. Validate the SO.
3. Go to the delivery, select DHL as carrier, and confirm. → Error: Validation error #/content/exportDeclaration: extraneous key
  [recepientReference] is not permitted.

Steps to reproduce datetime issue:
1. Create a delivery using the DHL carrier.
2. Confirm the delivery.
3. Return the delivery.
4. Click "Print Return Label". → Error: Bad request #/plannedShippingDateAndTime is not well formatted
  (expected format: '2010-02-11T17:10:09 GMT+01:00').

Official DHL documentation:
https://developer.dhl.com/sites/default/files/2025-11/dpdhl-express-api-3.1.1_swagger.yaml

opw-5024363

Forward-Port-Of: odoo/enterprise#98981

Steps to reproduce the bug:
- Create a storable product "P1" and "P2" with vendor "azure interior"
- for P2 subcontracting BoM referencing "azure interior" as subcontractor and component "C1"
- Create a receipt for partner "azure interior" including 1 unit of P1 and 1 unit of P2
- Validate the receipt
- Create a return for both P1 and P2

Problem:
A picking is created with destination location set to the subcontracting location for both products,
instead of setting the partner location only for subcontracted products.

Solution:
Ensure only the move line for subcontracted products uses the subcontracting destination location,
while other returned products go back to the supplier location.

When the `picking_id.partner_id`` is changed, it triggers a write on the
picking, which in turn triggers a write on its moves, but only on the
ones that are not scrapped.

However, since the `scrapped`` field is a stored computed field, and as
it hasn't been accessed before, it needs to be computed. And because
its computation depends on `location_dest_id`, that field also needs
to be recomputed. as a result, the `location_dest_id`` of the moves that
we manually set may be changed unexpectedly.

Therefore, in the `_create_return`` function, we check that the
picking’s `partner_id` is different from the moves’ partner_id before
updating it, to avoid unnecessary writes and the chain of recomputations
that could alter our values.

Resetting the picking’s partner_id based on the move’s partner_id could
actually be removed in master, as it serves no real purpose,
the move.partner_id itself is already derived from the picking’s
partner_id. We just keep it in stable versions to avoid any unexpected
behavior changes.

opw-5208289

Forward-Port-Of: odoo/odoo#234521

Versions
--------
- 18.0+

Steps
-----
1. Have a product attribute with variant creation set to never;
2. have product using only this attribute, with only a single value;
3. open website editor on /shop;
4. enable add-to-cart button & save;
5. use button on the aforementioned product at least twice.

Issue
-----
Each time the product gets added, a new line is created.

Cause
-----
Because there's only a single value, the product configurator doesn't pop up by default when adding the product to the cart. Without the configurator pop-up, the `_cart_update` method doesn't receive any `no_variant_attribute_value_ids`, which are used find a matching line if the product template has any `no_variant` attribute.

Solution
--------
Instead of checking `product.product_tmpl._has_no_variant_attributes()`, to see if we should attempt to match `no_variant_attribute_value_ids`, check if the added product has any `no_variant` attributes that have more than one value or are optional (multi-checkbox). If not, a `no_variant` product behaves the same as a single-variant product.

opw-5093175
opw-5137351

Forward-Port-Of: odoo/odoo#234958
Forward-Port-Of: odoo/odoo#233452

There’s no constraint preventing duplicate `ir.default` records. When setting a default using `self.env['ir.default'].set()`, it searches for an existing one, but if more than one match is found, accessing `default.json_value` raises a singleton error.

This fix makes sure the search only picks one record, avoiding that crash.

Before fix:
```py
self: res.users(1,)
>>> company = self.company_id
>>> company
res.company(1,)
>>> self.env['ir.default'].create({'field_id': 4540, 'company_id': company.id, 'json_value': 7})
ir.default(9,)
>>> self.env['ir.default'].set('res.partner', 'property_account_receivable_id', 7, company_id=company.id)
Traceback (most recent call last):
  File "/home/odoo/odoo/odoo/odoo/orm/models.py", line 5630, in ensure_one
    _id, = self._ids
    ^^^^
ValueError: too many values to unpack (expected 1)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/home/odoo/odoo/odoo/odoo/addons/base/models/ir_default.py", line 107, in set
    if default.json_value != json_value:
       ^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo/odoo/odoo/orm/fields.py", line 1670, in __get__
    record.ensure_one()
  File "/home/odoo/odoo/odoo/odoo/orm/models.py", line 5633, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: ir.default(4, 9)
```

After fix:
```py
self: res.users(1,)
>>> company = self.company_id
>>> company
res.company(1,)
>>> self.env['ir.default'].create({'field_id': 4540, 'company_id': company.id, 'json_value': 7})
ir.default(10,)
>>> self.env['ir.default'].set('res.partner', 'property_account_receivable_id', 7, company_id=company.id)
True
```

opw-5228419


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#234944
Forward-Port-Of: odoo/odoo#234893