In certain cases the barcode of a product could be a valid standalone 
GS1 sequence. In that case it needs to be be correctly interpreted as 
a product scan.

### Steps to reproduce:

- In the settings enable "Default GS1 Nomenclature"
- Create a storable product P with the barcode 3701762412212
- Create and confirm a  delivery for 2 units of P and set the qty to 2
- Go to the barcode app and open your delivery
- Scan 3701762412212
> The line of P is now selected with a quantity of 1/2
- Scan 3701762412212
#### > A new line is created for 1762411 units

### Cause of the issue:

According to the GS1 nomenclature, the barcode 3701762412212 matches the scan of a quantity of "1762412" units of the lot name "2". As the scan of the of the product match a pattern for the GS1 nomenclature before matching a product, its barcode data is expected to be reset by these lines:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1320-L1324
In order to bypass the GS1 parser and to add 1 unit of the product. This is what happen on the first scan. However, performing the first scan also selects the associated line and, hence on the second scan the lines just above this check do set the product to match the product of the current line:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1294-L1320
In particular, we do not bypass the result provided by the GS1 parser and add `1762412` units of the product.

opw-6175621

Forward-Port-Of: odoo/enterprise#122256
Forward-Port-Of: odoo/enterprise#120035

**Steps to reproduce:**
- Install Accounting

- Create an invoice:
  * Customer: Partner A
  * Total: 30.00
- Confirm the invoice
- Create a second invoice for the same customer:
  * Customer: Partner A
  * Total; 10.00
- Confirm the invoice

- From the invoice list, select both invoice
- Create payment:
  * Journal: Bank
  * Group Payments: [checked]
  * Amount: 40.00

- Create a third invoice for another customer:
  * Customer: Partner B
  * Total: 25.00
- Confirm the invoice
- Register payment from the invoice

- Create a fourth invoice for another customer:
  * Customer: Partner C
  * Total; 40.00
- Confirm the invoice
- Register payment from the invoice

- From the payment list, select all 3 payments and create batch payment
- Validate the batch payment

- From Accounting dashboard, open Bank journal
- Create a new bank statement line of 105.00
- Match it with the batch payment

At that point, the statement line is reconciled with the 4 invoices and the 3 payments are marked as paid.

- Go to the fourth invoice
- Reset it to draft
- Change the price
- Save

When the amount of the invoice is changed, the statement line is unreconciled and all the payments should change state from "Paid" to "In Process".

**Issue:**
All the single payments have their state correctly changed to "In Process", except for the group payment for the 2 first invoices, which leads to undesired values when trying to reconcile the statement line with the batch payment again.

**Cause:**
When the statement is unreconciled, all the partial reconcile records are deleted and the state of the linked payments are updated to "In Process".
The payments are retrieved by checking if there are linked to an account move present in the partial reconcile record and if the amount of the payment matches the amount of the partial reconcile record. In case of a group payment, there are 2 partial reconcile records for each invoice linked to the payment.
Therefore, in that case, the amount doesn't match the amount of the payment because it matches the amount of one of the invoice.

opw-6141089




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

Forward-Port-Of: odoo/odoo#273563
Forward-Port-Of: odoo/odoo#269510

**Steps to reproduce:**
- Install Accounting

- Create an invoice:
  * Customer: Partner A
  * Total: 30.00
- Confirm the invoice
- Create a second invoice for the same customer:
  * Customer: Partner A
  * Total; 10.00
- Confirm the invoice

- From the invoice list, select both invoice
- Create payment:
  * Journal: Bank
  * Group Payments: [checked]
  * Group Payments: [checked]
  * Amount: 40.00

- Create a third invoice for another customer:
  * Customer: Partner B
  * Total: 25.00
- Confirm the invoice
- Register payment from the invoice

- Create a fourth invoice for another customer:
  * Customer: Partner C
  * Total; 40.00
- Confirm the invoice
- Register payment from the invoice

- From the payment list, select all 3 payments and create batch payment
- Validate the batch payment

- From Accounting dashboard, open Bank journal
- Create a new bank statement line of 105.00
- Match it with the batch payment

At that point, the statement line is reconciled with the 4 invoices and the 3 payments are marked as paid.

- Go to the fourth invoice
- Reset it to draft
- Change the price
- Save

When the amount of the invoice is changed, the statement line is unreconciled and all the payments should change state from "Paid" to "In Process".

**Issue:**
All the single payments have their state correctly changed to "In Process", except for the group payment for the 2 first invoices, which leads to undesired values when trying to reconcile the statement line with the batch payment again.

**Cause:**
When the statement is unreconciled, all the partial reconcile records are deleted and the state of the linked payments are updated to "In Process".
The payments are retrieved by checking if there are linked to an account move present in the partial reconcile record and if the amount of the payment matches the amount of the partial reconcile record. In case of a group payment, there are 2 partial reconcile records for each invoice linked to the payment.
Therefore, in that case, the amount doesn't match the amount of the payment because it matches the amount of one of the invoice.

opw-6141089

Forward-Port-Of: odoo/enterprise#122585
Forward-Port-Of: odoo/enterprise#120210

### Issue:
When a bank journal uses a foreign currency, reconciliation model lines with `Amount Type: From Label` (regex) could raise a constraint error or produce incorrect balances on the journal entry

### Cause:
The `balance` of the generated move line was set to the raw value extracted by the regex, without converting it from the journal currency to the company currency

This violated the sign constraint between `balance` and `amount_currency` when the exchange rate caused a mismatch, raising a `_check_amount_currency_balance_sign` error

The `amount_currency` was already correctly set
Only the `balance` conversion was missing

### Steps to reproduce:
- Install `accountant`
- Enable a foreign currency (e.g. EUR) with two rates: yesterday: ratio < 1 (e.g. 0.5), today: ratio > 1 (e.g. 2.0)
- Create a Bank journal in EUR
- Open Bank Reconciliation for that journal
- Add two transactions (one dated yesterday, one today) (Ref: "test BANK:0001690,00EUR EXP:00033,80", amount: 1656.20)
- Create a reconciliation model (3 dots > Manage Models) (name: From Label):
-- Account: 101401 Bank, Amount: BANK:0*(\d+),(\d+)
-- Account: 600000 Expenses, Amount: EXP:0*(\d+),(\d+)
- Apply the model on both transactions
Before the fix, one raised an error due to the constraint violation
- From the list view, open the Journal Entry for the other transaction
Before the fix, `balance` was not converted to company currency

opw-6292839

Forward-Port-Of: odoo/enterprise#121114

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Intrastat"

- Create a product with Intrastat info
- Create a bill:
  * Product: [the created Intrastat product]
  * Intrastat Country: [any]
  * Intrastat Transport Mode: [any]
- Confirm the bill
- Make sure that the bill name contains a hyphen character (i.e. "-")
For example, "BILL/2026-06/0001".
Use the "Resequence" action from the bills list view if needed.

- Go to "Accounting / Reporting / Audit Reports / Intrastat Report"
- Expand the line to display the bill name

**Issue:**
The bill name is not fully displayed.
It is cropped right before the hyphen character (i.e. BILL/2026).

**Cause:**
A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character.

**Solution:**
Just allow "-" character in addition.
No other character is allowed to limit the risk of matching something that should not.

opw-6299854

Forward-Port-Of: odoo/enterprise#120979

Steps to reproduce
1. Create a service product: Invoicing Policy = Prepaid/Fixed Price, Track Service = Timesheets, Unit of Measure = Days
2. Confirm a Sales Order with 2 days of that product at 800/day
3. Register 1 hour on the generated task
4. Open Timesheets > Reporting, add the "Timesheet Revenues" measure

Issue
`timesheet_revenues` in `timesheets.analysis.report` was computed per analytic line as `(SOL.price_subtotal / SOL.qty_delivered) * (unit_amount * sol_uom.factor / ts_uom.factor)` (https://github.com/odoo/odoo/blob/16f170619d9cc5fd86529a3f17e349da37607f73/addons/sale_timesheet/report/timesheets_analysis_report.py#L42-L44).

`SOL.qty_delivered` is a stored float rounded to the day UoM precision (0.01d). For 1 hour timesheeted, qty_delivered = 1/8 = 0.125d rounds to 0.13d, so the formula yields (1600 / 0.13) × (1/8) = 1538.46 instead of the correct 100. Because `qty_delivered` is recomputed each time a timesheet is added, all existing rows shift their revenue figure with every new entry.

Additionally, using `price_subtotal / qty_delivered` as the per-unit rate ignores any line discount: the rate derived from a discounted subtotal divided by a delivered quantity that differs from the ordered quantity is not the effective price per day.

For prepaid lines, the effective per-unit rate is `price_subtotal / product_uom_qty` — the ordered quantity is stable and the subtotal already reflects any discount — multiplied by the timesheet hours converted to the SO line UoM.

opw-6150555

Forward-Port-Of: odoo/odoo#272910
Forward-Port-Of: odoo/odoo#262524

## Issue
When using the Timesheets systray, if we set a project after clicking the *Save* or *Reset* button, the project is not saved after closing the systray.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. Open the Timesheets systray
3. Click *Reset* and set a description, a project and/or a task, then close the systray
4. Open the systray again
5. **The description/project/task set in step 3 do(es) not appear anymore.**

## Cause
Commit https://github.com/odoo/enterprise/commit/b9b7f8a0acf7a1c545c6613cf8bbc29871632e26 introduced the `preventUnmountSave` attribute. The attribute is set to `true` after saving and discarding an entry. When the systray is unMounted, the manual values (e.g., description, project and task) are not saved if the attribute is set to `true`:

https://github.com/odoo/enterprise/blob/7cd8dd008eb88d6c12f3e65fb8d311058290a301/timesheet_grid/static/src/components/timesheet_timer_inline_form/timesheet_timer_inline_form.js#L171-L174

## Fix
After discussing with the author of the previous commit, it appears this was done to prevent an issue with values stored in cache, but that issue does not seem to occur anymore, which leads to believe that the attribute is not required anymore.

opw-6284016

Forward-Port-Of: odoo/enterprise#122332
Forward-Port-Of: odoo/enterprise#121605

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi_withholding
2. Switch to IT company
3. Create 2 taxes with a Pension fund type set (in Advanced Options)
4. Create an invoice and set on the same line the 2 taxes created
5. Click on send and print and see the error: Invoices must have at most one Pension Fund tax set per line. (even if it's not true)

### Cause of the issue:
The following function check how many taxes we have per line but this limit is incorrect because it is accepted by the Italian electronic invoicing specifications to have also more than 1 tax. 
https://github.com/odoo/odoo/blob/bd095fe286930acc54d85bdf7f92af15569f5b82/addons/l10n_it_edi/models/account_move.py#L1268-L1273

### Reference documentation:

1. [Art. 10 della Legge n. 183_2011, successivamente integrato dal D.L. n. 1_2012 (art. 9-bis)..pdf](https://github.com/user-attachments/files/29056003/Art.10.della.Legge.n.183_2011.successivamente.integrato.dal.D.L.n.1_2012.art.9-bis.pdf)

2. Following image:
<img width="823" height="580" alt="estrattoEppi" src="https://github.com/user-attachments/assets/e79be16f-651e-467a-84f4-8400185ceea4" />


opw-6264685

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

Forward-Port-Of: odoo/odoo#273040
Forward-Port-Of: odoo/odoo#269456

[FIX] hr_payroll: fix correct company selection in payrun (branch case)

Bug reproduc:

    1 - Select 19.3 or master -> Open a branch to belgium company -> create an employee in that branch
    2 - In your env, select both belgium and its branch, payroll->payrun->select branch as a company.
    3 - Continue till the end of payrun creation, you will get warning (blocked) due to wrong company selection, main belg company is selected instead of branch

Bug cause:

    1 - In selectEmployees function of hr_payslip_run_form, in the raw_record the company_id is passed as integer.
    2 - In buildRawRecord function of hr_version_list_controller, we are assigning company_id as raw_record's company_ids id, but company id was already integer, company_id.id is undefined
    3 - Since undefined is passed to the company_id, it uses the self.env.company_id as a default in the creation of hr payrun that cause to the error.

Bug fix:

    1 - In the buildRawRecord function of hr_version_list_controller, I just assigned the company_id because it is already integer and all problem is solved.

task - 6326117

Forward-Port-Of: odoo/enterprise#121505

Currently on the pos payment method form, if you click "Select more" on the journal field, you will see two buttons 'New' & 'Create New'.

Steps to reproduce:
-------------------
* Open any pos payment method
* Select the journal field
* Select "Search more"
> See two creation buttons

Why the fix:
------------
One button is the standard "On search more" button which can be hidden using options such as no_create, no_create_edit, ...

The second button is defined on the list view for journals and since the search more uses the list view it shows the button as well. Currently we can do that with a context key to ensure that on the "real" list view it's still visible.

Why do we want to hide those buttons? Asked the R&D accounting team, it should not be allowed to create journals on the fly. You should only be able to create them inside accounting app.

Before the fix:
-------------------
<img width="700" height="417" alt="image" src="https://github.com/user-attachments/assets/6b67a45b-6e52-4e02-a827-1aca5d8417ec" />
<img width="1507" height="887" alt="image" src="https://github.com/user-attachments/assets/077bc3ab-bc6e-42a1-85e6-adf778000b92" />

After the fix:
-----------------
<img width="707" height="474" alt="image" src="https://github.com/user-attachments/assets/da2a43e3-01c0-44c5-b529-e73f21825150" />
<img width="1457" height="870" alt="image" src="https://github.com/user-attachments/assets/b658b95f-5bc3-4b7a-9e7c-8b182cab48a0" />


opw-6131231

Forward-Port-Of: odoo/odoo#269716

Currently on the pos payment method form, if you click "Select more" on the journal field, you will see two buttons 'New' & 'Create New'.

Steps to reproduce:
-------------------
* Open any pos payment method
* Select the journal field
* Select "Search more"
> See two creation buttons

Why the fix:
------------
One button is the standard "On search more" button which can be hidden using options such as no_create, no_create_edit, ...

The second button is defined on the list view for journals and since the search more uses the list view it shows the button as well. Currently we can do that with a context key to ensure that on the "real" list view it's still visible.

Why do we want to hide those buttons? Asked the R&D accounting team, it should not be allowed to create journals on the fly. You should only be able to create them inside accounting app.

This behavior is not limited to this view but will only be applied locally. The fix can however be applied everywhere where needed.

Before the fix:
-------------------
<img width="700" height="417" alt="image" src="https://github.com/user-attachments/assets/ca11ea13-c38e-40a1-9848-cbc5edc6226e" />
<img width="1507" height="887" alt="image" src="https://github.com/user-attachments/assets/1cde5d3b-3372-4aca-b5d0-2319bd82c1de" />

After the fix:
----------------
<img width="707" height="474" alt="image" src="https://github.com/user-attachments/assets/01dc7b42-43d6-4b18-a12d-54330d51b92b" />
<img width="1457" height="870" alt="image" src="https://github.com/user-attachments/assets/ff387d3f-f59c-47ad-abfe-a2003669db1a" />


opw-6131231

Forward-Port-Of: odoo/enterprise#120379

When an order is sent to the preparation display and one of its products has an attribute with a custom (free text) value, completely deleting that line in the PoS makes the whole preparation display crash and show a blank white screen, so the kitchen can no longer see any order.

Steps to reproduce:
-------------------
* Configure a PoS product with an attribute whose variant that has a custom (free text) value.
* In the PoS, add the product, select that attribute value and send the order to the preparation display.
* Back in the PoS, completely delete that order line (do not just set its quantity to 0) and send the order to the preparation display again.

> Observation:
The preparation display crashes and only a white screen is shown. The browser console reports "TypeError: Cannot read properties of undefined (reading 'id')".

Why the fix:
------------
Completely deleting the line deletes the source pos.order.line, so the preparation line that is still displayed no longer resolves its `pos_order_line_id`. While building the attributes to display, the orderline component dereferenced `.id` on that (now undefined) relation, as well as on the related custom value records, which threw and brought down the whole preparation display instead of only that line.
We now guard those relations: when the originating order line is gone, the unresolvable custom value is simply dropped and the attribute is still shown, keeping the preparation display alive.

opw-6282607

Forward-Port-Of: odoo/enterprise#121194

### [FIX] website: guard form default email in cross-company editing
Since [1], the website form uses the website's company email as the
default recipient. With cross-company editing, the editor user may not
have access to that company's email and hits an `Access Error` when
reading `res.company`.
This commit catches the error and falls back to the editor user's email.

Steps to reproduce:
- Log in as admin
- Set demo user Access Right to `Editor and Designer` for website
- Log in as demo user
- Change company to `My US company`
- Enter website builder and edit mode on `My website`
- Drop a snippet `s_website_form`
- Save
- Traceback: `Access Error`

[1]: https://github.com/odoo/odoo/commit/10eea785e631fb3398ed5df5bfbb8d2f17453551

---

### [FIX] website: ensure default email is used for every form
Following [1], `applyDefaultValues` was no longer applied to snippets
that contain an `s_website_form` without being one themselves, such as
`s_website_form_info`.
`onSnippetDropped` only matched `.closest(".s_website_form")`,
so wrapper snippets returned early and never got their default recipient
email.

Steps to reproduce:
- Drop a `s_website_form_info`
- Click on the form
- "Recipient Emails" is empty, it should contain the company email

task-6356910

[1]: https://github.com/odoo/odoo/commit/ff44e9d56fa64f02946a1432a03f19db1b17ec37

Steps to reproduce
---
1. Pay a website sale order through a payment provider (the payment stays In Process).
2. Reconcile that provider payment with a bank statement line before invoicing.
3. Confirm the delivery and create the invoice for the order.

Issue
---
The invoice is posted but stays open: the linked payment is never assigned to it, even though its receivable line is still outstanding and is even offered in the invoice outstanding-credits widget.

Reconciling the bank statement first fully matches the payment's liquidity line, so the payment moves to the 'paid' state while its receivable line stays open. At invoice posting, _post only auto-assigns payments still in the 'in_process' state, so a 'paid' payment is skipped and its receivable is left unreconciled, leaving the invoice open and requiring a manual intervention.

The matched case was lost in 01b87f1230be, which split the former 'posted' state into 'in_process' (cash not matched) and 'paid' (cash matched) and mechanically renamed this filter to 'in_process' only, dropping the matched payments the old 'posted' used to cover. Restoring 'paid' fixes it while the existing not-reconciled guard still keeps failed payments out.

https://github.com/odoo/odoo/blob/2b89d39f9329ac0fe7a2938595d1f6ee16dc2924/addons/sale/models/account_move.py#L115-L126

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

Forward-Port-Of: odoo/odoo#270315

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#121742
Forward-Port-Of: odoo/enterprise#120180

In certain cases the barcode of a product could be a valid standalone 
GS1 sequence. In that case it needs to be be correctly interpreted as 
a product scan.

### Steps to reproduce:

- In the settings enable "Default GS1 Nomenclature"
- Create a storable product P with the barcode 3701762412212
- Create and confirm a  delivery for 2 units of P and set the qty to 2
- Go to the barcode app and open your delivery
- Scan 3701762412212
> The line of P is now selected with a quantity of 1/2
- Scan 3701762412212
#### > A new line is created for 1762411 units

### Cause of the issue:

According to the GS1 nomenclature, the barcode 3701762412212 matches the scan of a quantity of "1762412" units of the lot name "2". As the scan of the of the product match a pattern for the GS1 nomenclature before matching a product, its barcode data is expected to be reset by these lines:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1320-L1324
In order to bypass the GS1 parser and to add 1 unit of the product. This is what happen on the first scan. However, performing the first scan also selects the associated line and, hence on the second scan the lines just above this check do set the product to match the product of the current line:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1294-L1320
In particular, we do not bypass the result provided by the GS1 parser and add `1762412` units of the product.

opw-6175621

Forward-Port-Of: odoo/enterprise#122256
Forward-Port-Of: odoo/enterprise#120035

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Intrastat"

- Create a product with Intrastat info
- Create a bill:
  * Product: [the created Intrastat product]
  * Intrastat Country: [any]
  * Intrastat Transport Mode: [any]
- Confirm the bill
- Make sure that the bill name contains a hyphen character (i.e. "-")
For example, "BILL/2026-06/0001".
Use the "Resequence" action from the bills list view if needed.

- Go to "Accounting / Reporting / Audit Reports / Intrastat Report"
- Expand the line to display the bill name

**Issue:**
The bill name is not fully displayed.
It is cropped right before the hyphen character (i.e. BILL/2026).

**Cause:**
A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character.

**Solution:**
Just allow "-" character in addition.
No other character is allowed to limit the risk of matching something that should not.

opw-6299854

Forward-Port-Of: odoo/enterprise#120979

Steps to reproduce
1. Create a service product: Invoicing Policy = Prepaid/Fixed Price, Track Service = Timesheets, Unit of Measure = Days
2. Confirm a Sales Order with 2 days of that product at 800/day
3. Register 1 hour on the generated task
4. Open Timesheets > Reporting, add the "Timesheet Revenues" measure

Issue
`timesheet_revenues` in `timesheets.analysis.report` was computed per analytic line as `(SOL.price_subtotal / SOL.qty_delivered) * (unit_amount * sol_uom.factor / ts_uom.factor)` (https://github.com/odoo/odoo/blob/16f170619d9cc5fd86529a3f17e349da37607f73/addons/sale_timesheet/report/timesheets_analysis_report.py#L42-L44).

`SOL.qty_delivered` is a stored float rounded to the day UoM precision (0.01d). For 1 hour timesheeted, qty_delivered = 1/8 = 0.125d rounds to 0.13d, so the formula yields (1600 / 0.13) × (1/8) = 1538.46 instead of the correct 100. Because `qty_delivered` is recomputed each time a timesheet is added, all existing rows shift their revenue figure with every new entry.

Additionally, using `price_subtotal / qty_delivered` as the per-unit rate ignores any line discount: the rate derived from a discounted subtotal divided by a delivered quantity that differs from the ordered quantity is not the effective price per day.

For prepaid lines, the effective per-unit rate is `price_subtotal / product_uom_qty` — the ordered quantity is stable and the subtotal already reflects any discount — multiplied by the timesheet hours converted to the SO line UoM.

opw-6150555

Forward-Port-Of: odoo/odoo#272910
Forward-Port-Of: odoo/odoo#262524

## Issue
When using the *Auto Plan* feature on a planning slot with a Role and a Project set, a resource which operated on the same project will be chosen if available, without taking into account the Role set on the slot.

## Steps to reproduce
1. Install Project Planning (`project_forecast`)
2. In Planning > Configuration > Roles, create two planning roles A and B
    - Role A: Assign a resource R
    - Role B: No resource
3. Open Planning (Schedule by Resource), and go back a few weeks (to prevent overlaps with potential demo data)
4. Create two new slots:
    1. Set Role B and a random Project P, then click Auto Plan: there should be no available resource (because we didn't set any resource for Role B)
    2. Set Role A and the same Project P, then click Auto Plan: it should assign the resource R assigned to Role A
5. After assigning a resource to the slot for Role A, edit the Open Shift for Role B again and click Auto Plan: **it assigns the same resource R, even though that resource is not assigned to Role B.**

## Cause
The `_get_open_shifts_resources` override in `project_forecast` looks for resources that were assigned to slots related to the same project. It does not filter resources based on the requested role.

https://github.com/odoo/enterprise/blob/885edbc270a86ab76e0a6eff4acb5767c0fe29d1/project_forecast/models/planning_slot.py#L104-L116

This means that resources that are not part of the requested role can be assigned to the slot, as long as the resource operated on another slot for the same project.

opw-6325744

Forward-Port-Of: odoo/enterprise#122352
Forward-Port-Of: odoo/enterprise#122035

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi_withholding
2. Switch to IT company
3. Create 2 taxes with a Pension fund type set (in Advanced Options)
4. Create an invoice and set on the same line the 2 taxes created
5. Click on send and print and see the error: Invoices must have at most one Pension Fund tax set per line. (even if it's not true)

### Cause of the issue:
The following function check how many taxes we have per line but this limit is incorrect because it is accepted by the Italian electronic invoicing specifications to have also more than 1 tax. 
https://github.com/odoo/odoo/blob/bd095fe286930acc54d85bdf7f92af15569f5b82/addons/l10n_it_edi/models/account_move.py#L1268-L1273

### Reference documentation:

1. [Art. 10 della Legge n. 183_2011, successivamente integrato dal D.L. n. 1_2012 (art. 9-bis)..pdf](https://github.com/user-attachments/files/29056003/Art.10.della.Legge.n.183_2011.successivamente.integrato.dal.D.L.n.1_2012.art.9-bis.pdf)

2. Following image:
<img width="823" height="580" alt="estrattoEppi" src="https://github.com/user-attachments/assets/e79be16f-651e-467a-84f4-8400185ceea4" />


opw-6264685

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

Forward-Port-Of: odoo/odoo#273040
Forward-Port-Of: odoo/odoo#269456

### Issue:

Editing the `lot_ids` of a move of a `lot` tracked product from the picking form view leads to wildly unexpected results. This happens only with tracking by `lot` not by serial.

### Concrete Issue 1:

1. In the settings Enable "Lots and serial numbers", "Storage Locations"
2. Create a storable product P tracked by lots
3. Create and confirm a delivery for 5 units of P
4. Set the quantity of the move to 5 from the Form picking view > save
5. Create and set 2 lots: LOT1, LOT2 on the serial numbers field
6. Save
#### > The quantity of the move has been updated to 2, only the first lot is set and it has been for this quantity of 2

### Concrete Issues 2 and 3:

1. In the settings Enable "Lots and serial numbers", "Storage Locations"
2. Create a storable product P tracked by lots
3. Update the onhand quantity of P:
    - 1 units of LOT001 in Shelf1
    - 2 units of LOT001 in Shelf2
    - 2 units of LOT002 in Stock
4. Create and confirm a delivery for 5 units of P
5. Remove LOT002 from the Serial numbers in the Form picking view > save
#### > The quantity of the move is updated to 1 (only the 1 unit of LOT001 from Shelf2 is kept)
5'. Remove LOT002 and put it back
#### > The quantity is updated from 5 to 2 if you save, only LOT001 is kept.

### Cause of the issue:

The `_onchange_lot_ids` and `_set_lot_ids` methods have been tailored to work appropriately only with `serial` tracking, updating the quantities considering a 1 to 1 quantity, lot matching:
https://github.com/odoo/odoo/blob/c9715982134220aa8fa525d0cf6a8d47eaeb6ed6/addons/stock/models/stock_move.py#L623-L645
However, for lot tracked product the situation is much more subtle to handle.

### Behavior after the fix:

Editing the `lot_ids` on tracked products should adapt the reservation following these rules:
- Existing move lines with a valid lot or lot name should be kept unchanged.
- Removing a lot should delete its related move lines and adjust the move quantity accordingly.
- Each newly assigned lot must be linked to at least one move line of the move.

If the move is expected to bypass reservation (e.g. receipts, final move of a production,...):
- Assignment should be performed, in priority, on an existing free move line.
- If no suitable free move line exists, a new move line should be created with the largest possible quantity that does not cause the total assigned quantity to exceed the move demand.
- If such a quantity cannot be assigned, the new move line should be created with a quantity of 1 in the product.uom_id.

If the move is expected to be reserved (e.g. internal transfer, deliveries,...):
- Each new lot should be assigned from an existing quants with the maximum available quantity to satisfy at best the remaining demand.
- If no available quantity can be assigned from existing quants, the lot should be assigned a minimum quantity of 1 in product.uom_id.

### Additional note on the fix:

Since move that do bypass reservation use a different detailed operation view relying on lot_names form move line rather than lot_id from existing quants it is important to set both the `lot_name` as well as the `lot_id` on move lines for the changes to be visible in the detailed operations view.

### Note:

The current fix populated records on which the `label_production_view_pdf` report was tested (by the test_report) highlighting a template error:
https://github.com/odoo/odoo/blob/a73428187112b3948a11810abae2a3c82c9c7bcd/addons/mrp/report/mrp_production_templates.xml#L187
The value provided to the t-field being something else than a field but rather an or close between two fields.


opw-6173914
opw-5881661

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

Forward-Port-Of: odoo/odoo#272253
Forward-Port-Of: odoo/odoo#263037

Currently on the pos payment method form, if you click "Select more" on the journal field, you will see two buttons 'New' & 'Create New'.

Steps to reproduce:
-------------------
* Open any pos payment method
* Select the journal field
* Select "Search more"
> See two creation buttons

Why the fix:
------------
One button is the standard "On search more" button which can be hidden using options such as no_create, no_create_edit, ...

The second button is defined on the list view for journals and since the search more uses the list view it shows the button as well. Currently we can do that with a context key to ensure that on the "real" list view it's still visible.

Why do we want to hide those buttons? Asked the R&D accounting team, it should not be allowed to create journals on the fly. You should only be able to create them inside accounting app.

Before the fix:
-------------------
<img width="700" height="417" alt="image" src="https://github.com/user-attachments/assets/6b67a45b-6e52-4e02-a827-1aca5d8417ec" />
<img width="1507" height="887" alt="image" src="https://github.com/user-attachments/assets/077bc3ab-bc6e-42a1-85e6-adf778000b92" />

After the fix:
-----------------
<img width="707" height="474" alt="image" src="https://github.com/user-attachments/assets/da2a43e3-01c0-44c5-b529-e73f21825150" />
<img width="1457" height="870" alt="image" src="https://github.com/user-attachments/assets/b658b95f-5bc3-4b7a-9e7c-8b182cab48a0" />


opw-6131231

Forward-Port-Of: odoo/odoo#269716

Currently on the pos payment method form, if you click "Select more" on the journal field, you will see two buttons 'New' & 'Create New'.

Steps to reproduce:
-------------------
* Open any pos payment method
* Select the journal field
* Select "Search more"
> See two creation buttons

Why the fix:
------------
One button is the standard "On search more" button which can be hidden using options such as no_create, no_create_edit, ...

The second button is defined on the list view for journals and since the search more uses the list view it shows the button as well. Currently we can do that with a context key to ensure that on the "real" list view it's still visible.

Why do we want to hide those buttons? Asked the R&D accounting team, it should not be allowed to create journals on the fly. You should only be able to create them inside accounting app.

This behavior is not limited to this view but will only be applied locally. The fix can however be applied everywhere where needed.

Before the fix:
-------------------
<img width="700" height="417" alt="image" src="https://github.com/user-attachments/assets/ca11ea13-c38e-40a1-9848-cbc5edc6226e" />
<img width="1507" height="887" alt="image" src="https://github.com/user-attachments/assets/1cde5d3b-3372-4aca-b5d0-2319bd82c1de" />

After the fix:
----------------
<img width="707" height="474" alt="image" src="https://github.com/user-attachments/assets/01dc7b42-43d6-4b18-a12d-54330d51b92b" />
<img width="1457" height="870" alt="image" src="https://github.com/user-attachments/assets/ff387d3f-f59c-47ad-abfe-a2003669db1a" />


opw-6131231

Forward-Port-Of: odoo/enterprise#120379

## Problem
When multiple Default Prompts are configured for the same AI Agent and
interface key, clicking the "Ask AI" button raises a ValueError.

## Cause
The `_get_composer_from_key_and_model` method searches for composers matching
an interface_key and model, but doesn't limit the results. When multiple
Default Prompts exist for the same agent, the search returns multiple records,
causing a singleton error when accessing `ai_agent_id`.

## Steps to Reproduce

[[Video](https://drive.google.com/file/d/1yMAmX4RuevS0vH07qex2V0fMAiLrtJBg/view?usp=sharing)]
1. Go to AI > Configuration > Default Prompts
2. Create a new Default Prompt with Odoo Agent
3. Click the Ask AI button in the top-right corner
4. Error: ValueError: Expected singleton: ai.agent(2, 1)



## Fix

Replace the two-step search with a single search using an `OR` domain:

- Search both model-specific and generic Default Prompts in one query.
- Order the results with `focused_model_id desc` so model-specific prompts are preferred over generic ones.
- Return only one record using `limit=1`.

This preserves the previous behavior while preventing singleton errors.

---
opw-6323764

**Steps to reproduce:**
* Install the **account_peppol** and **l10n_be** module.
* Switch to BE Company.
* Create and confirm a BE customer invoice.
* Open the "Send & Print" dialog.
* Activate Peppol (register as a Peppol participant) in developer mode and demo mode by clicking on `Why should you use it ?` on the banner in wizard.

**Observed behavior:**
* An Uncaught Promise OwlError trace is thrown on the screen: `TypeError: Cannot use 'in' operator to search for 'toString' in null`.
* The success notification indicating that Peppol was activated fails to appear.

**Cause:**
* Upon successful registration, the `peppol.registration` wizard triggers a client action to display a success notification via `display_notification`.
* The backend Python code explicitly passed `title=None` in the notification parameters, which is serialized to `null` in the JavaScript frontend.
* In previous versions (like 19.2), the `Notification` component's `title` prop validation was defined loosely as `{ type: [String, Boolean, { toString: Function }] }`. OWL did not strictly validate this shape, allowing `null` to pass through without error.
* In 19.3, the prop validation was updated to strictly enforce the object shape: `{ type: [String, Boolean, { type: Object, shape: { toString: Function } }] }`. Because JavaScript evaluates `typeof null` as `"object"`, the OWL validation schema now attempts to verify the shape by evaluating `'toString' in null`. Using the `in` operator on `null` is illegal in JavaScript and immediately crashes the application.

**Fix:**
* Replace `title=None` with `title=False` in the `_action_send_notification` method.
* This translates to `false` in the JavaScript frontend, which seamlessly satisfies the `Boolean` prop type validation for the OWL component and allows the notification to render safely without errors.

opw-6333224

The previous memory profiler was causing a lot of performance issues.
This is because tracemalloc tracks the allocations that happens at the
python interpreter level by attaching to the cpython allocators. This
first meant each allocation that happens through python has to go
through a callstack while holding the GIL and preventing the thread and
other threads from operating. This callstack does multiple things,
first is walking the allocation back from the current frame up until
the specified frame depth at the start of collection. The other is
updating the internal object that keeps track of the allocations and
what cause them up until now which degrades the performance even more
when the allocator keeps running for a long time. Increasing the frame
depth also means the partitioning becomes even more fragmented in the
internal object and leads to higher memory usage. This in turns means
lower performance as well. The issue becomes more evident when the
overhead of tracemalloc blocks any execution even turning it off
because the gil cannot be released until the full allocation execution
happens.

Currently this would happen on long enough requests or a high enough
depth.

Two PRs were made to try to address this issue.

1- https://github.com/odoo/odoo/pull/251950 : This PR tries the
solution of having a lower frame depth but matching the frames based on
a window of frames so that we can reconstruct an approximation of the
flamegraph, for example: matching window of 2 frames
1 - > 2 - > 3 - > 4
2 - > 3 - > 4 - > 5
would mean that we would match frames 2 and 3 in both stack traces and
append the first frame to the second callstack which would look like
1 - > 2 - > 3 - > 4 - > 5
Neverthless this was deemed to have too big of an assumption in the
building heuristic.

2- https://github.com/odoo/odoo/pull/253120: This PR was supposed to be
introducing memray as a profiler. Memray is the best tool for this
usecase. First because it attaches on the native system allocation
calls, and uses a file to append to on allocations. This solves both of
the issues that we had in the beginning but the issue with memray is
that it's an external tool that was deemed unnecessary to add.

The final solution is this PR:
The PR assumes a heuristic that in worker mode, a single worker handles
one thread which mean that the process memory can be fully attributed
to the request. The heuristic is also based that on a high enough
sampling rate, the delta can be fully attributed to the current frame.
This is a close enough approximation to know where to look but not what
is the actual memory usage by line.

Forward-Port-Of: odoo/odoo#273158
Forward-Port-Of: odoo/odoo#253604

### Steps to reproduce:

- In the settings Enable: Multi-steps Routes, Packages
- Put your warehouse in delivery in 2-steps
- On the Pick operation type in the barcode tab disable: "Allow extra products"
- Create two storable products P1 and P2
- On P2 > On hand > Update Quantity > New
- Create a new line in WH/Output with a package POOK for 1 unit
- Create a new internal transfer for 1 unit of P1 using the pick operation type so that the picking goes WH/Stock -> WH/Output
- Set the quantity of the move to 1 unit and go to the barcode app
- Open the Pick > Scan WH-STOCK > Scan P1 > Scan POOK
#### > An error is raised: This package contains extra products and extra products are not allowed on this operation.
#### Expected behavior:
The package should be set as result package.

### Cause of the issue:

In the `_processPackage`, a check that is done to ensure that the package scan will not add extraproduct to the picking if this operation is not allowed:
https://github.com/odoo/enterprise/blob/5e4c8ecb0c644e21755570ed59cd8f6e9f618c8a/stock_barcode/static/src/models/barcode_picking_model.js#L2024-L2035
Unfortunately, this check is done just before a possible usage of the package as package dest. And, in that case, since we do not try to add any product to the picking the check is irrelevant anyway.

opw-6303969

Forward-Port-Of: odoo/enterprise#121789

**Problem:**
On a round-the-clock (0h-24h) working schedule, shifts created from a shift template that spans more than one day get one extra minute added to their allocated time: an 8-hour shift shows 08:01.

**Steps to reproduce:**
1. Create a working schedule with a 00:00 -> 24:00 attendance for every day (24h/day, "Full Day").
2. Assign an employee to that schedule.
3. Create a multi-day-span shift template (e.g. 16:00 -> 00:00, 2 days).
4. Plan a shift for that employee using the template.
5. Observe the Allocated Time shows one minute more than expected (08:01).

**Current behavior:**
Allocated Time is one minute too long (e.g. 08:01 instead of 08:00), which throws off the customer's planning reports.

**Expected behavior:**
Allocated Time matches the template duration exactly (08:00).

**Cause of the issue:**
In `_calculate_start_end_dates`, the end of a multi-day-span shift is computed with `resource.calendar_id.plan_days(...)`. On a 0h-24h calendar each day ends at `time.max` (23:59:59.999999), so `plan_days` returns an end datetime carrying those stale seconds. The following `end.replace(hour=..., minute=...)` overwrites only the hour and minute, leaving `second=59, microsecond=999999`. The slot is therefore ~1 minute longer than intended, and `allocated_hours` rounds that up to 08:01.

**Fix:**
Resetting seconds and microseconds when rebuilding the end datetime keeps the slot aligned to the template's whole-minute boundary, regardless of how the underlying calendar represents the end of day. The hour/minute already come from the template, so the leftover sub-minute precision from `plan_days` is never meaningful and is what produces the drift.

opw-6265238

Forward-Port-Of: odoo/enterprise#121964
Forward-Port-Of: odoo/enterprise#120219

# Setup
Ensure you currently have no activity

# How to reproduce
- Go to any form view with a chatter (e.g. Quotation form view)
- Add 2 activities with a due date of today or before
> Notice there activity counter next to the activity clock icon in the top right should be 2
- Click on the activity clock icon in the top right
> Notifce the activity counter decreases to 1
- Mark as done both To-Do activites

# The problem
The activity counter is negative

# Cause
This issue is due to a desync between the activity counter client side and server side.
When clicking on the activity clock icon, the front-end fetches the mail store data from the
backend, which is why we see the activity counter decrease.

The server computes the activity counter the following way :
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/res_users.py#L457

It searches for up to 1000 activities and group them by the record they are
associated to (e.g. a sale.order). Then, for each of these records, if atleast
one activity is late or for today, increase the counter by 1 :
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/res_users.py#L504-L509

Essentially, server side, we get a single +1 in the activity counter by record, not by activity

On the other hand, client side, we simply add 1 in the activity counter every time a
new activity is created. If an activity is deleted, then we remove 1 :
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/static/src/core/web/mail_core_web_service.js#L17-L30
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/mail_activity.py#L305-L309

# Proposed solution
Both the client and server side logic were edited fairly recently

Server side :
https://github.com/odoo/odoo/pull/234899

Client side :
https://github.com/odoo/odoo/pull/215880

According to experts, the activity counter should count records, not activities, so we
should fix the client side but properly doing so would introduce too much complexity.
We instead simply prevent the counter from going below 0.

opw-6116821

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

Forward-Port-Of: odoo/odoo#259602

**Steps to reproduce:**
- Install the `l10n_mx_reports` module and switch to a Mexican company.
- Navigate to Accounting > Reporting > Trial Balance.
- From the dropdown menu, click `SAT (XML)`.
- Open the generated XML file and inspect the `<BCE:Ctas>` nodes.

**Observation:**
- The generated XML uses the following attribute order: `Debe > NumCta > Haber > SaldoFin > SaldoIni`
- However, the SAT-recommended structure is: `NumCta > SaldoIni > Debe > Haber > SaldoFin`

**Root Cause:**
At [1], the attributes of the `<BCE:Ctas>` node are defined in an order 
that differs from the SAT-recommended structure. While the XML remains 
valid, the generated report does not match the layout recommended by the 
Mexican government specification.

**Fix:**
This commit reorders the `<BCE:Ctas>` attributes to follow the 
SAT-recommended structure, aligning the generated XML with 
the behavior introduced at [2] for `saas-19.3`.

backport-of: https://github.com/odoo/enterprise/pull/115374

[1]:
https://github.com/odoo/enterprise/blob/cb9c19272309d793379fa4d23145162f72fa5552/l10n_mx_reports/data/templates/cfdibalance.xml#L15-L20

[2]:
https://github.com/odoo/enterprise/blob/acf0929a88ec788aecd44f6b4c647e468dc0a319/l10n_mx_reports/data/templates/cfdibalance.xml#L17-L22

opw-6297711

Forward-Port-Of: odoo/enterprise#122469
Forward-Port-Of: odoo/enterprise#121440

### Issue:
In 19.0, the values of lines 415 and 420 in the Swiss tax report are negative, causing line 479 to add them instead of subtracting

Line 479 formula:
`tax_ch_400 + tax_ch_405 + tax_ch_410 - tax_ch_415 - tax_ch_420`
For the subtraction to be correct, 415 and 420 must be positive

### Cause:
In 18.0, each tax grid had two variants (`+415`/`-415`) allowing the user to control the sign manually
The double negative (`-*-`) incidentally produced positive values in the report

In 19.0, the unified tax grid merges them into a single tax grid (`415`) with automatic sign handling
415 and 420 are correction lines that must appear positive in the report so that 479 subtracts them correctly
The formulas were not updated to reflect this change

### Steps to reproduce:
- Install `l10n_ch_reports` and `accountant`
- Switch to `CH Company`
- Create and confirm a Bill (Amount: 100, Tax: 8.1%)
- Create and post a Journal Entry:
  - Account: 1170 Input Tax (VAT), Credit: 2, Tax Grids: 415 and 420
  - Account: 1021 Bank, Debit: 2
- Open the Tax Report for this month
 
Before the fix, lines 415 and 420 are negative and line 479 adds them instead of subtracting

opw-6311126

Forward-Port-Of: odoo/odoo#272385

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Intrastat"

- Create a product with Intrastat info
- Create a bill:
  * Product: [the created Intrastat product]
  * Intrastat Country: [any]
  * Intrastat Transport Mode: [any]
- Confirm the bill
- Make sure that the bill name contains a hyphen character (i.e. "-")
For example, "BILL/2026-06/0001".
Use the "Resequence" action from the bills list view if needed.

- Go to "Accounting / Reporting / Audit Reports / Intrastat Report"
- Expand the line to display the bill name

**Issue:**
The bill name is not fully displayed.
It is cropped right before the hyphen character (i.e. BILL/2026).

**Cause:**
A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character.

**Solution:**
Just allow "-" character in addition.
No other character is allowed to limit the risk of matching something that should not.

opw-6299854

Forward-Port-Of: odoo/enterprise#120979

### Issue:
When creating a website through the configurator and selecting the
website type 'an eCommerce', the shop feature is not preselected as
expected.

### Steps to reproduce:
- Ensure that the eCommerce module is not installed.
- Navigate to Website > Configuration > Settings.
- Click on the "New Website" button to create a new website.
- Select the "eCommerce" option as the website type and proceed to the
  next step.
- On the "Add Pages and Features" screen, observe that the "Shop" option
  is not selected by default.

### Reason:
0cb45457 renamed the website type from `online_store` to `eCommerce`,
but the related feature was not updated and still references the old
name. As a result, the preselection is not triggered.

### Fix:
Restore the eCommerce website type's internal name to `online_store` in
the configurator. This matches the value already stored in the database
for existing installations, allowing the shop feature preselection to
work for existing users as well, without requiring a data update.

task-[6284263](https://www.odoo.com/odoo/project/974/tasks/6284263)

[1]:https://github.com/odoo/odoo/pull/223724

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

### Commit 1:

[FIX] website: prevent CSRF error by blocking duplicate form submission

Before this commit: Clicking the logout button from the website
preview triggered two simultaneous logout requests:

1. The browser performed the default form submission with a valid
   `csrf_token`, destroying the session afterward.
2. During the same click event, `setupClickListener()` intercepted
   the click using `closest('[action]')`, found the parent
   `/web/session/logout` form, and triggered a second POST request
   using `odoo.csrf_token`.

Since the session was already destroyed by the first request, the
second request resulted in a "CSRF validation failed" error.

This commit prevents the default form submission before triggering
the manual POST request, ensuring that only one request is sent.

Runbot-940403

--------------------------------------------------------------------------------------------------------------------------------

### Commit 2:

[FIX] website: enable free sign up setting in test_auth_forms_warning

Steps to reproduce:
1. Install any website related module (e.g. `website`, `website_event`).
2. Keep the default configuration and do not manually enable
   'Free sign up' in Settings.
3. Run `test_auth_forms_warning`.

Before this commit: The test did not programmatically enable the
'Free sign up' setting. As a result, it failed unless a developer
manually navigated to the setting and enabled it beforehand.

After this commit: This commit explicitly enables the "Free sign up"
configuration during test execution, allowing public access to the
`/web/signup` page and ensuring the test passes without any manual
setup.

runbot-940394

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

### Summary

When `dev_mode` includes `reload`, `ThreadedServer`'s FSWatcher reacts to a file change by sending the process a `SIGHUP` to trigger a phoenix restart. `signal_handler` turns `SIGHUP` into `KeyboardInterrupt`, which `ThreadedServer.run()`'s wait-loop catches. The catch is too narrow — a reload `SIGHUP` can kill the process through **three** windows that all sit outside the wait-loop's `try/except`, so the exception escapes `run()`/`main()`. Under Docker's default `restart: no`, PID 1 dies and the container stays down.

### The three windows

1. **Teardown duplicate (exit 130).** One file change can emit several FS events; the FSWatcher's `if not odoo.phoenix:` dedup races across threads and fires more than one `SIGHUP`. The first begins the phoenix teardown; the second lands during `stop()` / `watcher.stop()` / `_reexec()` and `KeyboardInterrupt` escapes.
2. **Exec-gap (exit 129).** `os.execve()` resets caught signal handlers to their default disposition (`SIGHUP` terminates) but preserves `SIG_IGN`; a `SIGHUP` arriving after the exec but before the re-exec'd process re-installs its handler kills the process outright.
3. **Startup (exit 130).** In the re-exec'd process, a `SIGHUP` anywhere in the startup section that precedes the wait-loop — `start()`, `preload_registries()` **and** `cron_spawn()` — escapes `run()`.

### Reproducer (deterministic)

Boot a `ThreadedServer` (`--workers 0`) on any initialised db, then signal PID 1 a few times in quick succession:

```bash
docker exec <container> sh -c 'i=0; while [ $i -lt 8 ]; do kill -HUP 1; sleep 0.1; i=$((i+1)); done'
```

Unpatched the process exits 130 or 129. Patched it stays up after one clean phoenix reload. Verified live on 17.0 and 18.0: stock `server.py` dies; the patched `server.py` survives sustained bursts (20/20 across repeated reload cycles on each version); `SIGINT`/`SIGTERM` still exit 0.

### Fix

Minimal, in `signal_handler` + `run()` + `_reexec()`; `SIGINT`/`SIGTERM` untouched; one new instance attribute, no new module globals:

- **Teardown duplicate:** ignore a `SIGHUP` once `quit_signals_received` is set (a restart/shutdown is already pending; the re-exec reloads fresh code).
- **Startup:** a per-instance `in_preload` flag marks the entire startup section (`start()` + `preload_registries()` + `cron_spawn()`); a `SIGHUP` there sets the phoenix flag + counter and returns instead of raising, so the wait-loop exits right after startup and runs the normal restart.
- **Exec-gap:** `signal.signal(signal.SIGHUP, signal.SIG_IGN)` just before `os.execve` so a `SIGHUP` in the gap is dropped rather than terminating the process.

### Related

- #21209 (merged) — introduced the phoenix flag; did not guard these windows.
- #206898 (merged), #207930 (open) — PreforkServer reload.

### CLA

Covered by Codeforward B.V.'s corporate CLA; #269240 adds me to its contributor list (pending merge).

Forward-Port-Of: odoo/odoo#269247

Steps to reproduce
---
1. Install a carrier that requires a positive package shipping weight (e.g. UPS) and enable Packages.
2. From the Barcode app, process a delivery and Put in Pack the products.
3. Validate the transfer.

Issue
---
Validation is refused because the package has no positive shipping weight, even though its computed weight is correct.

The package shipping weight is only set in `_post_put_in_pack_hook` from `context['weight']`, which is filled exclusively by the put in pack wizard. Flows that bypass the wizard, like the Barcode app, never provide that key, so the stored `shipping_weight` stays 0 while carriers reading it directly reject the delivery. The Barcode app suppresses the wizard through the `barcode_view` context, so its put in pack goes straight to the hook without any weight.

https://github.com/odoo/enterprise/blob/6b18215bfa98ef636b63f4fafbba1d25264f4883/stock_barcode/models/stock_move_line.py#L193-L196

This handling was centralized in this hook by 9a2ff6f4033e, so every wizard-bypassed pack leaves the field empty. Defaulting it to the package computed weight via `_get_weight` when the context did not provide one makes the stored value correct for any carrier, independently of the flow that created the package.

https://github.com/odoo/odoo/blob/4235b48c86077bd5bceb9e817cc45b2eec8697e8/addons/stock_delivery/models/stock_move.py#L111-L115

opw-6297689

Forward-Port-Of: odoo/odoo#272510

Steps to reproduce
1. Create two customer invoices that share the same VAT tax, with a payment term granting an early payment discount.
2. Create one bank statement line whose amount equals the sum of both invoices' discounted totals.
3. From the bank reconciliation widget, select both invoices and validate in a single batch reconciliation.
4. Open Accounting > Reporting > Tax Return, switch the variant to "Group by: Account > Tax".

Issue
The cash-discount expense row shows a Net base column equal to twice the real
discount base. The Tax column is correct.

The bank-statement reconciliation paths (set_line_bank_statement_line,
set_batch_payment_bank_statement_line, _reconcile_payments) loop over each
invoice and call _apply_early_payment_discount one invoice at a time. Each
call writes one discount base line and one discount tax line on the resulting
bank entry, so when two invoices share the same tax the bank entry ends up
with two pairs carrying the same (account, partner, currency,
tax_repartition_line_id, tax_ids).

The SQL that feeds the tax report at
https://github.com/odoo/odoo/blob/d7d0efd39a65bfb6fee307b661cd2523a6b8231d/addons/account/models/account_move_line_tax_details.py#L100
matches every base line of a tax with every tax line of that tax inside the
same move. With two pairs sharing one tax that turns two rows into four, and
SUM(base_amount) doubles. The Tax column does not double because the same SQL
redistributes each tax line's recorded amount across its matched rows so the
totals still add back to the original tax.

The payment register flow does not have this problem because it calls
_get_invoice_counterpart_amls_for_early_payment_discount once with every
invoice, and that helper already collapses duplicates with the merge key at
https://github.com/odoo/odoo/blob/f3b317310b84edb073009f7d15d7fec002f3ccf0/addons/account/models/account_move.py#L5082-L5093

opw-6199906

Forward-Port-Of: odoo/enterprise#117743

**Steps to reproduce:**
- Install `stock` and `purchase` modules
- Enable `Units of Measure and Packages`  and `Storage Locations` from setting
- Create a storable product with vendor purchase UoM set to "Pack of 6"
- Create and confirm a Purchase Order with quantity 6 Units
- Open the generated receipt
- Update a move line in Detailed Operations:
  - Quantity: 1
  - UoM: Pack of 6
- Save and open the Barcode view using smart button.
- Increase quantity using "+" button by 1.
- Exit barcode view without validating and refresh the receipt

**Issue:**
After refresh, the stock move quantity becomes 1 instead of 6,
while the move line correctly shows 1 Pack of 6.

**Cause:**

https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/static/src/components/main.js#L161-L162

- Exiting the barcode view triggers `__onExit()`, which forwards
`reserved_uom_qty` and `qty_done` from move lines to
`post_barcode_process()`.
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/static/src/models/barcode_picking_model.js#L1885-L1898

This `post_barcode_process()` function triggers `_truncate_overreserved_moves()`
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/models/stock_move.py#L56-L58

- During this flow, `_truncate_overreserved_moves()` updates the stock move quantity
by taking the maximum of `qty_done` and `reserved_uom_qty`. However, it assigns
this value directly to the move without converting it into the stock move UoM.

- In this case, both values are 1 because the move line is UoM is "Pack of 6"
Logically, 1 Pack corresponds to 6 units, but since the stock move UoM is in units,
this conversion is skipped. As a result, the move quantity is incorrectly set to 1
instead of 6.

https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/models/stock_move.py#L52-L54

**Fix:**

- Convert quantities coming from barcode processing into the stock
move UoM before updating the move quantity, ensuring packaged
UoM values are preserved correctly.

----

opw-5472598

Forward-Port-Of: odoo/enterprise#116022

### Steps to reproduce:

- Have two companies: company1 and company2
- Create a producct P available in both company1 and company2
- with company1, create a kit bom for a product P
- with company2, create and confirm a sale order for 1 unit of P
- with company1, change the bom type of P from kit to manufature
#### > UserError: As long as there are some sale order lines that must be delivered/invoiced and are related to these bills of materials, you can not remove them.

### Cause of the issue:

Changing the bom type from a kit (phantom type) to a non kit will launch a call of the `_ensure_bom_is_free` in order to ensure data integrity if the kit bom was used by a relevant sale order line: https://github.com/odoo/odoo/blob/f4c76be062bec47b68ee42505d7d42fed31ac0f2/addons/sale_mrp/models/mrp_bom.py#L15-L18
https://github.com/odoo/odoo/blob/f4c76be062bec47b68ee42505d7d42fed31ac0f2/addons/sale_mrp/models/mrp_bom.py#L24-L42
However, this check does not take the company of the bom into account and in the present flow, the company of the bom is different from the company of the supposedly problematic sol.

opw-6290304

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

Forward-Port-Of: odoo/odoo#273486
Forward-Port-Of: odoo/odoo#271119

Steps to reproduce
1. Create a service product: Invoicing Policy = Prepaid/Fixed Price, Track Service = Timesheets, Unit of Measure = Days
2. Confirm a Sales Order with 2 days of that product at 800/day
3. Register 1 hour on the generated task
4. Open Timesheets > Reporting, add the "Timesheet Revenues" measure

Issue
`timesheet_revenues` in `timesheets.analysis.report` was computed per analytic line as `(SOL.price_subtotal / SOL.qty_delivered) * (unit_amount * sol_uom.factor / ts_uom.factor)` (https://github.com/odoo/odoo/blob/16f170619d9cc5fd86529a3f17e349da37607f73/addons/sale_timesheet/report/timesheets_analysis_report.py#L42-L44).

`SOL.qty_delivered` is a stored float rounded to the day UoM precision (0.01d). For 1 hour timesheeted, qty_delivered = 1/8 = 0.125d rounds to 0.13d, so the formula yields (1600 / 0.13) × (1/8) = 1538.46 instead of the correct 100. Because `qty_delivered` is recomputed each time a timesheet is added, all existing rows shift their revenue figure with every new entry.

Additionally, using `price_subtotal / qty_delivered` as the per-unit rate ignores any line discount: the rate derived from a discounted subtotal divided by a delivered quantity that differs from the ordered quantity is not the effective price per day.

For prepaid lines, the effective per-unit rate is `price_subtotal / product_uom_qty` — the ordered quantity is stable and the subtotal already reflects any discount — multiplied by the timesheet hours converted to the SO line UoM.

opw-6150555

Forward-Port-Of: odoo/odoo#272910
Forward-Port-Of: odoo/odoo#262524

In certain cases the barcode of a product could be a valid standalone 
GS1 sequence. In that case it needs to be be correctly interpreted as 
a product scan.

### Steps to reproduce:

- In the settings enable "Default GS1 Nomenclature"
- Create a storable product P with the barcode 3701762412212
- Create and confirm a  delivery for 2 units of P and set the qty to 2
- Go to the barcode app and open your delivery
- Scan 3701762412212
> The line of P is now selected with a quantity of 1/2
- Scan 3701762412212
#### > A new line is created for 1762411 units

### Cause of the issue:

According to the GS1 nomenclature, the barcode 3701762412212 matches the scan of a quantity of "1762412" units of the lot name "2". As the scan of the of the product match a pattern for the GS1 nomenclature before matching a product, its barcode data is expected to be reset by these lines:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1320-L1324
In order to bypass the GS1 parser and to add 1 unit of the product. This is what happen on the first scan. However, performing the first scan also selects the associated line and, hence on the second scan the lines just above this check do set the product to match the product of the current line:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1294-L1320
In particular, we do not bypass the result provided by the GS1 parser and add `1762412` units of the product.

opw-6175621

Forward-Port-Of: odoo/enterprise#122256
Forward-Port-Of: odoo/enterprise#120035

### Issue:
When a bank journal uses a foreign currency, reconciliation model lines with `Amount Type: From Label` (regex) could raise a constraint error or produce incorrect balances on the journal entry

### Cause:
The `balance` of the generated move line was set to the raw value extracted by the regex, without converting it from the journal currency to the company currency

This violated the sign constraint between `balance` and `amount_currency` when the exchange rate caused a mismatch, raising a `_check_amount_currency_balance_sign` error

The `amount_currency` was already correctly set
Only the `balance` conversion was missing

### Steps to reproduce:
- Install `accountant`
- Enable a foreign currency (e.g. EUR) with two rates: yesterday: ratio < 1 (e.g. 0.5), today: ratio > 1 (e.g. 2.0)
- Create a Bank journal in EUR
- Open Bank Reconciliation for that journal
- Add two transactions (one dated yesterday, one today) (Ref: "test BANK:0001690,00EUR EXP:00033,80", amount: 1656.20)
- Create a reconciliation model (3 dots > Manage Models) (name: From Label):
-- Account: 101401 Bank, Amount: BANK:0*(\d+),(\d+)
-- Account: 600000 Expenses, Amount: EXP:0*(\d+),(\d+)
- Apply the model on both transactions
Before the fix, one raised an error due to the constraint violation
- From the list view, open the Journal Entry for the other transaction
Before the fix, `balance` was not converted to company currency

opw-6292839

Forward-Port-Of: odoo/enterprise#121114

**Steps to reproduce:**
- Install Accounting

- Create an invoice:
  * Customer: Partner A
  * Total: 30.00
- Confirm the invoice
- Create a second invoice for the same customer:
  * Customer: Partner A
  * Total; 10.00
- Confirm the invoice

- From the invoice list, select both invoice
- Create payment:
  * Journal: Bank
  * Group Payments: [checked]
  * Group Payments: [checked]
  * Amount: 40.00

- Create a third invoice for another customer:
  * Customer: Partner B
  * Total: 25.00
- Confirm the invoice
- Register payment from the invoice

- Create a fourth invoice for another customer:
  * Customer: Partner C
  * Total; 40.00
- Confirm the invoice
- Register payment from the invoice

- From the payment list, select all 3 payments and create batch payment
- Validate the batch payment

- From Accounting dashboard, open Bank journal
- Create a new bank statement line of 105.00
- Match it with the batch payment

At that point, the statement line is reconciled with the 4 invoices and the 3 payments are marked as paid.

- Go to the fourth invoice
- Reset it to draft
- Change the price
- Save

When the amount of the invoice is changed, the statement line is unreconciled and all the payments should change state from "Paid" to "In Process".

**Issue:**
All the single payments have their state correctly changed to "In Process", except for the group payment for the 2 first invoices, which leads to undesired values when trying to reconcile the statement line with the batch payment again.

**Cause:**
When the statement is unreconciled, all the partial reconcile records are deleted and the state of the linked payments are updated to "In Process".
The payments are retrieved by checking if there are linked to an account move present in the partial reconcile record and if the amount of the payment matches the amount of the partial reconcile record. In case of a group payment, there are 2 partial reconcile records for each invoice linked to the payment.
Therefore, in that case, the amount doesn't match the amount of the payment because it matches the amount of one of the invoice.

opw-6141089

Forward-Port-Of: odoo/enterprise#122585
Forward-Port-Of: odoo/enterprise#120210

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Intrastat"

- Create a product with Intrastat info
- Create a bill:
  * Product: [the created Intrastat product]
  * Intrastat Country: [any]
  * Intrastat Transport Mode: [any]
- Confirm the bill
- Make sure that the bill name contains a hyphen character (i.e. "-")
For example, "BILL/2026-06/0001".
Use the "Resequence" action from the bills list view if needed.

- Go to "Accounting / Reporting / Audit Reports / Intrastat Report"
- Expand the line to display the bill name

**Issue:**
The bill name is not fully displayed.
It is cropped right before the hyphen character (i.e. BILL/2026).

**Cause:**
A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character.

**Solution:**
Just allow "-" character in addition.
No other character is allowed to limit the risk of matching something that should not.

opw-6299854

Forward-Port-Of: odoo/enterprise#120979

## Issue
When using the Timesheets systray, if we set a project after clicking the *Save* or *Reset* button, the project is not saved after closing the systray.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. Open the Timesheets systray
3. Click *Reset* and set a description, a project and/or a task, then close the systray
4. Open the systray again
5. **The description/project/task set in step 3 do(es) not appear anymore.**

## Cause
Commit https://github.com/odoo/enterprise/commit/b9b7f8a0acf7a1c545c6613cf8bbc29871632e26 introduced the `preventUnmountSave` attribute. The attribute is set to `true` after saving and discarding an entry. When the systray is unMounted, the manual values (e.g., description, project and task) are not saved if the attribute is set to `true`:

https://github.com/odoo/enterprise/blob/7cd8dd008eb88d6c12f3e65fb8d311058290a301/timesheet_grid/static/src/components/timesheet_timer_inline_form/timesheet_timer_inline_form.js#L171-L174

## Fix
After discussing with the author of the previous commit, it appears this was done to prevent an issue with values stored in cache, but that issue does not seem to occur anymore, which leads to believe that the attribute is not required anymore.

opw-6284016

Forward-Port-Of: odoo/enterprise#122332
Forward-Port-Of: odoo/enterprise#121605

Before:
- Documents flow: after signing, the signed copy was placed in the Sign folder instead of the same folder as the original document.
- HR flow: after signing a sign.request linked to an HR record (e.g. hr.employee, hr.version), the signed document appeared twice, once in the Employee/Payroll folder and again in the Sign folder.
- [_sign()](https://github.com/odoo/enterprise/blob/19.0/sign/models/sign_request.py#L505) attaches a copy of the signed document to the linked record, but the missing `no_document=True` was mistakenly creating an extra document
- Import from Documents flow: after signing via "Import from Documents" in the Sign app, the signed copy was placed in the original document folder instead of the Sign folder.

After:
- Documents flow: the signed document is now placed in the same folder as the original document.
- HR flow: the signed document is created only once, in the Employee/Payroll folder. No copy is made in the Sign folder.
- No extra documents are created in the background when a sign request linked to a record is completed.
- Import from Documents flow: the signed document is now placed in the Sign folder.

Impact:
- Signed documents from the Documents app stay in the same folder.
- Signed HR contracts appear only in the Employee/Payroll folder.
- No duplicate documents are created on completion.

Task: 6176315

[FIX] l10n_be_hr_contract_salary: fix NISS runbot error in salary config

Bug reproduction:
    1 - Get 19.4, only install hr_contract_salary and execute tour test hr_contract_salary_employee_flow_tour
    2 - When only single app is installed without installing l10n_be_hr_contract_salary, the tour test fails

Bug cause:
    1 - When the employee's company's country is belgium we were showing NISS instead of identification number.
    2 - But NISS field is appended in l10n_be_hr_contract_salary and if you do not install, there is no identification number and NISS.
    3 - That's why the test fails (it looks for identification number or NISS but none of them is there)

Bug solution:
    1 - I moved the code of hiding identification number or hiding NISS to the l10n_be_hr_contract_salary. So, when only hr_contract_salary is installed, identification number field won't get hided.

task - 6333129

runbot error link: https://runbot.odoo.com/odoo/error/941044

Forward-Port-Of: odoo/enterprise#121800

Currently on the pos payment method form, if you click "Select more" on the journal field, you will see two buttons 'New' & 'Create New'.

Steps to reproduce:
-------------------
* Open any pos payment method
* Select the journal field
* Select "Search more"
> See two creation buttons

Why the fix:
------------
One button is the standard "On search more" button which can be hidden using options such as no_create, no_create_edit, ...

The second button is defined on the list view for journals and since the search more uses the list view it shows the button as well. Currently we can do that with a context key to ensure that on the "real" list view it's still visible.

Why do we want to hide those buttons? Asked the R&D accounting team, it should not be allowed to create journals on the fly. You should only be able to create them inside accounting app.

This behavior is not limited to this view but will only be applied locally. The fix can however be applied everywhere where needed.

Before the fix:
-------------------
<img width="700" height="417" alt="image" src="https://github.com/user-attachments/assets/ca11ea13-c38e-40a1-9848-cbc5edc6226e" />
<img width="1507" height="887" alt="image" src="https://github.com/user-attachments/assets/1cde5d3b-3372-4aca-b5d0-2319bd82c1de" />

After the fix:
----------------
<img width="707" height="474" alt="image" src="https://github.com/user-attachments/assets/01dc7b42-43d6-4b18-a12d-54330d51b92b" />
<img width="1457" height="870" alt="image" src="https://github.com/user-attachments/assets/ff387d3f-f59c-47ad-abfe-a2003669db1a" />


opw-6131231

Forward-Port-Of: odoo/enterprise#120379

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

Version: 19.0

`test_sign_request_notification`, `test_gc_removes_orphan_roles_and_dummy_items` ,`test_sign_tour` and `test_sign_tour_without_sign` fail locally when you run them on a db with demo data installed, after doing some manual testing/ operations on it.

- `test_sign_request_notification` builds `completion_mail_to_user` by searching `mail.mail` for any email addressed to the admin's address. If admin had received any other email before this test ran, it got counted too, so the assertion on `len(completion_mail_to_user)` became wrong. We now also filter by subject matching `sign_request.reference`, so it only counts the email this test's own sign request actually generated.

- `test_gc_removes_orphan_roles_and_dummy_items` relies on the helper `_get_signer_and_item_gc_context` to count dummy sign items (page < 0). That helper searched `sign.item` with no domain at all, so any dummy item left behind by a different template got added to `non_active_item_ids` and broke the `len(non_active_item_ids) == 4` check. We now scope that search to `template_id = sign_template.id`, so it only counts items belonging to the template created in the test.

- `sign_tour` had a step targeting `.o-autocomplete--dropdown-item:contains('Administrator')` in the signer autocomplete. After installing demo data the admin user is named `Mitchell Admin`, so the tour failed on databases using that name. Both contain 'Admin', so the trigger now matches on that instead.

taskid- 6329037

Steps to reproduce:
-------------------------------------------
1. Install the Timesheet module with demo data
2. Go to any FSM task > set allocated hours to 20h
3. Fill the timesheet for the same task for 10h
4. Navigate to FSM > My Tasks > Gantt view

Observation:
-------------------------------------------
Look at the task on the Gantt chart. The shading is barely visible because it covers only 0.5% of the bar, not 50%

Issue:
-------------------------------------------
In the commit
https://github.com/odoo/odoo/pull/137570/changes/4a93d9aee957dd3feb3db0cb69eb3b8f0f4a4683 The progress field computation was changed from storing percentage values (0-100) to storing decimal values (0-1). Specifically, the `_compute_progress_hours` method was modified. This change was made to standardize the progress field storage format, with the understanding that the UI layer would multiply by 100 when displaying the value. While most views (form, list, kanban, etc.) were updated to multiply the progress by 100 for display purposes, the Gantt view's pill progress bar was missed.

Solution:
-------------------------------------------
Overrides the `enrichPill` method to multiply the `_progress` value by 100 before it's passed to the template. This ensures the Gantt pill progress bars display correctly without modifying the core web_gantt module.

Before
---------------------------
<img width="268" height="368" alt="image" src="https://github.com/user-attachments/assets/6d35927f-bd3f-47fc-9101-e2e188d419b8" />


After:
--------------------------
<img width="250" height="371" alt="image" src="https://github.com/user-attachments/assets/fe7133e0-26d1-4c5f-b903-48826fda9488" />


opw-6038983

**Steps to reproduce:**

- Make a product with a category
- In the category, make the inventory valuation to automated
- Set the income and expense account
- Set a cost for the product
- Make a fiscal position and set it as default for the PoS
- In the Account Mapping tab, map the income and expense to two other accounts
- Go to the PoS
- Make a sale for that product, without invoice
- Close the session and in the backend check the session
- Check the journal entries
- The income account has been mapped to the fiscal position's
- The outcome account stayed the same as in the category's

**Why the fix:**

When we invoice an order, the income and expense accounts are immediately updated, in a different place than if it has not been invoiced.

At the session's closure, we update the accounts for every order that hasn't been invoiced. In this flow, the account mapping defined on the fiscal position was not applied, so we took the one defined on the product's category.
The income account was already mapped as we need to do it earlier than the session closure, so it had already been set as the right one before our flow. For the expense account, we only need it at this specific time, so we can map it as the session's closure.

We now map the account depending on the fiscal position if we are able to find one, otherwise, we use the category's default as we did before.

opw-6171677

### Issue before this commit:
When reversing an invoice with a credit note in the l10n_cz and l10n_sk only the invoice_date is updated with the reversal_date but not the TSD date.

### Steps to reproduce the issue:
1. Download Accounting and l10n_cz (same steps can be done for l10n_sk)
2. Go to invoices and put as not invisible the Accounting Date field
3. Create and post the invoice setting as Taxable Supply Date (TSD) a previous date
4. Create a credit note for the invoice with reversal date as today for example and then click Reverse
5. See the dates (as taxable supply date and accounting date) are not updated

### Cause of the issue:
Prior to version 19, the taxable_supply_date (TSD) was a localization-specific field and did not exist in the core account.move model. Consequently, when the reverse_moves method:
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/account/wizard/account_move_reversal.py#L110-L174
executed, the accounting date was recomputed but the TSD was left unhandled. Thanks to PR https://github.com/odoo/odoo/pull/225035, which natively integrates this field into the core account module in version 19, the fields are now properly aligned and the issue is no longer reproducible.

### Reason to introduce the fix:
The fix explicitly populates taxable_supply_date with the wizard's reverse_date during the reversal preparation process.

opw-6102869

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

Currently when the user reverts an inventory adjustment move line with a package the package contains extra line showing negative quantity of the product.

## Steps to produce:
- Install Inventory without demo data
- Settings Enable 'Packages'
- Create a product:
   - Cheese burger
   - On hand > Create a new quant
   - Package: 'Burgerbox' and 'On Hand Quantity`: 1 and save
- Set the On Hand quantity to zero and save
- History > Revert the Inventory adjustment line from WH/stock to Inventory adjustment by selecting it and reverting via actions.
- Products > Packages > BurgerBox

## Observed Behaviour:
After reverting an inventory adjustment that set the product's physical quantity to 0, the package contains two lines for the same product with quantities 1 and -1.

This is inconsistent because a package should not contain a product with a negative quantity.

The package should be restored to its original state and contain only the expected positive quantity.

## Root cause:
When the user reverts the move line, `action_revert_inventory` is called. This method creates the revert move and then marks that move as done at [1].

Marking the move as done subsequently marks all related move lines as done at [2]. During this process, the system first unreserves the quantity from the virtual location / inventory adjustment and then removes the quantity from that location (resulting in a -1 quantity move line at that location). This is performed through `_synchronize_quant`, which is responsible for synchronizing the physical inventory with the move line at [3].

The `_synchronize_quant` method uses the move line's `package_id` when updating the corresponding quant at [4]. As a result, `_update_available_quantity` creates a new quant with the following values at [5]:
```
{
    'product_id': 1,
    'location_id': 14,
    'lot_id': stock.lot(),
    'package_id': 1,
    'owner_id': res.partner(),
    'in_date': datetime.datetime(2026, 6, 22, 12, 42, 11),
    'quantity': -1.0,
}
```
This creates a quant with a negative quantity that is linked to the package because `package_id` is set on the newly created quant. Consequently, the move line with the negative quantity becomes associated with the package.

[1]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move_line.py#L1016-L1035 
[2]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move.py#L1956 [3]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move_line.py#L662-L666 
[4]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_move_line.py#L678-L687 
[5]-
https://github.com/odoo/odoo/blob/333c279be7cba9fda17d2818be36f4d96d8cd0f6/addons/stock/models/stock_quant.py#L1130-L1143
## Solution:
Remove the source `package_id` when creating revert moves for inventory adjustment locations.

When an inventory adjustment sets a product's quantity to 0, the adjustment is completed without a destination package, meaning the product is effectively removed from the package. Therefore, the corresponding revert move should not retain the package as its source. Keeping the package as the source is inconsistent because package information should not exist on a virtual inventory adjustment location, and the original inventory adjustment removes the product from the package (there is no destination package).

By removing the source `package_id` from the revert move, the system avoids creating negative quants associated with the package during quant synchronization. This also ensures that, after the inventory adjustment is reverted, the quantities of products inside the package are restored correctly and match their state prior to the adjustment.

opw-6285739

Forward-Port-Of: odoo/odoo#271440

Example of steps:
- Install web_studio and `accountant`
- Open the corresponding form view in Studio
- With debug mode toggle "Show invisible Elements" and edit "Invisible" on the second partner_id field
- Traceback

`normalize()` compares the combined arch without the studio customization to the one with it, in order to compute the smallest possible set of xpaths. To do so, it calls `apply_inheritance_specs` (the low-level function from `odoo.tools.template_inheritance`) directly on the statically combined arch.

Some models add or duplicate nodes dynamically in `_get_view()` (Python postprocessing, run after the static view combination). A studio operation can target such a node, since it is what the user actually sees and clicks on. But that node has no counterpart in the purely static combined arch used by `normalize()`, so `apply_inheritance_specs` raises a ValueError.

`edit_view()` only catches `ValidationError` to fall back to an un-optimized (but valid) studio arch instead of failing the request. Since the low-level function raises a plain `ValueError` here, that fallback never triggers, and the exception is not caught anywhere.

To fix this, we will keep the behavior from version 18.0 and catch the
ValueError raised by `apply_inheritance_specs` in `normalize_with_keyed_tree` and re-raise it as a ValidationError, like `ir.ui.view.apply_inheritance_specs` already does elsewhere. This lets `edit_view()`'s existing fallback handle the case gracefully instead of crashing.

opw-6332911

Steps to reproduce:
----------------------------------------
1. Install `industry_fsm_sale` and `base_automation` modules
2. Create a product with:
    * Type: Service
    * Create on order: Task
    * Project: Field Service
3. Create an automation rule with:
    * Model: Sales order
    * Trigger: Incoming message
4. Create and confirm a sale order with this product
5. Add another product to the SO via the catalog view:
    * Change the quantity to 2 or more

Observation:
----------------------------------------
Traceback occurs:
```
  File '/home/odoo/src/odoo/addons/base_automation/models/base_automation.py', line 871, in _message_post
    message_sudo = message.sudo().with_context(active_test=False)
AttributeError: 'bool' object has no attribute 'sudo'
```

Root Cause:
----------------------------------------
* Catalog qty change calls `set_fsm_quantity()` method
* Setting `fsm_quantity` triggers its inverse `_inverse_fsm_quantity()`, which writes the new qty to the SOL, but passes `fsm_no_message_post=True` in context to suppress chatter noise
https://github.com/odoo/enterprise/blob/ac5d670832a5e0db714c0bd056e1406b50bb4c17/industry_fsm_sale/models/product_product.py#L72-L83
* `sale.order.line.write()` detects a qty change on a confirmed order and calls `_update_line_quantity()`, which posts a message on the parent sale order
* FSM's `message_post` override sees the context flag and returns `False`
* When `base_automation` has an `on_message_received` rule on `sale.order`, it wraps `message_post` at registry load time. That wrapper calls `sudo()` on whatever `message_post` returns, Which was `False`

Solution:
----------------------------------------
Return `self.env['mail.message']` (empty recordset) instead of False, it's still falsy, but it's a proper ORM object that `sudo()` can be called on

opw-6276916