Currently, an error occurs when validating stock moves without location.

Step to produce:

- Install the `mrp_subcontracting` module (make a debugger on).
- Create a product, add some quantities, and remove the value of 'Production Location' and 'Inventory Location' from it.
- Click on the 'Bills of Materials' button which is in the breadcrumbs of the product form view to create a bom of this product, And set a 'BoM Type' as Subcontracting and add an Administrator as 'Subcontractors'.
- Go to Inventory / Operations / Transfers / Receipts and create a new 'Receipts', add an Administrator as 'Receive From', and add product in 'Operations' which we created bom.
- Open a form view of 'Receive From' (res.partner) and remove value from 'Subcontractor Location' filed which is in the 'Sales & Purchase' tab.
- Again come to receipts form view and try to validate it.

`ValueError: Expected singleton: stock.location()`

This occurs because the system attempts to get 'location_id' from the stock move at [1], but it is not available.

Link [1]: https://github.com/odoo/odoo/blob/231952114ae730bb8d4671f4a61f738e8b6dd5b8/addons/stock/models/stock_move.py#L1566

To resolve this issue, add a condition to check if location_id is not available then use the company's subcontracting location as the default value.

Sentry-6156032937

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

Forward-Port-Of: odoo/odoo#191005

This commit introduces improvements to the order synchronization mechanism. The changes ensure better error handling and provide a more reliable and informative synchronization process.

Key Changes:

1. Enhance `_flush_orders` Method - The `_flush_orders` method now has additional error handling to detect RPC errors during synchronization of multiple orders. If an RPC error is detected and multiple orders are being synced, the method will attempt to send each order to the server individually.

2. Introduce `_flush_orders_retry` Method - This method sends orders to the server one by one and keeps track of the synchronization status (successful, RPC error, or other errors). - It sets the synchronization status to `'connected'`, `'error'`, or `'disconnected'` based on the outcome of individual order synchronization attempts.

3. Improve Error Handling - Enhanced error handling mechanisms to differentiate between various types of errors. - Synchronization status reflects the type of error encountered.

opw-3389388

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

Forward-Port-Of: odoo/odoo#144177
Forward-Port-Of: odoo/odoo#126662

Description of the issue/feature this PR addresses:
- In Mexico, failing to assign an appropriate account for cash basis movements can be considered illegal. Therefore, it's essential to set a default one for Mexican companies.

Current behavior before PR:
- When the 'Cash Basis' (`tax_exigibility`) setting is enabled (via Settings → Accounting → Taxes), no 'Base Tax Received Account' (`account_cash_basis_base_account_id`) is set by default for companies using the 'Mexico' fiscal localization.

Desired behavior after PR is merged:
- For companies with Mexican fiscal localization, set the default *Base Tax Received Account* to the account with code `899.01.99`. This account, already defined in the [l10n_mx data](https://github.com/odoo/odoo/blob/17.0/addons/l10n_mx/data/template/account.account-mx.csv#L47), is specified by the SAT (_Servicio de Administración Tributaria_, Mexico's primary tax authority) for miscellaneous or generic adjustments (see their [official documentation](http://omawww.sat.gob.mx/fichas_tematicas/buzon_tributario/Documents/codigo_agrupador.pdf#page=22)).

opw-[4393526](https://www.odoo.com/odoo/project.task/4393526)

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

Forward-Port-Of: odoo/odoo#190279

This PR fixes an issues about the terms & conditions overlapping the rest of the content on the `website_sale` payment page.

Prior to this PR, the terms & conditions was positioned using a `position-absolute` with a `bottom-0`, resulting in the element extending to the topside if its content is very long. This led to some overlapping issues with the others elements of the view.

To prevent this issue to happen, we position the element with a `top-100` and remove the `<div>` that aimed to handle the spacing at the bottom. We now manage this spacing with a utility class.

opw-4373853

| 17.0 | This PR |
|--------|--------|
| <img width="472" alt="image" src="https://github.com/user-attachments/assets/6b4b768f-9764-45aa-84b8-94fcab059f30" /> | <img width="461" alt="image" src="https://github.com/user-attachments/assets/5cd8548e-9b8f-4036-84dd-3f224779af27" /> | 

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

Forward-Port-Of: odoo/odoo#191346

Currently when we validate a transfer with products tracked by serial number, we may run into a bottleneck when the `quality_mrp` module is installed. That's because there's 1 move_line by Serial Number and inside `_create_assign_production_lot` those move_lines are grouped by `(company_id, product_id, lot_name)`. As we are tracking by Serial Number, each of these group key will be unique. Also, the mls are grouped in key_to_mls using `__union__` which calls `browse` to produce a recordset, effectively setting the `_prefetch_ids` of the results to `_ids`. Therefore, in the sml `write` override in quality_mrp when there's a condition on `self.sudo().check_ids`, the `_prefetch_ids` of self will only be the id in self, leading to 1 SELECT query by SML, i.e. 1 SELECT query by serial number.

This wouldn't be that much of an issue if `quality_check.move_line_id` was properly indexed but that's not the case.

So this commit first adds a missing `btree_not_null` index on `quality_check.move_line_id` to change the query plan from Seq Scan to Index Scan. Then we manually set the `_prefetch_ids` in `_create_and_assign_production_lot` to reduce the number of queries.

#### speedup

In a 17 database with 750 000 quality checks, on hot cache, adding the index makes a single query go from ~50ms to 0.250ms.

When doing a transfer of 1000 serial numbers, setting the `_prefetch_ids` reduce the number of queries from 1000 to 1. This query takes around 120ms on hot cache without the index.

Both with the index and the `_prefetch_ids`, the total time of the `_create_and_assign_production_lot` method when validating a transer of 1000 serial numbers goes from 50ms * 1000 = 50s -> 2ms * 1 = 2ms.

opw-4285293

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

Forward-Port-Of: odoo/odoo#190479

**Issue:**

When printing a Purchase Order or Quotation in a company using the Indonesian tax chart, a tax code (Indonesian tax description) appears instead of the tax percentage.

**Steps to Reproduce:**

1- Ensure the company uses the Indonesian chart of accounts.
	- Install the l10n_id module.
	- Go to Settings > Taxes and set the Fiscal Country to Indonesia. 2- Navigate to Purchase and create a Purchase Order. 3- Add a product line and select an Indonesian tax (ex: 11%). 4- Print the Purchase Order.

The printed Purchase Order displays the tax code (description) instead of the tax percentage. The same behavior occurs in the Sales module regarding quotation printing (see screenshots attached)

<img src ="https://github.com/user-attachments/assets/08dd6940-e07e-4e44-9f03-85f8ae2e8914" width=300 />
<img src ="https://github.com/user-attachments/assets/a8d16f6c-c6a0-441f-8c3f-3546387fb4e6" width=300 />

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

Forward-Port-Of: odoo/odoo#191367
Forward-Port-Of: odoo/odoo#187703