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

**Issue:**
When the currency symbol display position is set to `After Amount`, the currency sign of a negative amount (credit) in a bank journal entry overlaps with the amount.
![Capture d’écran 2024-12-12 à 15 40 19](https://github.com/user-attachments/assets/9c7f5773-9962-4d4a-8df8-de2680981c69)

**Expected:**
The `Amount` field should consistently display the currency symbol after the amount when configured as such, even for negative values.

**Steps to reproduce:**
1. Activate the Accounting app.
2. Go to `Accounting / Configuration / Accounting / Currencies`.
3. Select the company's currency and enable debug mode.
4. Set the `Display` `Symbol Position` to `After Amount` and save.
![Capture d’écran 2024-12-12 à 15 40 39](https://github.com/user-attachments/assets/bfc0b12f-8042-4408-94ea-e7c7a66da858)
5. Navigate to `Accounting / Dashboard` and open the `Bank` journal.
6. Locate an entry with a credit (negative) value.

**Cause:**
The negative sign (`-`) is correctly displayed before the input field, but it is not added to the "ghost field" used for layout alignment, causing the currency symbol to overlap with the amount.

**Fix:**
Ensure the negative sign is included before the ghost field as well, aligning the visual layout with the actual value.
![Capture d’écran 2024-12-12 à 15 39 57](https://github.com/user-attachments/assets/dce5b9ae-0f38-4ba2-b041-1a24fb549074)


opw-4348298

Forward-Port-Of: odoo/enterprise#75567

When fetching the Routing in project->task, the map view shows the error "To get routing on your map, you first need to set up your Mapbox token. -> Set up token" even if they already have the token set up.

This happens when, for example:
 if you have 3 tasks where 2 of them have the customer field
filled and one doesn't. The function _fetchRoute tried to filter out the records that don't have the latitude/longitude. But, here, since one of the records doesn't have a partner, when it's trying to look into partner.partner_latitude, it throws an error. After the error, mapBoxToken is set to '' in _partnerFetching, and called _openStreetMapAPI() resulting in displaying the error, "to get routing on your map, you first need to set up your Mapbox token."

So, adding record.partner in the filter will help filter out the records that don't have partner.

To Reproduce on Runbot:
1. Set up Mapbox token
2. Go to Project->Task
3. Create 3 Tasks ( 2 with customer and 1 without customer )
4. Go to the map view and it'll display the error.

opw-3682829

Forward-Port-Of: odoo/enterprise#73960
Forward-Port-Of: odoo/enterprise#55580

**Issue:**
The client gets an error while accessing an employee's payslips if that employee has a contract based on attendances with a null allowed value for its working schedule.

**Expected:**
The client should be able to access the payslips regardless on the working schedule value, even blank.

**Steps to reproduce:**
- Activate Payroll app and presence based on attendances in employees' settings;
- Open or create a contract through an employee's file;
- Set "Work Entry Source" to "Attendances" and leave "Working Schedule" empty;
- Try to access the employee's payslips through the action button.

**Cause:**
No timezone found on a contract's calendar because the calendar is null. [https://github.com/odoo/enterprise/blob/18.0/hr_payroll/models/hr_payslip.py#L1141](https://github.com/odoo/enterprise/blob/18.0/hr_payroll/models/hr_payslip.py#L1141
)

**Fix:**
Add a default value on `'UTC'` if no calendar has been found.

**Linked:**
Community PR :
https://github.com/odoo/odoo/pull/186222

opw-4268672

Forward-Port-Of: odoo/enterprise#73274

**Issue:**
The client gets an error while accessing an employee's payslips if that employee has a contract based on attendances with a null allowed value for its working schedule.

**Expected:**
The client should be able to access the payslips regardless on the working schedule value, even blank.

**Steps to reproduce:**
- Activate Payroll app and presence based on attendances in employees' settings;
- Open or create a contract through an employee's file;
- Set "Work Entry Source" to "Attendances" and leave "Working Schedule" empty;
- Try to access the employee's payslips through the action button.

**Cause:**
No timezone found on a contract's calendar because the calendar is null. [https://github.com/odoo/enterprise/blob/18.0/hr_payroll/models/hr_payslip.py#L1141](https://github.com/odoo/enterprise/blob/18.0/hr_payroll/models/hr_payslip.py#L1141
)

**Fix:**
Add a default value on `'UTC'` if no calendar has been found.

**Linked:**
Community PR :
https://github.com/odoo/odoo/pull/186222

opw-4268672

**Issue:**
When the currency symbol display position is set to `After Amount`, the currency sign of a negative amount (credit) in a bank journal entry overlaps with the amount.
![Capture d’écran 2024-12-12 à 15 40 19](https://github.com/user-attachments/assets/9c7f5773-9962-4d4a-8df8-de2680981c69)

**Expected:**
The `Amount` field should consistently display the currency symbol after the amount when configured as such, even for negative values.

**Steps to reproduce:**
1. Activate the Accounting app.
2. Go to `Accounting / Configuration / Accounting / Currencies`.
3. Select the company's currency and enable debug mode.
4. Set the `Display` `Symbol Position` to `After Amount` and save.
![Capture d’écran 2024-12-12 à 15 40 39](https://github.com/user-attachments/assets/bfc0b12f-8042-4408-94ea-e7c7a66da858)
5. Navigate to `Accounting / Dashboard` and open the `Bank` journal.
6. Locate an entry with a credit (negative) value.

**Cause:**
The negative sign (`-`) is correctly displayed before the input field, but it is not added to the "ghost field" used for layout alignment, causing the currency symbol to overlap with the amount.

**Fix:**
Ensure the negative sign is included before the ghost field as well, aligning the visual layout with the actual value.
![Capture d’écran 2024-12-12 à 15 39 57](https://github.com/user-attachments/assets/dce5b9ae-0f38-4ba2-b041-1a24fb549074)


opw-4348298

Forward-Port-Of: odoo/enterprise#75567

When fetching the Routing in project->task, the map view shows the error "To get routing on your map, you first need to set up your Mapbox token. -> Set up token" even if they already have the token set up.

This happens when, for example:
 if you have 3 tasks where 2 of them have the customer field
filled and one doesn't. The function _fetchRoute tried to filter out the records that don't have the latitude/longitude. But, here, since one of the records doesn't have a partner, when it's trying to look into partner.partner_latitude, it throws an error. After the error, mapBoxToken is set to '' in _partnerFetching, and called _openStreetMapAPI() resulting in displaying the error, "to get routing on your map, you first need to set up your Mapbox token."

So, adding record.partner in the filter will help filter out the records that don't have partner.

To Reproduce on Runbot:
1. Set up Mapbox token
2. Go to Project->Task
3. Create 3 Tasks ( 2 with customer and 1 without customer )
4. Go to the map view and it'll display the error.

opw-3682829

Forward-Port-Of: odoo/enterprise#73238
Forward-Port-Of: odoo/enterprise#55580

**Issue:**
Some terms don't appear in Spanish in DIAN invoice PDF files.
![image](https://github.com/user-attachments/assets/3a76f66c-9a53-473c-a5cd-68ef1e4c3980)

**Expected:**
These terms should be translated in Spanish.

**Steps to reproduce:**
- Activate Accounting app in a Colombian database;
- Configure the DIAN credentials, client, journal and product (https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/colombia.html?highlight=dian);
- Create a customer invoice;
- Send and print with (only) DIAN checkbox checked;
- Open the PDF for the invoice.

**Cause:**
No translations (or erroneous ones) have been found for these keys.

**Fix:**
Add Spanish translations for these terms.
<img width="642" alt="Capture d’écran 2024-12-09 à 11 52 44" src="https://github.com/user-attachments/assets/77f548f4-f87e-4823-9fdc-5b54d0db2a1f">
Backport of Odoo 18 fix: https://github.com/odoo/enterprise/commit/99f332e3211cf17eb7bf0a970544dd0e0e07a9f8

**Testing:**
Testing needs actual credentials and complete configuration (including setting the client's language to LATAM Spanish)
![Capture d’écran 2024-12-09 à 11 34 54](https://github.com/user-attachments/assets/3bbea0c4-2696-4fb9-88d0-38be9a8cae06)


opw-4343184

Forward-Port-Of: odoo/enterprise#75913

…ing taxes

Steps to reproduce
==================

- Create a company in Canada with the canadian fiscal localization
- Configure the avatax sandbox credentials
- Create a new fiscal position in the USA that uses the avatax API
- Create a USD pricelist
- Create a warehouse in Cleveland Ohio
- Create a salesorder with an Ohio based customer and the USD pricelist
- Select a storable product with an invoicing policy on delivered
  quantity
- Set the avatax category of the product to "Hand tools"
- Select the warehouse just created on the sales order
- Click on the "Compute taxes" button
=> The tax is set to 1%
- Confirm the sales order
=> The tax is still set to 1%
- Validate the delivery and create + confirm a new invoice
=> The tax is now 2.25%

Cause of the issue
==================

When computing the addresses to send to Avatax, the stock move addresse
was used, but at this point, they have not yet been created

Solution
========

We now use the warehouse from the sales order. This is only a
best-effort estimation of where the products will ship from. It's
possible products ship from a different warehouse than warehouse_id. For
example, you can change the default delivery route to pull from a source
location in a different warehouse. However, this is probably not a
common configuration. In the end, the only way to know for sure is to
run the inventory-related code, which we want to avoid just for tax
computation. Finally, it's also possible for users to change the
warehouse manually after the order is confirmed. This can also
potentially change taxes, and there's no way to anticipate this.

The account.move code will continue to pull the warehouse from the
stock.move, because we know it will be created before the invoice. Note
that even on account.move the shipping address remains an estimation for
products with an “invoice on ordered” invoicing policy.

opw-4073701

## Issue:
- Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax.

## Steps to reproduce:
- Create a new invoice and add a line with an 8% tax.
- Validate the invoice and export it as XML.
- Upload the XML file as a vendor bill.
- The vendor bill incorrectly shows two "8% taxes" instead of one.

## Solution:
- The issue stems from a forward-port error from `saas-16.4` https://github.com/odoo/enterprise/commit/5681a8d5abee3a8787f3ee8612a8c3b18ed63ee6 to `17.0` https://github.com/odoo/enterprise/commit/56a2b66d84d8398ea870d559cd55cfeae44019d8
- In `17.0` we introduced this Extract method  `_l10n_mx_edi_import_cfdi_get_tax_from_node` to refactor the `_l10n_mx_edi_import_cfdi_fill_invoice_line`.
- We should have add the Exento checks in the new method however we mistakenly pushed code from `saas-16.4` to `17.0` without adapting it.
- I removed the extra code introduced during the forward-porting.
- Refactored the related code to ensure compatibility with the new changes in `17.0`.

OPW-4198016