Description of the issue/feature this PR addresses:
Updating quantities in a Bill of Materials (BoM) on a draft Manufacturing Order (MO) and clicking the “Update BoM” button could trigger an error. This happens because the _link_bom function unlinks existing mrp.workorders before writing to product_qty, causing the _compute_qty_remaining compute on now-unlinked workorders to fail.

Closes #243774

Current behavior before PR:
- Editing a BoM quantity on a draft MO and pressing “Update BoM” sometimes raises an error.
- The system fails to properly update mrp.workorder quantities after unlinking existing workorders.

Desired behavior after PR is merged:
- The BoM can be updated safely on draft MOs without raising errors.
- Moves and workorders are unlinked only after the BoM is reassigned.
- `product_qty` and `product_uom_id` are safely reset, and `_compute_qty_remaining` runs correctly.
- Overall, the draft MO workflow behaves as expected, avoiding crashes when updating BoMs.

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

**Steps to reproduce:**
* Install the **l10n_ch** module for a Swiss company.
* Create a vendor bill for a **foreign vendor**.
* Apply a reverse charge tax:
  * **8.1% R C** (figure **383a**), or
  * **7.7% R C** (figure **382a**).
* Confirm the vendor bill.
* Go to **Accounting → Reporting → Tax Report**.
* Generate the VAT report for the relevant period.

**Observed behavior:**
* Figure **383a** (8.1% reverse charge) is reported as **negative**.
* Figure **382a** (7.7% reverse charge) is reported as **negative**.
* This results in incorrect VAT reporting.

**Cause:**
* Reverse charge taxes use **negative tax rates** to model the reverse mechanism.
* The base amounts were tagged with **positive** signs, leading to negative values in the report.

**Fix:**
* Invert the base tax tag signs for reverse charge taxes:
  * **382a**: change base tag from `-382a` to `+382a`.
  * **383a**: change base tag from `-383a` to `+383a`.
* Reverse charge base amounts now appear as **positive** values in the VAT report.

opw-5257445

Forward-Port-Of: odoo/odoo#244452

Steps to reproduce:
-----------------------------------
1. Install `sale_subscription` module.
2. Go to Settings and enable Pricelists
3. Create a new Subscription, set a pricelist & add a recurring plan
4. Add a non-subscription product to the order line
5. Manually set the Discount field to any non-zero value
6. Save the subscription
7. Open the Other Info tab, set the Start Date, and save again

Observation:
-----------------------------------
After saving the start date, the Discount value on the order line is reset to 0.00

Issue:
-----------------------------------
https://github.com/odoo/odoo/blob/55f34fa471316406f4ace442cb962545fa47bca1/addons/sale/models/sale_order_line.py#L771-L777
For regular products, In the discount recomputation logic, the discount is
explicitly set to 0 before checking for a pricelist. When a pricelist is present
the computation continues to the next iteration, leaving the discount already
reset

This issue only affected non-subscription products because subscription
products have their own discount computation logic in `sale_subscription`
https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/sale_subscription/models/sale_order_line.py#L80-L97
This implementation preserves discounts during temporal computations
(start_date) and doesn't rely on pricelist rules

Solution:
-----------------------------------
Reset discount to 0 only when pricelist has rules but none apply, preserving manual discounts when pricelist contains no rules at all

Related community PR: https://github.com/odoo/odoo/pull/242759

opw-5428077

Steps to reproduce:
-----------------------------------
1. Install `sale_subscription` module.
2. Go to Settings and enable Pricelists
3. Create a new Subscription, set a pricelist & add a recurring plan
4. Add a non-subscription product to the order line
5. Manually set the Discount field to any non-zero value
6. Save the subscription
7. Open the Other Info tab, set the Start Date, and save again

Observation:
-----------------------------------
After saving the start date, the Discount value on the order line is reset to 0.00

Issue:
-----------------------------------
https://github.com/odoo/odoo/blob/55f34fa471316406f4ace442cb962545fa47bca1/addons/sale/models/sale_order_line.py#L771-L777
For regular products, In the discount recomputation logic, the discount is
explicitly set to 0 before checking for a pricelist. When a pricelist is present
the computation continues to the next iteration, leaving the discount already
reset

This issue only affected non-subscription products because subscription
products have their own discount computation logic in `sale_subscription`
https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/sale_subscription/models/sale_order_line.py#L80-L97
This implementation preserves discounts during temporal computations
(start_date) and doesn't rely on pricelist rules

Solution:
-----------------------------------
Reset discount to 0 only when pricelist has rules but none apply, preserving manual discounts when pricelist contains no rules at all

Related Enterprise PR: https://github.com/odoo/enterprise/pull/103639

opw-5428077

Description of the issue/feature this PR addresses:

-The first step is to produce all but one unit from an MRP production order to enable a split. As the example images show, the first line of the "Work Orders" has both quantities completed, while the second line only has one of the two quantities completed.

<img width="1522" height="681" alt="image" src="https://github.com/user-attachments/assets/fb44e688-b851-45bb-9d86-0f5b03f9141d" />

<img width="1524" height="744" alt="image" src="https://github.com/user-attachments/assets/85ce3838-3b53-48ef-ad2f-c99308b5fb2d" />


-After performing the split, the "-002" segment should resemble what's depicted in the screenshots, with one line being canceled and the other remaining in the "Ready" status.

<img width="1529" height="805" alt="image" src="https://github.com/user-attachments/assets/a66c3414-a73b-4810-9fca-ac18c235704b" />

<img width="1532" height="856" alt="image" src="https://github.com/user-attachments/assets/46480229-0380-47f3-8552-c92f7c4282a6" />


-Now for the actual issue: once you produce everything in the second split, the line that was canceled goes back to "in process," which is incorrect. It should remain canceled because its full quantity was already completed in the first split. I've included screenshots showing how the "Work Order" lines appear after everything is produced.

<img width="1525" height="787" alt="image" src="https://github.com/user-attachments/assets/596cd97c-3f9a-4b1d-b51d-43b76fd083ce" />



My change prevents canceled or completed work orders from reverting to the “in progress” status. This is because when a change is made to the duration of a work order, the status is automatically updated. Therefore, I have added a status check to the condition to prevent this unwanted status change.


The issue occurs because a change in duration triggers a call to the "inverse" method of the "duration" field. This "inverse" method is responsible for updating the state of the "Work Orders," leading to the observed problem.

I've included both a screenshot of the code that changes the status and a link for easier access and review.

<img width="864" height="448" alt="image" src="https://github.com/user-attachments/assets/daafd66d-fe23-4d7c-a609-677c8fc29487" />

https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_workorder.py#L349

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

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

This commit https://github.com/odoo/odoo/commit/e566570e82e9 introduced a regression where the saveButtonClicked method automatically bound onSaveError as the error handler. This displays FormErrorDialog with "Oh snap!" for all save errors, causing UserErrors and ValidationErrors to show the generic "Oh snap!" message instead of the proper "Invalid Operation" dialog.

If you compare the original commit to the one here for the forward port 18.3+: https://github.com/odoo/odoo/pull/224620, you can see that the author reverted the problematic onError binding in saveButtonClicked and added forceLeave support to handle RedirectWarning redirects when the form is dirty. This PR backports those same changes to 18.0.

Steps To Reproduce:
1. Go to Time Off > Allocations > Create new allocation.
2. Set an End Date before the Start Date.
3. Click Save.
4. Error displays as "Oh snap!" instead of "Invalid Operation".
5. Switching tabs then shows the expected "Invalid Operation" dialog.

Ticket [link](https://www.odoo.com/odoo/project.task/5488127)
opw-5488127

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

**Issue**
When producing a large number of serial-tracked products, a RecursionError
can occur.

**Steps to reproduce**
- Create three products tracked by serial number (ensure MTO and Manufacture
  routes are enabled).
- Create a BoM for product A containing product B.
- Create a BoM for product B containing product C.
- Create a BoM for product C containing another product.
- Create a manufacturing order of 100 units for product A and confirm it.
- Produce the 100 units on the child MO of product C (100 backorders are created).
- On the main MO (product A), click on "Prepare MO".
- Attempt to produce product B.
→ RecursionError: maximum recursion depth exceeded.

**Cause**
While setting `move_finished_ids`:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/mrp/models/mrp_production.py#L806

the `deadline_date` of the final move is updated:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L742C1-L743C63

This deadline is then propagated to chained moves:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L539C1-L541C55
via:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L559C1-L562C61

This propagation retriggers the `move_finished_ids` setter recursively on other
moves. The recursion depth grows with the number of generated moves, eventually
exceeding Python's maximum recursion limit.

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

An error currently occurs when a user tries to confirm an account move using a document number that isn’t purely numeric and contains ASCII characters other than digits.

Steps to replicate:
- Install `l10n_cl` with demo and switch to CL company.
- Create a new invoice and add customer as `Andes Innovación SpA`.
- Add a move line > Add a product, price and tax.
- Give Document Number as `11-11`.
- Save and Confirm.

Error:
```
  File /home/odoo/odoo18/enterprise/account_accountant/models/account_move.py, line 119, in action_post
    res = super().action_post()
  File /home/odoo/odoo18/community/addons/account/models/account_move.py, line 5478, in action_post
    self._post(soft=False)
  File /home/odoo/odoo18/enterprise/l10n_cl_edi/models/account_move.py, line 161, in _post
    move._l10n_cl_create_dte()
  File /home/odoo/odoo18/enterprise/l10n_cl_edi/models/account_move.py, line 646, in _l10n_cl_create_dte
    folio = int(self.l10n_latam_document_number)
ValueError: invalid literal for int() with base 10: '11-11'
```

Cause:
- Trying to convert the document number to integer which includes some characters that are not numeric causes the error.

Solution:
- Specifically for Chile, the document number (folio) cant include anything other than numbers (Check the Sources listed below).
- Added a constraint on the field `l10n_latam_document_number` which only allows numbers using regex.

Sources:
- https://www.sii.cl/pagina/clave/folio.htm : The official Internal Revenue Service website for Chile provides information on the standard folio, along with a sample.
- https://www.sii.cl/factura_electronica/formato_dte.pdf : Refer to PG:11, Sr No:3, which specifies that the Folio should be of type NUM, meaning it must contain only numeric characters.
- The folio is created [here] that will be sent later to the authorities in the form of xml.

[here]: https://github.com/odoo/enterprise/blob/5a8bdb586e2d0bf9948a2d0b4c5e30b3849c0414/l10n_cl_edi/template/dte_template.xml#L8

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