### Steps to reproduce:
- Install "l10n_mx_edi" and switch to a Mexican company
- In Accounting > Configuration > Taxes activate the tax "1.25 WH"
- Create an invoice with one line with a price of $50 and the tax "1.25 WH"
- Go to the customer of the invoice
- Sale & Purchase > Fiscal information and activate "No Tax Breakdown"
- Confirm the invoice and Send it to CFDI
- Traceback

### Cause:
This [commit](https://github.com/odoo/enterprise/pull/75381/commits/3f2e9437439fd6f987a13816473da2bd5a26953d) added a part in the code to prevent rounding error when specific discounts are applied which makes the base have a 5 as third digit.

When having a withholding tax and selecting "No Tax Breakdown" on the partner, the base amount will be decreased by the amount of the tax. If this amount has a 5 as third digit, a difference is detected here: `delta_discount = currency.round(sum(x['importe'] for x in line_values_list)) - cfdi_values['subtotal']` because:
- `x['importe']` is 49.375 which rounds up to 49.38
- `cfdi_values['subtotal']` is 49.37 because the tax was rounded up from 0.625 to 0.63 The code will then try to find lines with discounts but there are none so it raises an error at the `max()` function which is given nothing.

### Solution:
Adding `default=None` to `max()` so it doesn't crash.

But the rounding issue still needs to be fixed.
The fix is to select a line with more than 2 digits and to remove the difference with its rounded value. This ensures that the resulting value stay in the same 2-digit range, preventing error CFDI40167, and that the sum of "importe" is rounded down.

opw-4528766

Forward-Port-Of: odoo/enterprise#81563

There is a special case where users can make invoices "B" to foreign customers. However, we are not allowing to create credit or debit notes "B" to adjust those invoices.
This PR adds the possibility to create "B" credit and debit notes (code "6" and "7" respectively) for foreign customers.

_**Behavior before this PR:**_
An error message like the following was raised when validating the credit/debit note on AFIP:

```
Esto es lo que obtenemos: Observaciones de validación de la AFIP: 
 * Code 10015: Para facturas B (CbteDesde igual a CbteHasta) mayor o igual a $417288, DocTipo debe ser uno de los valores devueltos por el método FEParamGetTiposDoc distinto a 99 y DocNro deberá ser mayor a 0. 
 * Code 10015: Factura B (CbteDesde igual a CbteHasta), DocTipo: 80, DocNro 0 no se encuentra registrado en los padrones de AFIP y no corresponde a una cuit pais. 
```
This happened because we have to send the "CUIT país" (vat number for the foreign country) as the customer vat so the document can be validated on AFIP. For invoices, we had the logic in the code to look for the country vat and set it in the XML we send to the organism, so I just added the related documents codes so they follow the same flow.

**_Behavior after this PR:_**
The credit/debit note should be validated on AFIP.

**_Steps to reproduce the error:_**
1) Install l10n_ar_edi
2) Set a testing enviroment 
3) Create an invoice "B" to a foreign customer. This customer won't have any VAT set. 
4) Validate the invoice
5) Create a credit note from the invoice that you created before.
6) Try to validate it, and check that an error message is raised.

Forward-Port-Of: odoo/enterprise#80169

In this commit, we fix multiple indeterministic tours:

- website/static/tests/tours/media_dialog.js Add a step to ensure all images are loaded before exiting the tour to avoid message: "CORS is misconfigured on the API server, image will be treated as non-dynamic."
- project/static/tests/tours/project_task_history.js Use stepUtils.saveForm to ensure form is well saved before continue.
- website/static/tests/tours/snippets_all_drag_and_drop.js Remove a step that can cause undeterministic failure during tours.
- pos_restaurant/static/tests/tours/pos_restaurant_tour.js Add a delay when transfering the order.
- website/static/tests/tours/page_manager.js Add a last step to ensure reloading is done before exiting the tour to avoid "Error received after termination: TypeError: Failed to fetch" error.
- website/static/tests/tours/html_editor.js Add steps to wait the iframe reload.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

When viewing sale report for POS orders, the gross weight number will
be off by a factor of how much larger/smaller the UOM ratio is
compared to the base. For example, if we sell 1 qty of product with a
weight of 25kg and a UOM of 25kg (25 * 1kg), the gross weight field
will be 1 * 25kg * 25kg or 625kg instead of the expected 1 * 25kg or
25kg. This fix removes the UOM factor from being taken into account
when calculating gross weight for POS orders. This is a valid solution
because if we treat 'SUM(p.weight * l.product_uom_qty / u.factor *
u2.factor)' as the ground truth from sale report for sale orders, the
'/ u.factor * u2.factor' portion of the calculation will cancel out
to 1 for POS orders. This is because the only time 'u2.factor/u.factor'
is not 1 for sale orders is when the product template's UOM factor is
different from the sale order line's UOM factor. Since we can not
change the UOM of pos order lines, the pos order line's factor will
always be the same as the product template's therefore
'u2.factor / u.factor' for pos orders will always be 1 and can be
ignored.

To reproduce error on blank DB:
1) For a product, change its UOM to a UOM with a ratio not equal to 1
2) For the same product, change its weight in the inventory tab to
a number not equal to 0
3) In POS make a sale with this product and confirm the order
4) Check the gross weight of the product just sold through POS by
going to sales->reporting->list view and adding gross weight to the
view through studio

opw-4452892

Forward-Port-Of: odoo/odoo#203849
Forward-Port-Of: odoo/odoo#203144

Steps to reproduce:
- go to a blog post with several paragraph
- edit translations

Issue 1:
- select several paragraph completely and use the translate tool
- insert the translation
=> the translation are not inserted

Issue 2:
- select 3 paragraphs but don't start at the beginning or end of
  the text
- insert translation
- see that all translations is inserted at end of paragraph 1, paragraph
  2 is emptied and paragraph 3 selected part is removed
- save
=> paragraph 1 and 2 are deleted (so we show original lang value),
   selected part of paragraph 3 is removed

Why:

In the blog post content, we are inside a "blog.post().content"
editable field, this allows the editor to select several translations
nodes which will work wrongly with the editor because translation mode
only expect to change the content of translation nodes.

The first paragraph translation is saved empty because the editor is
cloning the node with the same "data-oe-translation-source-sha"
because we are inserting several paragraphs inside it.

Fix: in translation mode, make the editable node of html fields around
translation nodes uneditable so we can't select several translation
nodes thanks to how browser handle selection and content editable.

Note: the added test step is very light, because in javascript it is
programmatically possible to select 2 separate content editable. At the
step that is added in the tour, with the fix it is not possible to
select both the H1 and P nodes.

opw-4221993
opw-4482717

pr note: opw-4221993 could possibly solved by this fix too (the video reproduction seemed to be about a bulleted list but I could not reproduce, and the original report video is deleted)

Forward-Port-Of: odoo/odoo#203859
Forward-Port-Of: odoo/odoo#197511

[FIX] web_editor: translate paragraph links as a whole.

Steps to reproduce:

1. Enable a second language in the website (e.g., French).

2. Add a "Text" block (in edit mode) > Save the page.

3. Translate a text paragraph to french > Save.

4. In edit mode again, add a link to a word in the paragraph > Save.

5. The translation in French is lost, and sometimes the whole French
   translation is used for the text before or after the link.

This is actually a limitation in the translation implementation. If we
initially have `text_1_en text_2_en text_3_en` translated to French this
way:

terms en_US: `["text_1_en text_2_en text_3_en"]`
terms fr_BE: `["text_1_fr text_2_fr text_3_fr"]`

After adding a link: `text_1_en<a...>text_2_en</a>text_3_en`, and since
the links are not translated as a whole, we should get:

terms en_US: `["text_1_en", "text_2_en", "text_3_en"]`
terms fr_BE: `["text_1_fr text_2_fr text_3_fr"]`

Which means the current translation will be lost, and the result will
depend on the outcome of `get_close_matches()`. Which explains why when
the link is added to the first words of the paragraph, the system still
maps the rest of the paragraph to its "full old translation".

The goal of this commit is to make this behavior less aggressive by
forcing the links added in paragraphs [1] to be translated as a whole.
This way, the `get_close_matches()` will map the new content with a link
to its old translation (without a link), and then, the user can set the
link in the "the most meaningful part of the translation" in the
translate mode.

[1]: We should use the "translate as a whole" feature carefully with
links, since there are already some situations where it's causing
issues (see the fix in [2]). So we only force them inside paragraphs.

[2]: https://github.com/odoo/odoo/commit/9bd60ca93510e410a0136b8b433f596330900593

opw-3984439

Forward-Port-Of: odoo/odoo#204207
Forward-Port-Of: odoo/odoo#179167

### Description of the issue/feature this PR addresses:

There is no need to print the tax detail information when the invoice's currency is not the same as the company's currency. This change removes that part of the report, and it only affects the AR Invoice Legal report.

This functionality was added to the account module and affects all the invoice reports, but we do not want them to be in the AR legal report. For more information about the extra tax detail in the company's currency, you can check this commit https://github.com/odoo/odoo/commit/8823e01040f9522947e5d11c7312d09c50867cc4

### Current behavior before PR:

![before](https://github.com/user-attachments/assets/7d0fcb9a-1cbc-4e66-8904-98e8b2010478)

### Desired behavior after PR is merged:

![after](https://github.com/user-attachments/assets/156c8771-e87e-495a-9633-136063bab5d3)

LATAM task 1329 / Adhoc ticket 88609

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

Forward-Port-Of: odoo/odoo#201084

Currently, An error occurs when quick create an hr leave (Time Off Request).

Step to produce:

- Install the `hr_holidays` module.
- Enable debug mode.
- Open Settings / Technical / Resource / Resource Time Off, Create a new record, and attempt to quick create a 'Time Off Request'.

Traceback:

```
  File "/home/odoo/odoo/community/odoo/http.py", line 1788, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "/home/odoo/odoo/community/odoo/service/model.py", line 133, in retrying
    result = func()
  File "/home/odoo/odoo/community/odoo/http.py", line 1816, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/odoo/community/odoo/http.py", line 2020, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/odoo/community/odoo/addons/base/models/ir_http.py", line 221, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/odoo/community/odoo/http.py", line 757, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/odoo/community/addons/web/controllers/dataset.py", line 24, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "/home/odoo/odoo/community/addons/web/controllers/dataset.py", line 20, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "/home/odoo/odoo/community/odoo/api.py", line 464, in call_kw
    result = _call_kw_model(method, model, args, kwargs)
  File "/home/odoo/odoo/community/odoo/api.py", line 435, in _call_kw_model
    result = method(recs, *args, **kwargs)
  File "/home/odoo/odoo/community/odoo/models.py", line 1708, in name_create
    record = self.create({self._rec_name: name})
  File "<decorator-gen-165>", line 2, in create
  File "/home/odoo/odoo/community/odoo/api.py", line 414, in _model_create_multi
    return create(self, [arg])
  File "/home/odoo/odoo/community/addons/hr_holidays/models/hr_leave.py", line 937, in create
    if mapped_validation_type[leave_type_id] == 'no_validation':
KeyError: None

```

The error occurs because the system attempts to access 'leave_type_id'  from the `vals_list` at [1], But vals_list has no data.

Link [1]: https://github.com/odoo/odoo/blob/a1969de6e6a292b14ad1d19c256ead04dc202528/addons/hr_holidays/models/hr_leave.py#L945C17-L945C68

To resolve this issue, remove the `quick_create` option for `Time Off Request` field from the 'Resource Time Off' form view.

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

Forward-Port-Of: odoo/odoo#199163

Versions
--------
- 17.0+

Steps
-----
1. Have a rental product with a minimum rental duration of 1 day;
2. open its eCommerce page;
3. select two days in the rental period datepicker;
4. go to cart;
5. go back to the product page and refresh.

Issue
-----
The product is displayed with a rental period of 3 days.

Cause
-----
Commit 0573ad5 attempted to add a timezone correction when retrieving DateTime values from the server. When duration isn't with hours, it gets the `startOf` of the start datetime, and the `endOf` of the end datetime as a means of converting datetimes to dates.

This only works correctly if the parses datetime value was serialized with a timezone value. This was already done for the default start dates passed to `combination_info`, but not when retrieving date fields from a current sale order.

Solution
--------
Use the `_get_localized_renting_dates` method in the template to get the relevant date values with the correct timezone offset.

opw-4583312

Forward-Port-Of: odoo/enterprise#82577
Forward-Port-Of: odoo/enterprise#82353

Currently, an exception is generated when the system tries to find the 'Out of Contract'  work_entry_type after it has been deleted.

Steps to Reproduce:

1 - Install hr_payroll module without demo data
2 - Navigate to hr payroll -> configuration -> work entry types 
3 - delete the 'Out of contract' work entry type
4 - Navigate to hr payroll -> Contracts -> Contract 
5 - Create a contract with a start date next to the current.
6 - Change the contract state to 'Running'.
7 - Navigate to hr payroll -> payslips ->  To pay
8 - Try to create Payslips To Pay for created contract
9 - an error occurs

Error:
```ValueError
External ID not found in the system: hr_payroll.hr_work_entry_type_out_of_contract
```
This issue[1] occurs because when the system tries to reference the missing 'Out of Contract' work entry type it results in a ValueError due to a missing required record. The same issue [2] occurs in the `l10n_hk_hr_payroll` module.

[1] - 
https://github.com/odoo/enterprise/blob/265177dfd281f3aa1d61db6587ddfa37790570fe/hr_payroll/models/hr_payslip.py#L597

[2] -https://github.com/odoo/enterprise/blob/31e56779f8e0011ddc5c1a2821f68c8f041efbe4/l10n_hk_hr_payroll/models/hr_payslip.py#L180

This fix resolves the issue by ensuring that if the `Out of Contract` work entry type is missing, it returns a false value. A similar fix has been applied in `l10n_hk_hr_payroll`. Additionally, code has been added to prevent the deletion of any work entry type using @api.ondelete.

sentry-6277939517

Forward-Port-Of: odoo/enterprise#82523
Forward-Port-Of: odoo/enterprise#79053

## How to reproduce the issue:

- In the Gantt view of the **All Tasks** view in **Project**, create a new task with allocated hours.

- Set the task to last **at least two days** and set its **end date** between **12:00 AM and 3:00 AM** (or its **start date** between **9:00 PM and 12:00 AM**).

Instead of displaying the **task name**, the **display name** shows the **start and end times**.

This happens because if a task **spans across days** but its start/end time is within **3 hours of midnight**, the display name includes the **start and end time** in the **week and month scale view**.

Commit https://github.com/odoo/enterprise/commit/1713de228c772e43d756f068dc8b7258e3299af0 introduced a fix via `spanAccrossDays` to display the **start and end times** for tasks (shifts) where the **startDate** or **endDate** falls within **3 hours of midnight**. If `spanAccrossDays` is **false**, then the pill display name is the **start and end time** in the **week and month scale view**. However, this behavior also applied to tasks spanning more than two days.

After this commit, if the pill **spans more than two days**, the pill name will only be the **task name**:

- **Example 1:**

**Start:** *01/01/2025, 4 PM*, **End:** *02/01/2025, 1 AM* → **Display name: Start/End Time - Task name** (since the end time is before 3 AM).

- **Example 2:**

**Start:** *01/01/2025, 4 PM*, **End:** *03/01/2025* → **Display name: Task Name** (since the task spans more than two days).

opw-4474991

Forward-Port-Of: odoo/enterprise#82134
Forward-Port-Of: odoo/enterprise#78174

There is a special case where users can make invoices "B" to foreign customers. However, we are not allowing to create credit or debit notes "B" to adjust those invoices.
This PR adds the possibility to create "B" credit and debit notes (code "6" and "7" respectively) for foreign customers.

_**Behavior before this PR:**_
An error message like the following was raised when validating the credit/debit note on AFIP:

```
Esto es lo que obtenemos: Observaciones de validación de la AFIP: 
 * Code 10015: Para facturas B (CbteDesde igual a CbteHasta) mayor o igual a $417288, DocTipo debe ser uno de los valores devueltos por el método FEParamGetTiposDoc distinto a 99 y DocNro deberá ser mayor a 0. 
 * Code 10015: Factura B (CbteDesde igual a CbteHasta), DocTipo: 80, DocNro 0 no se encuentra registrado en los padrones de AFIP y no corresponde a una cuit pais. 
```
This happened because we have to send the "CUIT país" (vat number for the foreign country) as the customer vat so the document can be validated on AFIP. For invoices, we had the logic in the code to look for the country vat and set it in the XML we send to the organism, so I just added the related documents codes so they follow the same flow.

**_Behavior after this PR:_**
The credit/debit note should be validated on AFIP.

**_Steps to reproduce the error:_**
1) Install l10n_ar_edi
2) Set a testing enviroment 
3) Create an invoice "B" to a foreign customer. This customer won't have any VAT set. 
4) Validate the invoice
5) Create a credit note from the invoice that you created before.
6) Try to validate it, and check that an error message is raised.

Forward-Port-Of: odoo/enterprise#80169