When transferring an order to a table that already has an open order, identical products are merged into a single line. If both orders were already sent to the kitchen printer, the merged line was incorrectly marked as new and had to be sent again.

Steps to reproduce:
-------------------
* Open table 1, add product A (2 units) and product B, send to kitchen
* Open table 2, add product A (3 units) and product C, send to kitchen
* On table 2, transfer/merge the order to table 1

> Observation:
product A shows 2 units as new and must be sent to the kitchen printer again, although all quantities were already sent.

Why the fix:
------------
When merging preparation history for identical lines, handlePreparationHistory overwrote the destination sent quantity with the source one instead of summing both. The kitchen diff then treated the missing quantity as new changes.

A unit test will be added in 18.3.

opw-6246470

Forward-Port-Of: odoo/odoo#271828
Forward-Port-Of: odoo/odoo#267915

### Issue:
When creating an automatic reconciliation rule by assigning the same account to multiple bank statement lines, the rule incorrectly overrides the original payment reference of subsequent lines with the account name

This creates an inconsistent user experience
Using the "Set Account" button directly keeps the statement line payment reference as the journal item label
However, clicking the automatically generated reconciliation model button replaces that reference with the account name

Before the fix, clicking the automated rule button on a third matching line overrides its label with the account name instead of keeping its unique reference

### Cause:
In `_create_reconciliation_rule`, when an automatic model is generated, the dictionary used to create the counterpart line explicitly set `label` to `rule_data['account'].name`

When a reconciliation model line has a specific label defined, Odoo uses it to replace the statement line `payment_ref` on the generated counterpart move lines
Removing this default value allows the system to fall back on the original payment reference

### Steps to reproduce:
- Install `account_accountant`
- Go to the Bank Reconciliation widget from the Accounting Dashboard
- Create 2 statement lines without partners (e.g., Ref: "Test Ref 1" and "Test Ref 2")
- Set the same account on both lines using Set Account
- This automatically creates a Reconciliation Rule named after the account
- Create a 3rd statement line with a matching reference (e.g., "Test Ref 3")
- Click the newly available automatic reconciliation button for this line

Before the fix, checking the generated entry label shows the account name instead of "Test Ref 3"
To check unfold the details, click on the pencil icon of a line

opw-6246833

Forward-Port-Of: odoo/enterprise#119133

Problem
----------------------
When an employee takes a long sick leave (more than 30 days), the basic wage on the payslip is set to 0, leading to the holiday attest annual taxable income to be calculated as 0 * 12, which is incorrect.

Reason
-------------------
The calculation for the holiday attest uses the last payslip for the employee, and if the employee had leave type LEAVE214, the last payslip has the basic wage set to zero, so the taxable wage that is used in the annual taxable wage calculation is wrong. The monthly wage should be used as the basic wage in the payslip to get the correct computation.

Solution
-------------------
The GROSS (taxable income) line that is used is computed as (basic wage - ONSS total + BIK), but the basic wage was 0. This commit checks whether the basic wage is 0 and if the time off type was longterm sick leave, and simulates a payslip using the monthly wage from the contract as basic wage to get the accurate computation for the taxable income.

task-6237717

Forward-Port-Of: odoo/enterprise#120180

When opening Studio → Contacts → Accounting Tab, Owl raises the following error:

```py
Odoo Client Error

Occured on 114697239-saas-19-2-all.runbot254.odoo.com on 2026-06-19 07:01:00 GMT

UncaughtPromiseError > OwlError
Uncaught Promise > Invalid props for component 'BankTag': 'onDelete' is undefined (should be a value)
OwlError: Invalid props for component 'BankTag': 'onDelete' is undefined (should be a value)
    Error: Invalid props for component 'BankTag': 'onDelete' is undefined (should be a value)
        at Object.validateProps (https://114697239-saas-19-2-all.runbot254.odoo.com/web/assets/5482857/web.assets_web.min.js:1001:67)
        at FieldMany2ManyTagsBanks.slot1 (eval at compile (https://114697239-saas-19-2-all.runbot254.odoo.com/web/assets/5482857/web.assets_web.min.js:1387:421), <anonymous>:16:13)
        at callSlot (https://114697239-saas-19-2-all.runbot254.odoo.com/web/assets/5482857/web.assets_web.min.js:968:25)
        at TagsList.template (eval at compile (https://114697239-saas-19-2-all.runbot254.odoo.com/web/assets/5482857/web.assets_web.min.js:1387:421), <anonymous>:22:30)
        at Fiber._render (https://114697239-saas-19-2-all.runbot254.odoo.com/web/assets/5482857/web.assets_web.min.js:797:96)
        at Fiber.render (https://114697239-saas-19-2-all.runbot254.odoo.com/web/assets/5482857/web.assets_web.min.js:796:6)
        at ComponentNode.initiateRender (https://114697239-saas-19-2-all.runbot254.odoo.com/web/assets/5482857/web.assets_web.min.js:867:47)
```
Note: The error only occurs when the contact has at least one bank accounts (bank_ids) in the Accounting tab.

`FieldMany2ManyTagsBanks` inherits from `Many2ManyTagsField`, whose `getTagProps()` [method](https://github.com/odoo/odoo/blob/saas-19.2/addons/web/static/src/views/fields/many2many_tags/many2many_tags_field.js#L165-L173) intentionally sets `onDelete` to [undefined](https://github.com/odoo/odoo/blob/saas-19.2/addons/web/static/src/views/fields/many2many_tags/many2many_tags_field.js#L168) when the field is rendered in readonly mode.

However, `BankTag` declares `onDelete` as a required [prop](https://github.com/odoo/odoo/blob/saas-19.2/addons/account/static/src/components/many2many_tags_banks/many2many_tags_banks.js#L18). Since Studio renders the field as readonly, `onDelete` is undefined, causing Owl prop validation to fail.

Make `onDelete` optional in `BankTag` to match the behavior of the parent widget and the underlying `BadgeTag` component, which already defines `onDelete` as [optional](https://github.com/odoo/odoo/blob/saas-19.2/addons/web/static/src/core/tags_list/badge_tag.js#L12).

This fixes the Owl error when opening the Accounting tab in Studio.

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

Forward-Port-Of: odoo/odoo#271019

Description of the issue/feature this PR addresses:

`Registry.check_indexes` derives a column index's name as `<table>__<column>_index`, which does **not** encode the access method, and only creates the index when no index of that name already exists. It never inspects the access method of an existing index.

As a consequence, changing a field's `index=` kind on an **already-indexed** column is silently ignored on existing databases. For example `account.move.name` was changed from a plain btree index to `index='trigram'`:

```python
name = fields.Char(
    ...
    index='trigram',
)
```
On a fresh database this creates the expected GIN/trigram index. On any database that already had the btree index, the old btree index keeps its name, so `check_indexes` finds the name present and does nothing. The `(=)ilike` searches the trigram index was meant to accelerate keep falling back to sequential scans, with no error or warning.

Current behavior before PR:

### Steps to reproduce

1. Install a module on an existing DB while a `Char` field is `index=True` (btree).
2. Change the field to `index='trigram'` and upgrade the module.
3. `\d <table>` in psql — the index is still `USING btree`, not `USING gin`.

Desired behavior after PR is merged:

`check_indexes` now also reads each existing index's access method (`pg_am.amname`). When the method no longer matches what the field expects (`gin` for trigram, `btree` otherwise), the stale index is dropped and recreated. The drop is issued inside the **same savepoint** as the recreate, so a failed rebuild (e.g. a lock timeout) rolls the drop back and never leaves the column without an index.

Scope: only the access method is reconciled. A change that alters solely the partial predicate (`btree` -> `btree_not_null`) keeps the same method and is intentionally left untouched.

### Notes

- This extends the existing index-management logic in place and keeps the current "keep unexpected index" behaviour for fields that dropped `index=` entirely; only fields that still want an index, of a different method, are rebuilt.
- Trigram rebuilds still require the `pg_trgm` extension; without it the GIN index is skipped exactly as before (`self.has_trigram` guard).


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

Forward-Port-Of: odoo/odoo#272198
Forward-Port-Of: odoo/odoo#268505

Step to reproduce:
- install l10n_co_dian and pos
- open pos and click on create a new partner from partner list
- enter name ex. "temp", identification number, click on form
- notice a `refresh icon` is visible: click on it.

Observation:
- the dialog is closed and partner is selected with "temp" name

Expected:
- with valid government credentials and a valid identification number,
the refresh action should also update the partner data on the POS side

Cause:
- the refresh button triggers the `button_l10n_co_dian_refresh_data` action,
which fetches the legal name and email from the government service
- although the backend record is correctly updated, the new values are not
immediately synchronized with the POS
- when the refresh button is clicked, editPartner() first triggers
`web_save` using the temporary "temp" name and immediately reads the
partner data afterward
- the refresh action executes later and updates the contact with the fetched
legal information, but the POS is not aware of these subsequent changes

Fix:
- read the data again if there is any update caused by this action.
- this is done by overriding `afterExecuteActionButton` of FormController class

opw-6198035

Forward-Port-Of: odoo/enterprise#117527

Steps to Reproduce:

* Create a database before saas~19.3.
* Install to l10n_do and company configured
* Upgrade the database to saas~19.3.
* Check the Dominican Republic chart of accounts, taxes, and tax groups.

Issue:

* The localization updates introduced in saas~19.3 are not loaded during the upgrade.
* As a result, some Dominican Republic accounts, taxes, and tax groups are missing after the upgrade.

Cause:

* New localization data was introduced for `l10n_do`, but the chart template is not reloaded during the upgrade.
* Consequently, the newly introduced records are never created on upgraded databases.

Related:
https://github.com/odoo/odoo/pull/257233

Fix:

* Reload the Dominican Republic chart template during the upgrade using `account.chart.template.try_loading('do', company)` to ensure all newly
 introduced accounts, taxes, and tax groups are created.

opw-6274580
upg-4333738

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

Steps to reproduce
------------------
Serial-tracked finished product:
1. Create a serial-tracked finished product and an un-tracked component.
2. Create a Manufacturing Order with quantity 2 and confirm it.
3. Open the Barcode app, scan the MO, then scan a first serial number SN_X1.
4. Scan a second serial number SN_X2.
5. Validate.

Lot-tracked finished product:
1. Create a lot-tracked finished product with a one-component BoM and an existing lot LOT_A.
2. Create a Manufacturing Order and confirm it.
3. Open the Barcode app, scan the MO, then scan the existing lot LOT_A.
4. Scan a different, not-yet-existing lot LOT_B.
5. Validate.

Issue
-----
Only the last scanned serial is registered on the MO, and validation then fails because the count of producing serials does not match qty_producing for a serial-tracked finished product.

updateLine overwrote lot_producing_ids with [args.lot_id] on every scan, so the first serial was dropped when the second one was scanned, and the same branch never staged a freshly typed
lot_name, so a brand-new serial typed on a serial-tracked MO was lost before reaching the backend.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L407

Two behaviours of the shared barcode dispatcher make a single accumulating branch insufficient.

The final-product line must keep exposing a producing lot, otherwise the base hasUnassignedQty check counts a scanned serial as zero once a quantity is already set, leaving qty_producing stuck below the demand.

https://github.com/odoo/enterprise/blob/f622064871bf55b93890606d16407c50cf4419a6/stock_barcode/static/src/models/barcode_model.js#L1446

But exposing a producing lot makes the dispatcher treat the next serial as a conflicting tracking number, since the base _canOverrideTrackingNumber considers a different lot name non-overridable.

https://github.com/odoo/enterprise/blob/f622064871bf55b93890606d16407c50cf4419a6/stock_barcode/static/src/models/barcode_model.js#L796-L798

So the scan is diverted to a new line through the override gate instead of updating the header line.

https://github.com/odoo/enterprise/blob/f622064871bf55b93890606d16407c50cf4419a6/stock_barcode/static/src/models/barcode_model.js#L1585

For a lot-tracked finished product the producing lot can be corrected by scanning a different value, but the lot branch only stored a freshly typed value in lot_name and overwrote lot_producing_ids with the single existing lot.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L404-L407

The header reads its lot from lot_producing_ids whenever that relation is set and only falls back to lot_name when it is empty.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/components/header.js#L45-L58

The save path only promotes lot_name to a producing lot when lot_producing_ids is empty, so scanning an existing lot then a new one neither displayed nor recorded the new lot and the finished product was produced under the old lot.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L628

Solution
--------
Accumulate scanned serials by appending to lot_producing_ids instead of replacing it, and stage a freshly typed lot_name as a new producing lot when the finished product is tracked by serial, so every serial reaches the backend.

Keep the final-product line exposing the last producing lot so each scanned serial is still counted as one unit instead of resetting the quantity to zero once several serials are registered.

Override _canOverrideTrackingNumber for the final-product line so a serial scan updates the header line rather than being diverted to a new line, which is the only valid path for the finished product since it is a single header line backed by the lot_producing_ids relation.

Persist the producing serials with explicit x2many commands, separating already-existing lots from freshly typed ones, so both are written on the MO.

Reject a serial that is already registered on the MO so the same number cannot be produced twice in one session.

For a lot-tracked finished product, build a producing lot from the scanned value, using the existing lot or a freshly typed lot name, and store it in lot_producing_ids so the new lot is both displayed and persisted through the same x2many commands as the serial case.

Leave the produced quantity unchanged when the scanned lot differs from the one already registered, since replacing the lot is a correction and not an extra unit, and keep incrementing it when the same lot is scanned again.

opw-6189620

Forward-Port-Of: odoo/enterprise#116890

When a stock move's UoM differs from the product template's UoM, the report aggregation incorrectly shows data for both UoMs of stock move.quantity on the same graph. All moves should be normalized to the UoM of the product for which we are viewing the forecast.

We can do this with:

`m.quantity * move_uom.factor / pt_uom.factor AS quantity`

If the UoMs of the stock move and the product template are identical, as is the case most of the time, this simply multiplies by one, and the query behaves exactly as it did before. But if the units are distinct, the move UoM is converted into
the product template UoM so that the data for stock move quantity is normalized to one shared unit across the entire forecast graph.

**E.g.**:

m.quantity == 500g
m.UoM == g
m.UoM.factor == 1
pt.UoM == kg
pt.UoM.factor == 1000

500g * 1 / 1000 ==> .5kg

**Steps to Reproduce on Runbot**:
1. Create a product which uses kg and g. 
2. Confirm and Validate a receipt for this product (10 kg for example). 
3. Confirm a second receipt for this product in the same UoM kg. 
4. Confirm and Validate a delivery for this product with UoM g (500 g for example).
5. View the forecasted graph for the product, and you will see that the y axis is scaled on grams ~500, and the current / future stock moves in the report are still scaled based on kg. 

opw-6234066

Forward-Port-Of: odoo/odoo#266811

### Issue:
When creating an automatic reconciliation rule by assigning the same account to multiple bank statement lines, the rule incorrectly overrides the original payment reference of subsequent lines with the account name

This creates an inconsistent user experience
Using the "Set Account" button directly keeps the statement line payment reference as the journal item label
However, clicking the automatically generated reconciliation model button replaces that reference with the account name

Before the fix, clicking the automated rule button on a third matching line overrides its label with the account name instead of keeping its unique reference

### Cause:
In `_create_reconciliation_rule`, when an automatic model is generated, the dictionary used to create the counterpart line explicitly set `label` to `rule_data['account'].name`

When a reconciliation model line has a specific label defined, Odoo uses it to replace the statement line `payment_ref` on the generated counterpart move lines
Removing this default value allows the system to fall back on the original payment reference

### Steps to reproduce:
- Install `account_accountant`
- Go to the Bank Reconciliation widget from the Accounting Dashboard
- Create 2 statement lines without partners (e.g., Ref: "Test Ref 1" and "Test Ref 2")
- Set the same account on both lines using Set Account
- This automatically creates a Reconciliation Rule named after the account
- Create a 3rd statement line with a matching reference (e.g., "Test Ref 3")
- Click the newly available automatic reconciliation button for this line

Before the fix, checking the generated entry label shows the account name instead of "Test Ref 3"
To check unfold the details, click on the pencil icon of a line

opw-6246833

Forward-Port-Of: odoo/enterprise#119133

Currently, when printing a request for quotation the incoterm informations are not present.

Steps to reproduce:
-------------------
* Create a new quotation
* Add basic required information
* Open tab "Other info" and fill incoterm field(s)
* Save (don't confirm)
* Print RFQ pdf report
> Observation: The incoterm values are not being printed

Why the fix:
------------
If we look at the html version of that report we can see those information are present before the logo section.

This issue was introduced by the following commit: https://github.com/odoo/odoo/commit/bba2fc505f5d0b4770eacc6877155b1aeda6d772

As we can see the incoterm informations are positioned after the `layout_document_title`
https://github.com/odoo/odoo/blob/a7de246efa8241c49196be0e0477abd086bf9e63/addons/purchase_stock/report/purchase_report_templates.xml#L44-L55

After the mentioned commit the `layout_document_title` is defined before the external layout. So when the report is rendered the incoterm bloc is positioned before the external layout as well which explains why it can be seen in the html and not the pdf.

This fix changes the xpath to make it corresponds to the same placement as it was prior to the issue. The class `page` was chosen in this case as the `layout_document_title` block was before the page class as well and all the blocks that were in between `layout_document_title` and `page` previously are now also before the external layout.


HTML:
<img width="1718" height="867" alt="image" src="https://github.com/user-attachments/assets/0b2a04ec-5f0e-4915-8e57-e511a1cd2d8c" />

PDF:
<img width="1677" height="870" alt="image" src="https://github.com/user-attachments/assets/06e94ea4-6ce6-48ed-85db-c672137877c2" />

After fix:
<img width="1917" height="1002" alt="image" src="https://github.com/user-attachments/assets/158e66a1-83ea-4122-8daa-f90e9aa537d5" />



opw-6211465

[FIX] point_of_sale, pos_viva_com: automatic receipt printing
3 Fixes for the app-to-app integration of Viva

1. Under the normal flow the `OrderPaymentValidation` does the payment
   validation and post validation operations (such as receipt printing or
   preparation prints). Then it launches the `FeedbackScreen` with the
   validation promise on the `waitFor` prop.

   The `pos_viva_com` app-2-app integration does the payment validation on
   the backend on the callback endpoint. Then it redirects the user
   directly on the `FeedbackScreen` skipping the normal validation and post
   validation operations. This means that receipts and preparation prints
   do not get processed.

   This PR adds a check on the `FeedbackScreen` to see whether there is
   anything set on the `waitFor` prop. If the prop is undefined, we can
   expect that the screen was mounted outside the normal flow, so we run
   the post validation operations manually.

---

2. Using the fast payment method with Viva would use
   `order.addPaymentLine` instead of the overloaded
   `payment_screen.addNewPaymentLine`. So the integration pop up which
   is defined in the `payment_screen` would never fire.

   Now I've added a check on `validateOrder` to detect whether we're about
   to use a `fastPaymentMethod`, in which case it will apply the same
   behaviour as the override of the `payment_screen.addNewPaymentLine`

---

3. Added a patch for `reloadData` which will remove the answer for the
   Viva wallet pop up from local storage in case users change their minds
   or made a mistake

Task-[6251297](https://www.odoo.com/odoo/project/1737/tasks/6251297)

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

When transferring an order to a table that already has an open order, identical products are merged into a single line. If both orders were already sent to the kitchen printer, the merged line was incorrectly marked as new and had to be sent again.

Steps to reproduce:
-------------------
* Open table 1, add product A (2 units) and product B, send to kitchen
* Open table 2, add product A (3 units) and product C, send to kitchen
* On table 2, transfer/merge the order to table 1

> Observation:
product A shows 2 units as new and must be sent to the kitchen printer again, although all quantities were already sent.

Why the fix:
------------
When merging preparation history for identical lines, handlePreparationHistory overwrote the destination sent quantity with the source one instead of summing both. The kitchen diff then treated the missing quantity as new changes.

A unit test will be added in 18.3.

opw-6246470

Forward-Port-Of: odoo/odoo#271828
Forward-Port-Of: odoo/odoo#267915

Description of the issue/feature this PR addresses:

`Registry.check_indexes` derives a column index's name as `<table>__<column>_index`, which does **not** encode the access method, and only creates the index when no index of that name already exists. It never inspects the access method of an existing index.

As a consequence, changing a field's `index=` kind on an **already-indexed** column is silently ignored on existing databases. For example `account.move.name` was changed from a plain btree index to `index='trigram'`:

```python
name = fields.Char(
    ...
    index='trigram',
)
```
On a fresh database this creates the expected GIN/trigram index. On any database that already had the btree index, the old btree index keeps its name, so `check_indexes` finds the name present and does nothing. The `(=)ilike` searches the trigram index was meant to accelerate keep falling back to sequential scans, with no error or warning.

Current behavior before PR:

### Steps to reproduce

1. Install a module on an existing DB while a `Char` field is `index=True` (btree).
2. Change the field to `index='trigram'` and upgrade the module.
3. `\d <table>` in psql — the index is still `USING btree`, not `USING gin`.

Desired behavior after PR is merged:

`check_indexes` now also reads each existing index's access method (`pg_am.amname`). When the method no longer matches what the field expects (`gin` for trigram, `btree` otherwise), the stale index is dropped and recreated. The drop is issued inside the **same savepoint** as the recreate, so a failed rebuild (e.g. a lock timeout) rolls the drop back and never leaves the column without an index.

Scope: only the access method is reconciled. A change that alters solely the partial predicate (`btree` -> `btree_not_null`) keeps the same method and is intentionally left untouched.

### Notes

- This extends the existing index-management logic in place and keeps the current "keep unexpected index" behaviour for fields that dropped `index=` entirely; only fields that still want an index, of a different method, are rebuilt.
- Trigram rebuilds still require the `pg_trgm` extension; without it the GIN index is skipped exactly as before (`self.has_trigram` guard).


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

Forward-Port-Of: odoo/odoo#272198
Forward-Port-Of: odoo/odoo#268505

Problem
----------------------
When an employee takes a long sick leave (more than 30 days), the basic wage on the payslip is set to 0, leading to the holiday attest annual taxable income to be calculated as 0 * 12, which is incorrect.

Reason
-------------------
The calculation for the holiday attest uses the last payslip for the employee, and if the employee had leave type LEAVE214, the last payslip has the basic wage set to zero, so the taxable wage that is used in the annual taxable wage calculation is wrong. The monthly wage should be used as the basic wage in the payslip to get the correct computation.

Solution
-------------------
The GROSS (taxable income) line that is used is computed as (basic wage - ONSS total + BIK), but the basic wage was 0. This commit checks whether the basic wage is 0 and if the time off type was longterm sick leave, and simulates a payslip using the monthly wage from the contract as basic wage to get the accurate computation for the taxable income.

task-6237717

Steps to reproduce
------------------
Serial-tracked finished product:
1. Create a serial-tracked finished product and an un-tracked component.
2. Create a Manufacturing Order with quantity 2 and confirm it.
3. Open the Barcode app, scan the MO, then scan a first serial number SN_X1.
4. Scan a second serial number SN_X2.
5. Validate.

Lot-tracked finished product:
1. Create a lot-tracked finished product with a one-component BoM and an existing lot LOT_A.
2. Create a Manufacturing Order and confirm it.
3. Open the Barcode app, scan the MO, then scan the existing lot LOT_A.
4. Scan a different, not-yet-existing lot LOT_B.
5. Validate.

Issue
-----
Only the last scanned serial is registered on the MO, and validation then fails because the count of producing serials does not match qty_producing for a serial-tracked finished product.

updateLine overwrote lot_producing_ids with [args.lot_id] on every scan, so the first serial was dropped when the second one was scanned, and the same branch never staged a freshly typed
lot_name, so a brand-new serial typed on a serial-tracked MO was lost before reaching the backend.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L407

Two behaviours of the shared barcode dispatcher make a single accumulating branch insufficient.

The final-product line must keep exposing a producing lot, otherwise the base hasUnassignedQty check counts a scanned serial as zero once a quantity is already set, leaving qty_producing stuck below the demand.

https://github.com/odoo/enterprise/blob/f622064871bf55b93890606d16407c50cf4419a6/stock_barcode/static/src/models/barcode_model.js#L1446

But exposing a producing lot makes the dispatcher treat the next serial as a conflicting tracking number, since the base _canOverrideTrackingNumber considers a different lot name non-overridable.

https://github.com/odoo/enterprise/blob/f622064871bf55b93890606d16407c50cf4419a6/stock_barcode/static/src/models/barcode_model.js#L796-L798

So the scan is diverted to a new line through the override gate instead of updating the header line.

https://github.com/odoo/enterprise/blob/f622064871bf55b93890606d16407c50cf4419a6/stock_barcode/static/src/models/barcode_model.js#L1585

For a lot-tracked finished product the producing lot can be corrected by scanning a different value, but the lot branch only stored a freshly typed value in lot_name and overwrote lot_producing_ids with the single existing lot.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L404-L407

The header reads its lot from lot_producing_ids whenever that relation is set and only falls back to lot_name when it is empty.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/components/header.js#L45-L58

The save path only promotes lot_name to a producing lot when lot_producing_ids is empty, so scanning an existing lot then a new one neither displayed nor recorded the new lot and the finished product was produced under the old lot.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L628

Solution
--------
Accumulate scanned serials by appending to lot_producing_ids instead of replacing it, and stage a freshly typed lot_name as a new producing lot when the finished product is tracked by serial, so every serial reaches the backend.

Keep the final-product line exposing the last producing lot so each scanned serial is still counted as one unit instead of resetting the quantity to zero once several serials are registered.

Override _canOverrideTrackingNumber for the final-product line so a serial scan updates the header line rather than being diverted to a new line, which is the only valid path for the finished product since it is a single header line backed by the lot_producing_ids relation.

Persist the producing serials with explicit x2many commands, separating already-existing lots from freshly typed ones, so both are written on the MO.

Reject a serial that is already registered on the MO so the same number cannot be produced twice in one session.

For a lot-tracked finished product, build a producing lot from the scanned value, using the existing lot or a freshly typed lot name, and store it in lot_producing_ids so the new lot is both displayed and persisted through the same x2many commands as the serial case.

Leave the produced quantity unchanged when the scanned lot differs from the one already registered, since replacing the lot is a correction and not an extra unit, and keep incrementing it when the same lot is scanned again.

opw-6189620

Forward-Port-Of: odoo/enterprise#116890

Overview
------

When having a favorite mailing (template) for target model X, and another one for target model Y, and try to create a new mailing for target model X, the theme selector will first show the template X with the correct title and preview, however when switching to model Y, the theme selector will show the title of the tempalte Y but the preview is always the one of template X.

How to reproduce
------

1. Create a new mailing for a target model X (e.g. `mailing.contact`)
2. Set a content for that mailing (you can choose from the existing themes)
3. Set that mailing as a favorite (using the favorite star button)
4. Create a new mailing for another target model Y.
5. Redo steps 2. and 3.
6. Create a new mailing, and set the target model to X (You should see the mailing X in the theme selector with the correct title and preview)
7. Change the target model to Y.

Expected Behavior
------

Both the title and the preview of the mailing X in the theme selector should change into the title and the preivew of mailing Y.

Current Behavior
------

The title of the template is changed into the one of Y however the preview remains the one of mailing X.

Cause of The Issue
------

After the first mount of the `FavoritePreivew` component, when the template changes in the props, the body content of the preivew is not updated with the new value.

Task-6332946



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

Forward-Port-Of: odoo/odoo#272065

*: website, website_mass_mailing

__Problem__
In some cases, popup snippets can be dropped inside another popup.
This shouldn't be possible. Moreover, it produces the following error:
`TypeError: Cannot read properties of undefined (reading 'after')`.

This can happen in multiple scenarios:
- After saving a custom snippet, the snippets are reloaded but
  `disableUndroppableSnippets` is not called again, although the
  snippets should be filtered again.
- `NewsletterPopupPlugin` registers `.o_newsletter_popup` in the
  `so_snippet_addition_selector` resource, bypassing the more
  restrictive `dropzone_selector` of `PopupOptionPlugin`.
- Popups are not disabled when the cookie bar is open because we don't
  take `excludeAncestor` into account in `DisableSnippetsPlugin`.

__Fix__
- Trigger an event whenever the snippets are loaded and call
  `disableUndroppableSnippets` when it is.
- Remove the redundant `NewsletterPopupPlugin`.
- Filter `dropAreaEls` with `excludeAncestor` in `DisableSnippetsPlugin`.

Forward-Port-Of: odoo/odoo#271635
Forward-Port-Of: odoo/odoo#269864

Issue:
When work entries are generated from Attendances, a worked-time time off created by the Indian sandwich rule can overlap a public holiday and generate duplicate work entries for the same day.

Steps to reproduce:
- Create an employee with Work Entry Source set to Attendances
- Use a flexible working schedule on the employee
- Configure a public holiday on a scheduled day with work entry type (Paid time off)
- Create a time off type with Count as set to Worked Time
- Generate time off for the period so the public holiday entry exists (maybe a day before and a the public holiday and the day after)
- Open Payroll > Work Entries (Observe the date of the public holiday will have more than 8h entry)

Cause:
In `_get_version_work_entries_values()`, calendar leaves are split by `hr_holidays` `time_type` into:
- leaves: absences and public holidays
- worked_leaves: worked-time time off For attendance-based contracts, both sets were turned into work entries without removing overlap between a public holiday and a worked-time leave on the same period. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L222-L226

For non-flexible calendar:
Public holidays and worked-time leaves are both clipped to the static working schedule (e.g. 8h per working day). overlap was kept in both result sets. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L260

For flexible calendar:
The one-day intervals are kept as the actual interval (often 00:00-23:59 for a public holiday). The worked-time on that day is schedule-shaped (e.g. 8h). Subtracting intervals on a full-day public holiday left a 16h fragment instead of removing the public holiday entry. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L242-L249

Solution:
We need to make regular leaves take priority over worked-time leaves, compute the real regular leave intervals first, then remove those intervals from the worked-time leave intervals before work entries are created:
- for fully flexible employees, subtract regular leaves from worked leaves;
- for flexible calendars, keep one-day regular leaves as is and subtract them from worked-time leaves
- for non-flexible attendance-based calendars, clip regular leaves on the static schedule, then subtract them from worked-time leaves clipped on the same schedule.
  
This means that when a sandwich worked-time leave overlaps a public holiday, the public holiday consumes that period first. The overlapping part is then removed from `real_worked_leaves`, so no second worked-time entry is generated for the same public holiday period.

opw-6237163

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

Forward-Port-Of: odoo/odoo#269615
Forward-Port-Of: odoo/odoo#268527

Issue:
When work entries are generated from Attendances, a worked-time time off created by the Indian sandwich rule can overlap a public holiday and generate duplicate work entries for the same day.

Steps to reproduce:
- Create an employee with Work Entry Source set to Attendances
- Use a flexible working schedule on the employee
- Configure a public holiday on a scheduled day with work entry type (Paid time off)
- Create a time off type with Count as set to Worked Time
- Generate time off for the period so the public holiday entry exists (maybe a day before and a the public holiday and the day after)
- Open Payroll > Work Entries (Observe the date of the public holiday will have more than 8h entry)

Cause:
In `_get_version_work_entries_values()`, calendar leaves are split by `hr_holidays` `time_type` into:
- leaves: absences and public holidays
- worked_leaves: worked-time time off For attendance-based contracts, both sets were turned into work entries without removing overlap between a public holiday and a worked-time leave on the same period. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L222-L226

For non-flexible calendar:
Public holidays and worked-time leaves are both clipped to the static working schedule (e.g. 8h per working day). overlap was kept in both result sets. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L260

For flexible calendar:
The one-day intervals are kept as the actual interval (often 00:00-23:59 for a public holiday). The worked-time on that day is schedule-shaped (e.g. 8h). Subtracting intervals on a full-day public holiday left a 16h fragment instead of removing the public holiday entry. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L242-L249

Solution:
We need to make regular leaves take priority over worked-time leaves, compute the real regular leave intervals first, then remove those intervals from the worked-time leave intervals before work entries are created:
- for fully flexible employees, subtract regular leaves from worked leaves;
- for flexible calendars, keep one-day regular leaves as is and subtract them from worked-time leaves
- for non-flexible attendance-based calendars, clip regular leaves on the static schedule, then subtract them from worked-time leaves clipped on the same schedule.
  
This means that when a sandwich worked-time leave overlaps a public holiday, the public holiday consumes that period first. The overlapping part is then removed from `real_worked_leaves`, so no second worked-time entry is generated for the same public holiday period.

opw-6237163

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

Forward-Port-Of: odoo/enterprise#120300
Forward-Port-Of: odoo/enterprise#119530

## Issue
In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
    - Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__

## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157

We obtain the following values:

```js
> monday = section.cells[1]

> monday.value
8.333333333333336

> workingHours[monday.column.value]
8.333333333333332

> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```

This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172

## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.

opw-6193181

Forward-Port-Of: odoo/enterprise#121463

Steps to reproduce
------------------
1. Set a default tax on the "Cash Difference Gain" account (e.g. a 25%
   sales tax) -- required in some countries like Denmark (cf 5972690).
2. Open a PoS session, count more cash than expected at closing.
3. Try to close the session.

-> Error message shows up "The journal entry reached an invalid
state..." ... "The journal entry must always have exactly one journal
item involving the bank/cash account"

What's happening
----------------
PoS creates a bank statement line with the gain account as counterpart,
resulting in 2 lines: cash +10, gain -10. Since the gain account has a
default tax, `_sync_tax_lines` adds a tax line of -2.5 on top, which
makes the move unbalanced by 2.5. Then `_sync_unbalanced_lines` adds a
4th line to fix it, on the line returned by
`_get_automatic_balancing_account`, which is `journal.default_account_id`,
i.e. the cash account itself for a cash journal.

So we end up with 2 lines on that same cash account, which a bank
statement line move doesn't allow -> Error.

The fix
-------
In `_post_statement_difference`, precompute the base and tax split
ourselves and build the statement line's `line_ids` directly (e.g. for
+10 and a 25% tax: cash +10, gain -8, tax -2). The move is balanced
from creation, so `_sync_tax_lines` and `_sync_unbalanced_lines` don't
have to touch it.

Note that we force the tax computation to be in 'force_price_include'
mode, as the counted cash difference is a gross amount (physical money
in the drawer). This way the tax is always extracted from the cash
amount, regardless of how the tax is configured (included or excluded
in price). Same pattern is already used by `hr_expense` (cf
`hr_expense.models.account_move_line._compute_totals`).

opw-5972690

Forward-Port-Of: odoo/odoo#271921
Forward-Port-Of: odoo/odoo#257892

A tax created without a fiscal position (empty fiscal_position_ids) is conceptually an "All" tax: it should apply across every fiscal position, including the empty ones used for tax units.

Problem

map_tax drops every tax when the FP has no mapping, including the "All" ones that should pass through.
action_open_related_taxes only lists the FP's tax_ids, so "All" taxes are invisible from the FP form.
The Taxes stat button is hidden whenever the FP has no tax_ids.
action_update_fpos_values invokes the field computes directly, so tax and balance lines fall out of sync after an FP change.

Fix

map_tax: when the FP has no tax_ids, return the input taxes whose fiscal_position_ids is empty (the "All" ones) instead of an empty recordset.
action_open_related_taxes: extend the domain to also include taxes bound to no fiscal position.
partner_view: drop the invisible="not tax_ids" guard on the Taxes stat button.
action_update_fpos_values: route the deferred computes through _check_balanced and _sync_dynamic_lines so tax lines stay in sync after the update.

task-id [6231514](https://www.odoo.com/odoo/project/967/tasks/6231514)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#268273

### Issue:
When creating an automatic reconciliation rule by assigning the same account to multiple bank statement lines, the rule incorrectly overrides the original payment reference of subsequent lines with the account name

This creates an inconsistent user experience
Using the "Set Account" button directly keeps the statement line payment reference as the journal item label
However, clicking the automatically generated reconciliation model button replaces that reference with the account name

Before the fix, clicking the automated rule button on a third matching line overrides its label with the account name instead of keeping its unique reference

### Cause:
In `_create_reconciliation_rule`, when an automatic model is generated, the dictionary used to create the counterpart line explicitly set `label` to `rule_data['account'].name`

When a reconciliation model line has a specific label defined, Odoo uses it to replace the statement line `payment_ref` on the generated counterpart move lines
Removing this default value allows the system to fall back on the original payment reference

### Steps to reproduce:
- Install `account_accountant`
- Go to the Bank Reconciliation widget from the Accounting Dashboard
- Create 2 statement lines without partners (e.g., Ref: "Test Ref 1" and "Test Ref 2")
- Set the same account on both lines using Set Account
- This automatically creates a Reconciliation Rule named after the account
- Create a 3rd statement line with a matching reference (e.g., "Test Ref 3")
- Click the newly available automatic reconciliation button for this line

Before the fix, checking the generated entry label shows the account name instead of "Test Ref 3"
To check unfold the details, click on the pencil icon of a line

opw-6246833

Forward-Port-Of: odoo/enterprise#119133

Steps to reproduce
------------------
Serial-tracked finished product:
1. Create a serial-tracked finished product and an un-tracked component.
2. Create a Manufacturing Order with quantity 2 and confirm it.
3. Open the Barcode app, scan the MO, then scan a first serial number SN_X1.
4. Scan a second serial number SN_X2.
5. Validate.

Lot-tracked finished product:
1. Create a lot-tracked finished product with a one-component BoM and an existing lot LOT_A.
2. Create a Manufacturing Order and confirm it.
3. Open the Barcode app, scan the MO, then scan the existing lot LOT_A.
4. Scan a different, not-yet-existing lot LOT_B.
5. Validate.

Issue
-----
Only the last scanned serial is registered on the MO, and validation then fails because the count of producing serials does not match qty_producing for a serial-tracked finished product.

updateLine overwrote lot_producing_ids with [args.lot_id] on every scan, so the first serial was dropped when the second one was scanned, and the same branch never staged a freshly typed
lot_name, so a brand-new serial typed on a serial-tracked MO was lost before reaching the backend.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L407

Two behaviours of the shared barcode dispatcher make a single accumulating branch insufficient.

The final-product line must keep exposing a producing lot, otherwise the base hasUnassignedQty check counts a scanned serial as zero once a quantity is already set, leaving qty_producing stuck below the demand.

https://github.com/odoo/enterprise/blob/f622064871bf55b93890606d16407c50cf4419a6/stock_barcode/static/src/models/barcode_model.js#L1446

But exposing a producing lot makes the dispatcher treat the next serial as a conflicting tracking number, since the base _canOverrideTrackingNumber considers a different lot name non-overridable.

https://github.com/odoo/enterprise/blob/f622064871bf55b93890606d16407c50cf4419a6/stock_barcode/static/src/models/barcode_model.js#L796-L798

So the scan is diverted to a new line through the override gate instead of updating the header line.

https://github.com/odoo/enterprise/blob/f622064871bf55b93890606d16407c50cf4419a6/stock_barcode/static/src/models/barcode_model.js#L1585

For a lot-tracked finished product the producing lot can be corrected by scanning a different value, but the lot branch only stored a freshly typed value in lot_name and overwrote lot_producing_ids with the single existing lot.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L404-L407

The header reads its lot from lot_producing_ids whenever that relation is set and only falls back to lot_name when it is empty.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/components/header.js#L45-L58

The save path only promotes lot_name to a producing lot when lot_producing_ids is empty, so scanning an existing lot then a new one neither displayed nor recorded the new lot and the finished product was produced under the old lot.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L628

Solution
--------
Accumulate scanned serials by appending to lot_producing_ids instead of replacing it, and stage a freshly typed lot_name as a new producing lot when the finished product is tracked by serial, so every serial reaches the backend.

Keep the final-product line exposing the last producing lot so each scanned serial is still counted as one unit instead of resetting the quantity to zero once several serials are registered.

Override _canOverrideTrackingNumber for the final-product line so a serial scan updates the header line rather than being diverted to a new line, which is the only valid path for the finished product since it is a single header line backed by the lot_producing_ids relation.

Persist the producing serials with explicit x2many commands, separating already-existing lots from freshly typed ones, so both are written on the MO.

Reject a serial that is already registered on the MO so the same number cannot be produced twice in one session.

For a lot-tracked finished product, build a producing lot from the scanned value, using the existing lot or a freshly typed lot name, and store it in lot_producing_ids so the new lot is both displayed and persisted through the same x2many commands as the serial case.

Leave the produced quantity unchanged when the scanned lot differs from the one already registered, since replacing the lot is a correction and not an extra unit, and keep incrementing it when the same lot is scanned again.

opw-6189620

Forward-Port-Of: odoo/enterprise#116890

A tax created without a fiscal position (empty fiscal_position_ids) is conceptually an "All" tax: it should apply across every fiscal position, including the empty ones used for tax units.

Problem

map_tax drops every tax when the FP has no mapping, including the "All" ones that should pass through.
action_open_related_taxes only lists the FP's tax_ids, so "All" taxes are invisible from the FP form.
The Taxes stat button is hidden whenever the FP has no tax_ids.
action_update_fpos_values invokes the field computes directly, so tax and balance lines fall out of sync after an FP change.

Fix

map_tax: when the FP has no tax_ids, return the input taxes whose fiscal_position_ids is empty (the "All" ones) instead of an empty recordset.
action_open_related_taxes: extend the domain to also include taxes bound to no fiscal position.
partner_view: drop the invisible="not tax_ids" guard on the Taxes stat button.
action_update_fpos_values: route the deferred computes through _check_balanced and _sync_dynamic_lines so tax lines stay in sync after the update.

task-id [6231514](https://www.odoo.com/odoo/project/967/tasks/6231514)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#268273

## Issue
In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
    - Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__

## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157

We obtain the following values:

```js
> monday = section.cells[1]

> monday.value
8.333333333333336

> workingHours[monday.column.value]
8.333333333333332

> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```

This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172

## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.

opw-6193181

Forward-Port-Of: odoo/enterprise#121463

Steps to reproduce
------------------
1. Set a default tax on the "Cash Difference Gain" account (e.g. a 25%
   sales tax) -- required in some countries like Denmark (cf 5972690).
2. Open a PoS session, count more cash than expected at closing.
3. Try to close the session.

-> Error message shows up "The journal entry reached an invalid
state..." ... "The journal entry must always have exactly one journal
item involving the bank/cash account"

What's happening
----------------
PoS creates a bank statement line with the gain account as counterpart,
resulting in 2 lines: cash +10, gain -10. Since the gain account has a
default tax, `_sync_tax_lines` adds a tax line of -2.5 on top, which
makes the move unbalanced by 2.5. Then `_sync_unbalanced_lines` adds a
4th line to fix it, on the line returned by
`_get_automatic_balancing_account`, which is `journal.default_account_id`,
i.e. the cash account itself for a cash journal.

So we end up with 2 lines on that same cash account, which a bank
statement line move doesn't allow -> Error.

The fix
-------
In `_post_statement_difference`, precompute the base and tax split
ourselves and build the statement line's `line_ids` directly (e.g. for
+10 and a 25% tax: cash +10, gain -8, tax -2). The move is balanced
from creation, so `_sync_tax_lines` and `_sync_unbalanced_lines` don't
have to touch it.

Note that we force the tax computation to be in 'force_price_include'
mode, as the counted cash difference is a gross amount (physical money
in the drawer). This way the tax is always extracted from the cash
amount, regardless of how the tax is configured (included or excluded
in price). Same pattern is already used by `hr_expense` (cf
`hr_expense.models.account_move_line._compute_totals`).

opw-5972690

Forward-Port-Of: odoo/odoo#271921
Forward-Port-Of: odoo/odoo#257892

Version:
--------
- 18.0+

Steps to reproduce:
-------------------
- Install `quality_mrp`
- Create a manufactured product with a BoM
- Create a Quality Point for the `Manufacturing` operation of that product
- Create and confirm multiple Manufacturing Orders
- Verify that each MO generates a quality check
- From the MO list view, select the MOs and merge them from the gear menu(merge)

Issue:
------
When Manufacturing Orders are merged, All MOs are cancelled but it keep their
quality checks in the 'To Do' state.

As a result:
- The quality checks remain linked to cancelled MOs
- The 'Quality Checks' smart button is still displayed on cancelled MOs

Expected behavior:
------------------
- Pending quality checks should be deleted when the MO is cancelled
- The 'Quality Checks' smart button should no longer be displayed

Cause:
------
A previous fix introduced logic to remove pending quality checks when a
Manufacturing Order is cancelled:
odoo-dev@db93bd2

This logic was implemented in `action_cancel()` by unlinking quality
checks associated with the cancelled MO:
https://github.com/odoo/enterprise/blob/20bc0eb5c2cec67eecd3b44450934e23370b48f2/quality_mrp/models/mrp_production.py#L94-L97

However, when MOs are merged, the merge flow does not call
`action_cancel()`. Instead, it directly invokes `_action_cancel()` on
the source Manufacturing Orders:

https://github.com/odoo/odoo/blob/aca0b7289c68fc7a75d47ab313f5f791ebf30f7d/addons/mrp/models/mrp_production.py#L2480


Since the quality check cleanup is implemented only in
`action_cancel()`, it is bypassed during the merge process.

As a result, the source MOs are cancelled but their pending quality
checks remain in place.


---

opw-6260735

Forward-Port-Of: odoo/enterprise#121717
Forward-Port-Of: odoo/enterprise#119525

## Issue
In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
    - Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__

## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157

We obtain the following values:

```js
> monday = section.cells[1]

> monday.value
8.333333333333336

> workingHours[monday.column.value]
8.333333333333332

> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```

This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172

## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.

opw-6193181

Forward-Port-Of: odoo/enterprise#121463

Steps to reproduce:
1. Install `account_reports` and set fiscal year beginning date for Tax returns.
2. Open Tax Report from the button on Kanban view of account return.
3. Try to refresh from the report page. Without debug mode, it will return to returns kanban view and with debug mode, it will go back and a traceback will appear.

Cause:
The report from kanban view is opened via a python action method, which returns a `ir.actions.client` of `account_report`. In the controller for report, it tries to fetch the `report_id` from `context` [[1]] set during the python method call.
But when we refresh page, this action context is wiped out, so when it tries to get the report options in controller via orm call [[2]], the report_id is lost, and it causes traceback.

Solution:
This commit tries to get the `report_id` from `action stack` which is prepared based on the url. so it fetches the correct report via ORM call.

[1]: https://github.com/odoo/enterprise/blob/saas-18.3/account_reports/static/src/components/account_report/controller.js#L23
[2]: https://github.com/odoo/enterprise/blob/saas-18.3/account_reports/static/src/components/account_report/controller.js#L167

task-6240800

## Issue
In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
    - Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__

## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157

We obtain the following values:

```js
> monday = section.cells[1]

> monday.value
8.333333333333336

> workingHours[monday.column.value]
8.333333333333332

> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```

This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172

## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.

opw-6193181

Forward-Port-Of: odoo/enterprise#121463

## Issue
In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
    - Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__

## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157

We obtain the following values:

```js
> monday = section.cells[1]

> monday.value
8.333333333333336

> workingHours[monday.column.value]
8.333333333333332

> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```

This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172

## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.

opw-6193181

Forward-Port-Of: odoo/enterprise#121463

Step to reproduce:
- install l10n_co_dian and pos
- open pos and click on create a new partner from partner list
- enter name ex. "temp", identification number, click on form
- notice a `refresh icon` is visible: click on it.

Observation:
- the dialog is closed and partner is selected with "temp" name

Expected:
- with valid government credentials and a valid identification number,
the refresh action should also update the partner data on the POS side

Cause:
- the refresh button triggers the `button_l10n_co_dian_refresh_data` action,
which fetches the legal name and email from the government service
- although the backend record is correctly updated, the new values are not
immediately synchronized with the POS
- when the refresh button is clicked, editPartner() first triggers
`web_save` using the temporary "temp" name and immediately reads the
partner data afterward
- the refresh action executes later and updates the contact with the fetched
legal information, but the POS is not aware of these subsequent changes

Fix:
- read the data again if there is any update caused by this action.
- this is done by overriding `afterExecuteActionButton` of FormController class

opw-6198035

Forward-Port-Of: odoo/enterprise#117527

## Problem
In shop floor, MOs with unplanned work orders get sorted before MOs that have planned operations, which contradicts the normal nulls last sorting for work orders.

## Solution
We will update the sorting logic in the MrpDisplay component to more gracefully handle falsy date_start values, sorting them to the end.

## Steps to reproduce (runbot 19)
1. Create 2 MOs with an operation (work order) involving a work center, we'll call them A and B.
2. Open Shop Floor and open the work center that the MOs' work orders belong to, and note they are ordered A, B (this is fine, neither are planned so the precedence falls back to id
3. Go back to MO B and plan it. This should give it precedence in Shop Floor
4. Under the work center in Shop Floor, note that the MOs are still ordered A, B, despite B's work order having a start date and A's work order not having one

To further motivate this being unintended, you can go to Manufacturing > Operations > Work Orders, and you'll see MO B's work order sitting at the top of the list.

opw-6303323

### Issue:
When installing a new language on a database with `l10n_co_dian`, the DIAN email templates are not translated

Languages already installed when `l10n_co_dian` is installed are correctly translated, as the copy happens at that moment
Only languages installed afterwards are affected

### Cause:
The DIAN email templates are created dynamically via `_create_dian_mail_templates` as copies of the `account` templates
Because they are created at runtime, no translations exist for their XML IDs in the `l10n_co_dian` `.po` files
The `TranslationImporter` finds nothing to import for them

The fix hooks into `_load_module_terms` to sync translations from the source `account` templates to the DIAN ones whenever a new language is installed

`TranslationImporter.save()` is used without `force_overwrite`, so existing translations on `noupdate` records are never replaced
This is the standard way to push translations while preserving any manually modified values

### Notes:
Languages installed before this fix are not updated
Only newly installed languages will get the synced translations

### Steps to reproduce:
- Install `l10n_co_dian`
- Enable Developer Mode in Settings
- Install any language (e.g. `fr_FR`)
- Go in Settings > Technical > Email > Email Templates
- Search for DIAN and open Invoice or Credit Note

Before the fix, the DIAN invoice and credit note templates had untranslated name, description and body_html

opw-6269979

## [FIX] website_sale_renting_planning: prepare payment if demo is installed

Before this commit, the demo  `payment.provider` for the tests was being created in `setUpClass` this caused an issue because `payment_demo` is not a dependency of this module, therefore it may not be installed while these tests are running and cause the tests to error at setup.

After this commit, the `payment.provider` creation was moved into the tests after the check for `payment_demo` installation, ensuring that `payment_demo` would exist when a `payment.provider` is prepared.

https://runbot.odoo.com/odoo/runbot.build.error/940273

## [FIX] website_sale_renting_planning: unforbid weekend in tests
Before this commit, the company had `renting_forbidden_sat` and `renting_forbidden_sun` enabled which made it not possible to rent products from website if the rental date included a saturday or sunday.

This commit fixes that but setting  `renting_forbidden_sat` and `renting_forbidden_sun` to False and allowing rental on all days of the week.

https://runbot.odoo.com/odoo/runbot.build.error/940312

## [FIX] website_sale_renting_planning: search for product in shop page

Before this commit, the website `/shop` page would display all published products in the db, this could cause the `website_sale_renting_planning_buy_product` tour to fail if the setup product is not in the first page.

After this commit, the `/shop` page is now access with a search on the product to ensure there won't be other products in the first page.

https://runbot.odoo.com/odoo/runbot.build.error/940275

## Issue
In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
    - Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__

## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157

We obtain the following values:

```js
> monday = section.cells[1]

> monday.value
8.333333333333336

> workingHours[monday.column.value]
8.333333333333332

> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```

This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172

## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.

opw-6193181

Forward-Port-Of: odoo/enterprise#121463

Steps to reproduce:
---------------------------------------
1. Install Subscription Module
2. Create and Confirm SO with no recurring plan and a non-recurring product
3. Add a recurring product > Save SO > Observe the User Error
4. Now add the same recurring product through Catalog View

Observation:
---------------------------------------
No User Error raised stating
'You cannot save a sale order with recurring product and no subscription plan.'

Issue:
---------------------------------------
When you manually add a line and click 'Save', the constraint (`_constraint_subscription_plan`) is triggered and raised `UserError` https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/sale_subscription/models/sale_order.py#L176-L177

When you add a product via the catalog view, it calls `_update_order_line_info` which directly creates/updates order lines, Which do not trigger the python constraint.
https://github.com/odoo/odoo/blob/ef9772bba1515bdaf5410c3af5a3e395f562d513/addons/sale/models/sale_order.py#L1926-L1933

Solution:
---------------------------------------
Two private helpers are introduced:
* `_is_exempt_from_subscription_plan_check`: single source of truth for all exempt states (draft, cancelled, upsell, and legacy upgrade orders).
* `_check_recurring_plan_mismatch`: raises a `UserError` when the order has or will have a recurring product but no subscription plan, reusing the exemption helper so both call sites stay in sync.

`_constraint_subscription_plan` is refactored to delegate to these helpers, and `_update_order_line_info` is overridden to call `_check_recurring_plan_mismatch` before the catalog update is applied, ensuring consistent validation across both entry points.

opw-6194865

Forward-Port-Of: odoo/enterprise#117879

### Steps to reproduce:
- Download Calendar and Contacts app
- Go to the Setting -> Companies -> Manage companies; make sure there are at least two companies
- Go to the Setting -> Users -> Manage users; make sure the current logged-in user has access to both companies
- Create a another user who also have access to both companies
- Search for the new user in contacts -> Assign the current company to the contact -> Through the internal link of the company, go to sales and purchase tab -> assign the same company in the company field
- Switch the company of the logged in user to the other company
- Open the test contact form, use the meeting smart button and create a new meeting
- Open the kanban contact view

 **> Access Error: Uh-oh! Looks like you have stumbled upon some top-secret records.**
### Cause of Issue:
When trying to view the search results in kanban view, the `meeting_count` is calculated for each contact. Hence,`_compute_meeting_count()` is called which calls `_compute_meeting()`. https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/calendar/models/res_partner.py#L49-L54 Since the above section tries to access `partner.parent_id` each loop, it reaches a `parent_id` that's not accessible for the current user.

### Fix:
Since we need to access `parent_id` to be able to calculate meeting count for the full tree of partners, `sudo()` is used to get all partners, but meetings are computed for ancestors who are in `self_ids` only so that we still remain within scope.
Same old logic is used to propagate meetings for every ancestor, but dictionary lookups are used to enhance performance.

opw-5874204

### Issue:
When invoicing partial quantities from a sale order, more DDTs than necessary are linked to the invoice

Since `l10n_it_ddt_ids` is computed and not stored, the incorrect links persist until the remaining quantities are invoiced, at which point the extra DDTs are moved to the new invoice

This creates inconsistencies in the generated XML, which references DDTs not actually covered by the invoice

### Cause:
The quantity allocation loop only checked whether there was remaining `move_qty` to consume, but never checked whether the invoiced quantity (`inv[0]`) had already been fully consumed

As a result, once all invoiced quantity was allocated, the loop kept iterating and linking additional DDTs from the sale order

### Steps to reproduce:
- Install `l10n_it_stock_ddt` with demo data
- Switch to the IT company
- Create a Warehouse
- Create a Product (Invoicing Policy: Delivered Quantities)
- Create and confirm a Sale Order (qty: 5) for that product
- Validate 3 partial deliveries of qty 1, creating a backorder each time
- Create the invoice, set the quantity to 2 and confirm

Before the fix, 3 DDTs were linked instead of 2

opw-6294035