Currently, an error occurs when exporting an accounting report to 
PDF if any of the selected contacts do not have a name.

**Steps to reproduce:**
- Install the `account_reports` and `contacts` modules.
- Go to Contacts and open any contact (e.g., Azure Interior).
- Click `Add` > `Save & Close`, then `save` the contact.
- Navigate to Accounting > Reporting > Aged Receivable.
- Click `Partners` button and select the newly created contact (e.g., `Azure Interior, Other Address`).
- Click `PDF` to export the report.

**Error:**
`TypeError: sequence item 0: expected str instance, bool found`

**Root Cause:**
At [1], `options['selected_partner_ids']` is built using `partner.name`, which may 
be `False` for unnamed contacts. At [2], the `partner_value` list may therefore 
contain `False` entries coming from `options['selected_partner_ids']`. When 
calling `', '.join(partner_value)`, an error is raised because the list contains 
`non-string` (`bool`) values.

**Fix:**
This commit prevents errors when exporting reports to PDF and ensures 
that partner names are displayed in the report the same way as in the 
partner selection widget.

[1]:
https://github.com/odoo/enterprise/blob/a0ec2fcdc043cf52f1a646e84b9b97466072d47f/account_reports/models/account_report.py#L745

[2]:
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/account_reports/data/pdf_export_templates.xml#L84-L93

opw-5467321

Forward-Port-Of: odoo/enterprise#105025
Forward-Port-Of: odoo/enterprise#103828

**Issue**:
The displayed available quantity on the ecommerce product page is incorrect for rental products when "continue selling" is enabled.

**Steps to reproduce**:
- Create a rental product tracked in stock with a quantity of 5
- Enable "continue selling" and "show available quantity below 10"
- Go to the ecommerce page of this product
- Rent 3 units for a given period, confirm and pay
- Return to the ecommerce product page
-> Whatever the selected renting period, the displayed quantity is always 2

**Cause**:
The website displays `free_qty`:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/static/src/xml/website_sale_stock_renting_product_availability.xml#L15

`free_qty` is computed in:
https://github.com/odoo-dev/odoo/blob/0935829ddaecd7b2b6eec9157f8f790b546d06ff/addons/website_sale_stock/models/product_template.py#L36

which leads to:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L10

and ultimately relies on:
https://github.com/odoo/odoo/blob/37bf1703c7478a3010b71cd60bbb43b3295a605b/addons/stock/models/product.py#L213

This computation does not take the selected renting period into account.

There is a period-aware computation here:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L15C17-L21C1

but it is only triggered when `product.allow_out_of_stock_order` is False (i.e. when "continue selling" is disabled).

opw-[5354163](https://www.odoo.com/web#id=5354163&view_type=form&model=project.task)

Forward-Port-Of: odoo/enterprise#104655
Forward-Port-Of: odoo/enterprise#103333

***Behavior:***
In a setting with a second warehouse that is supplied by the first one. Creating a product that uses that ressuply route,
and then adding it to the bom of a kit product will make it so that when ordering the kit product to the second warehouse from the MPS, the system will create an order for an exponential amount of components.

When calling action_replenish, kit products for which the components don't have an MPS entry will have their product_ratio computed to know how many components to reorder. However the current formula is wrong or outdated and ends up returning the squared amount.

***Steps to reproduce:***
- Create a second warehouse.
- Check Resuply From 'First Warehouse' (this will unarchive a route)
- Create a product that uses that route for reordering.
- Create a second product
- Create a kit for that product BOM composed of the first product make sure the amount of component is more than 1
- In the Master Production Schedule: Add the kit product and make sure it is produced in the second warehouse with the unarchived route.
- Add any amount to reorder in 'Replenishment' then click the Order button.
- If you go to deliveries and look for your component, you'll see the amount of component per kit squared multiplied by the reordered kit amount.

opw-5351460

Forward-Port-Of: odoo/enterprise#101462

Currently, an error occurs when a user tries to post an invoice using a payment method that shares the same code as another payment method.

Steps to replicate:
- Install `l10n_mx_edi` and `accountant` with demo and switch to `ZAPATERIA URTADO ÑERI` (Mexican company).
- Go to `Accounting > Configuration > Payment Way Codes (MX)`.
- Open `Efectivo` and change its code to `02`.
- Create a new Invoice, select `Efectivo` in the Payment Way.
- Add a customer and a move line, then confirm the invoice and send it (make sure CFDI is checked).

Error:
```
  File '/home/odoo/src/enterprise/19.0/l10n_mx_edi/models/account_move.py', line 424, in _l10n_mx_edi_get_extra_invoice_report_values
    cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
  File '/home/odoo/src/odoo/19.0/odoo/orm/fields.py', line 1659, in __get__
    record.ensure_one()
  File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(1, 22)
```

Cause:
- Issue originated through this [PR] that gave access to write on the model.
- As the user made the codes of two payment methods same, the [search] returned two records and while accessing `payment_method.name` on two records it results into this error.

Solution:
- Made the fields read-only via XML to prevent users from changing the payment method codes established by the Mexican government.
- Added limit to the search query to prevent multiple records. (for existing DBs that might have changed payment method codes).
- Removed unlink rights on the `l10n_mx_edi.payment.method` model.
- Added a SQL constraint to allow only unique values for the code.

[PR]: https://github.com/odoo/enterprise/pull/38046

[search]: https://github.com/odoo/enterprise/blob/18117c6a9fbf270ace1c551616828a85713d5225/l10n_mx_edi/models/account_move.py#L423

sentry-7171030995

Forward-Port-Of: odoo/enterprise#104914
Forward-Port-Of: odoo/enterprise#103944

In **l10n_ec**, negative lines are not accepted in the XML.
They must be dispatched as discounts on positive lines.
The dispatching logic implemented in `60e1b41734f76a2d9268edc41286462a9d01a501` can cause rounding issues when the decimal accuracy for `price_unit` is increased.

## Steps to reproduce

With **l10n_ec**:
1. Change the decimal accuracy to 6 digits.
2. Set the rounding method to *global rounding*.
3. Create an invoice with the following lines:

| Quantity | Price    | Taxes     |
|-----------|----------|-----------|
| 20        | 1.4235   | VAT 0% G  |
| 20        | 1.6425   | VAT 0% G  |
| 20        | 1.2337   | VAT 0% G  |
| 20        | 1.2337   | VAT 0% G  |
| 20        | 1.4235   | VAT 0% G  |
| 6         | 3.747768 | VAT 15% G |
| 6         | 3.747768 | VAT 15% G |


In the generated XML, some product lines show a `descuento` of `0.01` or `-0.01`.

This happens due to rounding differences in how the `descuento` is computed in the
`common_details_info_template` from **l10n_ec_edi**:

format_num_2(line_edi_values['price_discount'] + abs(line.balance) - line_items[1]['base_amount'])

where `line.balance` and `line_items[1]['base_amount']` can differ by 0.01 due to global rounding applied during tax aggregation, and that difference must be redistributed somewhere.

This commit changes how negative lines are dispatched onto positive ones, aligning the behavior with **l10n_mx**.
Instead of using `tax_details_per_record` to build the XML, we now use `base_lines`, where the negative lines have already been distributed.

opw-5128612

Forward-Port-Of: odoo/enterprise#97337