Issue
--------------
When refreshing checks on account returns (e.g. from rapid successive clicks or component re-renders), multiple concurrent RPC calls to `refresh_checks` were being dispatched to the server. This created a race condition that resulted in duplicate `account.return.check` records being generated in the database.

steps to reproduce demonstrated in video: https://drive.google.com/file/d/1-A0ZHdYGdv-UL0dqClqK6Kos_iVXoZai/view?usp=sharing

When this happen the `runAllReturnChecks` method fires parallel RPC calls to [`refresh_checks`](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1974-L1992) on the server. In the case of instant multiple RPC calls, parallel threads are dispatched which causes the data preparation stage to run simultaneously.


Because both threads run in parallel, Thread 2 runs its [preparation and existing ](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1986-L1987 )check mechanism before Thread 1 has reached the actual `create()` function [trigger](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1998-L1999).  Consequently, Thread 2's existence check fails to find the record (since Thread 1 hasn't committed it to the database yet), and it considers the record eligible for creation—even though the exact same record is already prepared for creation by Thread 1. This race condition leads to duplicate `account.return.check` records.

   
   
 Logs to demonstrate the thread execution:
--------

```python
2026-04-16 08:30:51,493 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.000 0.002
2026-04-16 08:30:51,662 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "POST /web/dataset/call_kw/account.report/dispatch_report_action#account.report.dispatch_report_action HTTP/1.0" 200 - 17 0.006 0.012
2026-04-16 08:30:51,847 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "POST /web/dataset/call_kw/account.return/get_views#account.return.get_views HTTP/1.0" 200 - 26 0.009 0.025
2026-04-16 08:30:52,099 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:52] "POST /web/dataset/call_kw/account.return/web_read_group#account.return.web_read_group HTTP/1.0" 200 - 95 0.029 0.064
2026-04-16 08:30:52,320 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:52] "POST /web/dataset/call_kw/account.return/get_next_returns_ids#account.return.get_next_returns_ids HTTP/1.0" 200 - 2 0.001 0.004
                 THREAD NAME: odoo.service.http.request.137360481711808 Thread ID:  137360481711808
                 REFRESH CHECK START:--------------------------------------------
                 Thread ID:   137360481711808 -------------DATA PREPARING STAGE------------
                 Thread ID:   137360481711808
                 Thread ID:   137360481711808     RECORD EXISTING CHECK:  None
2026-04-16 08:30:53,842 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:53] "GET /odoo/tax-report/tax-return?debug=1 HTTP/1.0" 200 - 29 0.020 0.021
2026-04-16 08:30:54,066 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/webclient/load_menus HTTP/1.0" 200 - 4 0.002 0.009
2026-04-16 08:30:54,351 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/manifest.webmanifest HTTP/1.0" 200 - 6 0.003 0.005
2026-04-16 08:30:54,493 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/webclient/translations?hash=bb5aa713d587cc7dd07b13d1d7efc2c525517e99&lang=en_US HTTP/1.0" 200 - 1 0.000 0.002
2026-04-16 08:30:54,586 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/bundle/web_tour.interactive?lang=en_US&debug=1 HTTP/1.0" 200 - 1 0.001 0.003
2026-04-16 08:30:54,640 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/action/load_breadcrumbs HTTP/1.0" 200 - 7 0.003 0.006
2026-04-16 08:30:54,710 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/ir.http/lazy_session_info#ir.http.lazy_session_info HTTP/1.0" 200 - 2 0.001 0.004
2026-04-16 08:30:54,753 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /bus/websocket_worker_bundle?v=19.0-2 HTTP/1.0" 304 - 3 0.004 0.006
2026-04-16 08:30:54,766 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/image?model=res.users&field=avatar_128&id=2 HTTP/1.0" 304 - 9 0.012 0.013
2026-04-16 08:30:54,777 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /mail/data HTTP/1.0" 200 - 34 0.034 0.020
2026-04-16 08:30:54,824 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/account.return/get_views#account.return.get_views HTTP/1.0" 200 - 3 0.001 0.010
2026-04-16 08:30:54,934 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/account.return/web_read_group#account.return.web_read_group HTTP/1.0" 200 - 88 0.029 0.051
2026-04-16 08:30:55,107 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:55] "POST /web/dataset/call_kw/account.return/get_next_returns_ids#account.return.get_next_returns_ids HTTP/1.0" 200 - 2 0.001 0.005
                 THREAD NAME: odoo.service.http.request.137360513177280 Thread ID:  137360513177280
                 REFRESH CHECK START:--------------------------------------------
                 Thread ID:   137360513177280 -------------DATA PREPARING STAGE------------
                 Thread ID:   137360513177280
                 Thread ID:   137360513177280     RECORD EXISTING CHECK:  None
2026-04-16 08:30:55,589 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:55] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.001 0.006
2026-04-16 08:30:56,702 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:56] "GET /web/service-worker.js HTTP/1.0" 200 - 1 0.000 0.003
2026-04-16 08:30:58,893 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:58] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.006 0.023
2026-04-16 08:31:05,296 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:31:05] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.001 0.002
                 Thread ID:   137360481711808     DATA to_create:  168
                 Thread ID:   137360481711808 done process create  
2026-04-16 08:31:10,132 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:31:10] "POST /web/dataset/call_kw/account.return/refresh_checks#account.return.refresh_checks HTTP/1.0" 200 - 513 11.611 6.039
                 Thread ID:   137360513177280     DATA to_create:  168
                 Thread ID:   137360513177280 done process create 

```

- OPW: 5917459

Forward-Port-Of: odoo/enterprise#114045

When the network drops after eTIMS processes a transaction but before Odoo receives the confirmation, Odoo would retry with the same invoice number, causing eTIMS error 924 (Invoice number already exists).

For POS orders, the old code decremented the sequence on any error (including timeout), so the next retry consumed the same invcNo. If eTIMS had already recorded the original send, the retry was rejected with 924. Fix by introducing a fetch-first strategy: on retry, if a pending invcNo is found in l10n_ke_order_json, call selectInvoiceDetails before sending. If eTIMS already has the invoice, recover the receipt data directly without resending. If eTIMS does not have it, resend with the same invcNo safely. On timeout errors, the sequence is no longer decremented so the invcNo is preserved in l10n_ke_order_json for the next idempotent retry.

For customer invoices, the existing fetch-first logic only bailed out on TIM (timeout) errors, falling through on CON (connection) errors and retrying blindly. Additionally, if saveTrnsSalesOsdc returned 924, there was no recovery path and the invoice number would be cleared. Fix by also bailing on CON in the fetch block, and adding an explicit 924 handler that calls selectInvoiceDetails to recover the existing receipt instead of failing.

opw-6105693

Forward-Port-Of: odoo/enterprise#115649

**Steps to reproduce:**
- Create a new marketing campaign with two activities
- Set them to occur some number of days after the beginning
- Save the campaign and start it
- Modify one of the activities to occur some number of days after the
other activity and save
- Modify the child activity by changing the number of days after its
parent that it should run and save
- An error will be thrown

**Issue:**
The trace related to the child activity has no parent when trying to reschedule it in `_update_schedule_date`. This causes an issue when trying to get the first mailing_trace_ids using index 0 in this line:
`base_dt_str = trace.parent_id.schedule_date or trace.parent_id.mailing_trace_ids[0].write_date or trace.participant_id.create_date`

**Fix:**
Prevent the activity hierarchy to be modified on started campaigns.
We also change the indexing to avoid further out of range issue and
properly default on the participant create value.

Trying to match existing traces to their parents has too many edge cases when trying to avoid duplicates, and might often need to reset the whole trace chain to work properly. This approach avoids user mistakes on running
campaigns, but if a user tries to launch a test (even on draft campaign) he won't be able to modify the hierarchy further without deleting/recreating some activities/traces. So we should ignore this for test traces, but it could
impact the behavior between test and actual executions.

opw-5362978

Forward-Port-Of: odoo/enterprise#107556

Issue:
----------------------------------------
When having an employee with `l10n_us_filing_status` not in `['single', 'jointly']` and evaluating the rule parameter `l10n_us_qualified_overtime_deduction_cap` an error occurs.

Cause:
----------------------------------------
`l10n_us_filing_status` can have 5 values: `['single', 'jointly', 'separately', 'head', 'survivor']` But only `['single', 'jointly']` are defined for `l10n_us_qualified_overtime_deduction_cap` ([src](https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/l10n_us_hr_payroll/data/hr_rule_parameters_data.xml#L48)).

When running the rule "Qualified Overtime", the custom Python crashes because we read a key that is not there:

https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/l10n_us_hr_payroll/data/hr_salary_rule_data.xml#L56

Solution:
----------------------------------------
In the custom Python condition, we first check if the key is there.

The custom Python computation also tries to read the key, but it is run only if the condition is validated. So we don't need to change it.

Also fixed indentation of test 069.

opw-6129657

Forward-Port-Of: odoo/enterprise#116913
Forward-Port-Of: odoo/enterprise#115754

## Issue
When generating a DMFA report with a working schedule with more or less than 5 days a week, the *Days Per Week* value in the report is still appearing as 5.

## Steps to reproduce
1. Install *Belgium - Payroll* (`l10n_be_hr_payroll`)
2. In Payroll's Settings:
    - set *ONSS Registration Number* to `0830123456`
    - set *DMFA Employer Class* to `083`
    - create a *Work Address DMFA code* (any name, any numeral code, but set the *Working Address* to the Belgian company used for the rest of the steps)
3. In Employees' Settings, set the *Company Working Hours* to a new Working Schedule, with 9 hours/day, 4 days/week. E.g from Monday to Thursday included:
    - Work from 8:00 to 12:00
    - Lunch from 12:00 to 13:00
    - Work from 13:00 to 18:00
4. Create an Employee E for the Belgian company:
    - In the *Payroll* tab, set the start date of the contract to 01/01/2026.
    - In the *Personal* tab, set the *NISS Number* to `85073003328`
5. Create the payslip for January 2026 for the Employee E.
6. In Payroll > Reporting > Belgium > DMFA, create a new DMFA for the first quarter of 2026 and generate the PDF report
7. **In the generated PDF report, the _Days per Week_ line is set to 5.**

## Cause
The number of days was calculated by multiplying `5` with the `work_time_rate` of the related calendar. This is inaccurate in the case of a company where employees are only expected to work 4 days a week.

opw-6103934

Forward-Port-Of: odoo/enterprise#116963
Forward-Port-Of: odoo/enterprise#113804

Steps to Reproduce (Fresh Database):
--------------------------------------
1. Install `Manufacturing` (mrp) and `PLM` (mrp_plm) modules
2. Create a product > New -- Name: "Test Product" > Save
3. Create BoM v1
   - Go to Manufacturing > Products > Bills of Materials > New --Product: Test Product
   - Add component: any
4. Create and apply ECO 1 on BoM v1
   - Go to PLM > ECOs > New-- Product: Test Product | Apply on: Bill of Materials
   - BoM: Test Product (v1) > Confirm > Apply Changes
   - This creates BoM v2 (previous_bom_id = BoM v1)
5. Create and apply ECO 2 on BoM v2
   - Same as step 4 but select BoM v2
   - This creates BoM v3 (previous_bom_id = BoM v2)
6. Create a separate unrelated BoM for the same product
   - Go to Manufacturing > Bills of Materials > New
   - Product: Test Product | Component: "Component B" > Save
7. Create ECO 3 on the separate BoM
   - Go to PLM > ECOs > New - Product: Test Product | Apply on: Bill of Materials
   - BoM: select the separate BoM from step 6 > Confirm

Observed Bug:
-------------
- Open BoM v3 > ECO(s) stat button shows count = 2
- Click the button > opens 3 records (ECO 3 incorrectly included)

Explain:- 
----------
The ECO stat button on the BoM form was showing a mismatched count vs
the actual records opened when clicking it. This happened because
[button_mrp_eco](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L56) was using all keys from [_get_previous_boms](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L67)() as the
domain, which includes BoMs from unrelated lineages of the same product
template, while [_compute_eco_data](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L20) only counts ECOs belonging to the
current BoM's version lineage.

Fixed by filtering the domain to only include BoM IDs whose lineage set
contains the current BoM ID, making the opened records consistent with
the displayed count.

Before Fix
<img width="1901" height="875" alt="image" src="https://github.com/user-attachments/assets/3208aed5-ebd3-47a3-a457-a7d61b7743cb" />

```
In [24]: labo = self.env['mrp.bom'].browse(710)
In [25]: previous_boms_mapping = labo._get_previous_boms()
In [26]: Test = ['&', ('bom_id', 'in', list(previous_boms_mapping.keys())), ('type', '=', 'bom')]
In [27]: Test
Out[27]:
['&',
 ('bom_id',
  'in',
  [710,
   1991,
   2049,
   1913,
   1840,
   1823,
   1676,
   1759,
   1794,
   1651,
   1604,
   1544,
   1537,
   1527,
   1506,
   1460,
   1265,
   1259,
   1196,
   1221,
   1223,
   1060,
   1029,
   960,
   858,
   850,
   791,
   739,
   723,
   698]),
 ('type', '=', 'bom')]
```

With My Fix
<img width="1824" height="947" alt="image" src="https://github.com/user-attachments/assets/0d68fdbc-7e42-4ce4-a326-2fb030ba1d06" />

```
In [15]: labo = self.env['mrp.bom'].browse(710)
In [16]: previous_boms_mapping = labo._get_previous_boms()
In [17]: previous_boms_mapping
Out[17]:
{710: {710},
 1991: set(),
 2049: set(),
 1913: set(),
 1840: set(),
 1823: set(),
 1676: set(),
 1759: set(),
 1794: set(),
 1651: set(),
 1604: set(),
 1544: set(),
 1537: set(),
 1527: set(),
 1506: set(),
 1460: set(),
 1265: set(),
 1259: set(),
 1196: set(),
 1221: set(),
 1223: set(),
 1060: set(),
 1029: set(),
 960: set(),
 858: set(),
 850: set(),
 791: set(),
 739: set(),
 723: set(),
 698: {710}}
In [18]: relevant_bom_ids = [
    ...:     bom_id
    ...:     for bom_id, current_bom_set in previous_boms_mapping.items()
    ...:     if labo.id in current_bom_set
    ...: ]
In [19]: relevant_bom_ids
Out[19]: [710, 698]
```

Task-6065020

Forward-Port-Of: odoo/enterprise#114039

Issue
--------------
When refreshing checks on account returns (e.g. from rapid successive clicks or component re-renders), multiple concurrent RPC calls to `refresh_checks` were being dispatched to the server. This created a race condition that resulted in duplicate `account.return.check` records being generated in the database.

steps to reproduce demonstrated in video: https://drive.google.com/file/d/1-A0ZHdYGdv-UL0dqClqK6Kos_iVXoZai/view?usp=sharing

When this happen the `runAllReturnChecks` method fires parallel RPC calls to [`refresh_checks`](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1974-L1992) on the server. In the case of instant multiple RPC calls, parallel threads are dispatched which causes the data preparation stage to run simultaneously.


Because both threads run in parallel, Thread 2 runs its [preparation and existing ](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1986-L1987 )check mechanism before Thread 1 has reached the actual `create()` function [trigger](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1998-L1999).  Consequently, Thread 2's existence check fails to find the record (since Thread 1 hasn't committed it to the database yet), and it considers the record eligible for creation—even though the exact same record is already prepared for creation by Thread 1. This race condition leads to duplicate `account.return.check` records.

   
   
 Logs to demonstrate the thread execution:
--------

```python
2026-04-16 08:30:51,493 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.000 0.002
2026-04-16 08:30:51,662 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "POST /web/dataset/call_kw/account.report/dispatch_report_action#account.report.dispatch_report_action HTTP/1.0" 200 - 17 0.006 0.012
2026-04-16 08:30:51,847 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "POST /web/dataset/call_kw/account.return/get_views#account.return.get_views HTTP/1.0" 200 - 26 0.009 0.025
2026-04-16 08:30:52,099 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:52] "POST /web/dataset/call_kw/account.return/web_read_group#account.return.web_read_group HTTP/1.0" 200 - 95 0.029 0.064
2026-04-16 08:30:52,320 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:52] "POST /web/dataset/call_kw/account.return/get_next_returns_ids#account.return.get_next_returns_ids HTTP/1.0" 200 - 2 0.001 0.004
                 THREAD NAME: odoo.service.http.request.137360481711808 Thread ID:  137360481711808
                 REFRESH CHECK START:--------------------------------------------
                 Thread ID:   137360481711808 -------------DATA PREPARING STAGE------------
                 Thread ID:   137360481711808
                 Thread ID:   137360481711808     RECORD EXISTING CHECK:  None
2026-04-16 08:30:53,842 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:53] "GET /odoo/tax-report/tax-return?debug=1 HTTP/1.0" 200 - 29 0.020 0.021
2026-04-16 08:30:54,066 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/webclient/load_menus HTTP/1.0" 200 - 4 0.002 0.009
2026-04-16 08:30:54,351 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/manifest.webmanifest HTTP/1.0" 200 - 6 0.003 0.005
2026-04-16 08:30:54,493 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/webclient/translations?hash=bb5aa713d587cc7dd07b13d1d7efc2c525517e99&lang=en_US HTTP/1.0" 200 - 1 0.000 0.002
2026-04-16 08:30:54,586 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/bundle/web_tour.interactive?lang=en_US&debug=1 HTTP/1.0" 200 - 1 0.001 0.003
2026-04-16 08:30:54,640 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/action/load_breadcrumbs HTTP/1.0" 200 - 7 0.003 0.006
2026-04-16 08:30:54,710 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/ir.http/lazy_session_info#ir.http.lazy_session_info HTTP/1.0" 200 - 2 0.001 0.004
2026-04-16 08:30:54,753 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /bus/websocket_worker_bundle?v=19.0-2 HTTP/1.0" 304 - 3 0.004 0.006
2026-04-16 08:30:54,766 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/image?model=res.users&field=avatar_128&id=2 HTTP/1.0" 304 - 9 0.012 0.013
2026-04-16 08:30:54,777 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /mail/data HTTP/1.0" 200 - 34 0.034 0.020
2026-04-16 08:30:54,824 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/account.return/get_views#account.return.get_views HTTP/1.0" 200 - 3 0.001 0.010
2026-04-16 08:30:54,934 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/account.return/web_read_group#account.return.web_read_group HTTP/1.0" 200 - 88 0.029 0.051
2026-04-16 08:30:55,107 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:55] "POST /web/dataset/call_kw/account.return/get_next_returns_ids#account.return.get_next_returns_ids HTTP/1.0" 200 - 2 0.001 0.005
                 THREAD NAME: odoo.service.http.request.137360513177280 Thread ID:  137360513177280
                 REFRESH CHECK START:--------------------------------------------
                 Thread ID:   137360513177280 -------------DATA PREPARING STAGE------------
                 Thread ID:   137360513177280
                 Thread ID:   137360513177280     RECORD EXISTING CHECK:  None
2026-04-16 08:30:55,589 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:55] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.001 0.006
2026-04-16 08:30:56,702 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:56] "GET /web/service-worker.js HTTP/1.0" 200 - 1 0.000 0.003
2026-04-16 08:30:58,893 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:58] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.006 0.023
2026-04-16 08:31:05,296 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:31:05] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.001 0.002
                 Thread ID:   137360481711808     DATA to_create:  168
                 Thread ID:   137360481711808 done process create  
2026-04-16 08:31:10,132 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:31:10] "POST /web/dataset/call_kw/account.return/refresh_checks#account.return.refresh_checks HTTP/1.0" 200 - 513 11.611 6.039
                 Thread ID:   137360513177280     DATA to_create:  168
                 Thread ID:   137360513177280 done process create 

```

- OPW: 5917459

Forward-Port-Of: odoo/enterprise#114045

During the work entry apocalypse, the gantt view that was used to do the
exports for Partena, Acerta etc was removed. With it, we lost the
ability to trigger those reports, which we want to reintroduce here. To
do so we create a dropdown element in the cog menu registry, which
starts out empty but is populated with the various reports based on
which modules are isntalled, by inheriting and adding the relative
dropdown items.

At the same time, currently the cogmenu of the employee when hr_presence
is installed is being overridden to use HrPresenceCogMenu which adds a
Dropdown of its own that includes actions related to employee presence.
Therefore, we need to refactor this dropdown becuase depending on the
module installation order the HrPresenceCogMenu might override the
addition of the ExportCogMenu and overriding the CogMenu is not the
correct way to add elements to it in general.

I have been able to move the logic of the PresenceCogMenu to the
registry but the actions don't have the correct context and give errors
because the records are not passed. Also there are some problems with
the ActionMenu (the one that shows up if you select employees from the
lsit view.

Task: 5985900

During the work entry apocalypse, the gantt view that was used to do the
exports for Partena, Acerta etc was removed. With it, we lost the
ability to trigger those reports, which we want to reintroduce here. To
do so we create a dropdown element in the cog menu registry, which
starts out empty but is populated with the various reports based on
which modules are isntalled, by inheriting and adding the relative
dropdown items.

At the same time, currently the cogmenu of the employee when hr_presence
is installed is being overridden to use HrPresenceCogMenu which adds a
Dropdown of its own that includes actions related to employee presence.
Therefore, we need to refactor this dropdown becuase depending on the
module installation order the HrPresenceCogMenu might override the
addition of the ExportCogMenu and overriding the CogMenu is not the
correct way to add elements to it in general.

I have been able to move the logic of the PresenceCogMenu to the
registry but the actions don't have the correct context and give errors
because the records are not passed. Also there are some problems with
the ActionMenu (the one that shows up if you select employees from the
lsit view.

Task: 5985900

Issue
-----
When there are 2 lines for a single product and different packaging uoms, scanning a packaging barcode alternates between lines.

Steps to reproduce
-----
- Enable packagings
- Create a product AAA
	- barcode 1
- Create a packaging 6-Pack
	- 6 units
	- barcode for AAA set to 6
- Create a PO
	- one line for 30 units of AAA
	- one line for 5 6-Pack of AAA
- Confirm PO and open picking in barcode
- Scan "6" multiple times

> Quantity increases on both lines, alternating for each scan

Cause
-----
Both lines can be found as matching lines when doing

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

The reason it alternates between the lines is because we set the currently selected line first in the array - and since both lines match, the `foundLine` returned ends up being the non-selected line.

https://github.com/odoo/enterprise/blob/d279632db25713dd639a51385cad197dfdbd2bdc/stock_barcode/static/src/models/barcode_model.js#L1823-L1832

We can avoid this y refining the `break` condition of the loop to also match the packaging uom.

-----
Ticket:
opw-6034572

Forward-Port-Of: odoo/enterprise#112578

When the network drops after eTIMS processes a transaction but before Odoo receives the confirmation, Odoo would retry with the same invoice number, causing eTIMS error 924 (Invoice number already exists).

For POS orders, the old code decremented the sequence on any error (including timeout), so the next retry consumed the same invcNo. If eTIMS had already recorded the original send, the retry was rejected with 924. Fix by introducing a fetch-first strategy: on retry, if a pending invcNo is found in l10n_ke_order_json, call selectInvoiceDetails before sending. If eTIMS already has the invoice, recover the receipt data directly without resending. If eTIMS does not have it, resend with the same invcNo safely. On timeout errors, the sequence is no longer decremented so the invcNo is preserved in l10n_ke_order_json for the next idempotent retry.

For customer invoices, the existing fetch-first logic only bailed out on TIM (timeout) errors, falling through on CON (connection) errors and retrying blindly. Additionally, if saveTrnsSalesOsdc returned 924, there was no recovery path and the invoice number would be cleared. Fix by also bailing on CON in the fetch block, and adding an explicit 924 handler that calls selectInvoiceDetails to recover the existing receipt instead of failing.

opw-6105693

Forward-Port-Of: odoo/enterprise#115649

**Steps to reproduce:**
- Create a new marketing campaign with two activities
- Set them to occur some number of days after the beginning
- Save the campaign and start it
- Modify one of the activities to occur some number of days after the
other activity and save
- Modify the child activity by changing the number of days after its
parent that it should run and save
- An error will be thrown

**Issue:**
The trace related to the child activity has no parent when trying to reschedule it in `_update_schedule_date`. This causes an issue when trying to get the first mailing_trace_ids using index 0 in this line:
`base_dt_str = trace.parent_id.schedule_date or trace.parent_id.mailing_trace_ids[0].write_date or trace.participant_id.create_date`

**Fix:**
Prevent the activity hierarchy to be modified on started campaigns.
We also change the indexing to avoid further out of range issue and
properly default on the participant create value.

Trying to match existing traces to their parents has too many edge cases when trying to avoid duplicates, and might often need to reset the whole trace chain to work properly. This approach avoids user mistakes on running
campaigns, but if a user tries to launch a test (even on draft campaign) he won't be able to modify the hierarchy further without deleting/recreating some activities/traces. So we should ignore this for test traces, but it could
impact the behavior between test and actual executions.

opw-5362978

Forward-Port-Of: odoo/enterprise#107556

__

## Short functional explanation of the error
When for an employee with a Flexible schedule, we set a shift overlapping on two days. The attendance report displays twice the worked hours.

## Reproduction Steps
1. Create an employee with a flexible schedule and with Work Entry Source set at Planning.
2. Go to Planning. Create a Planning Slot for this employee from 9 pm to 5 am, then Send and Publish it.
3. Click on the Reporting tab > Planning / Attendance Analysis.

### Expected behavior
The total for this Month for this employee under the Planned Time field should be equal to 8 hours, which is the duration of the planning slot.

### Unexpected behavior
The total for this Month for this employee under the Planned Time field is equal to 16 hours.

## Origin of the issue
This report is a view, for which the SQL is defined starting this line: https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/planning_attendance/report/planning_attendance_analysis_report.py#L27 the issue stems from here:
https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/planning_attendance/report/planning_attendance_analysis_report.py#L56 where we don't select distinct the planning entries based on their ID. As our shift overlaps 2 days, there will be only one entry for this shift in the `planning_slot`, but because of that, it will be duplicated.

__
opw-6146052

Forward-Port-Of: odoo/enterprise#115447

## Issues
When starting a timer from a task within a project, the timer appears in two locations: the page header, and the task's *Timesheets* tab. The latter does not behave as expected: when opening the *Timesheets* tab,
the timer resets to 00:00, and if the timer was started more than a minute earlier, it begins counting down (00:00, then -00:59, and so on). (**I1**)

A second issue (**I2**), introduced at the same time, is that two timers can run simultaneously if the database is reloaded while a timer is active.

A third issue (**I3**) happens after starting and stopping a timer from the Project app: the timer seems to still be running in the Timesheet app.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. Create a Project P and a Task T
3. Start the timer for Task T, wait a few seconds, then open the *Timesheets* tab
4. **The timer from the _Timesheets_ tab does not match the one on top of the page**
5. Wait for the timer in the header to reach 00:01:00, then open the *Timesheets* tab again
6. **The timer is going backward**

For the second issue (**I2**), after executing the steps above:
7. Do not stop the timer, but stop the database and start it again
8. Create a new Project P2 and a Task T2
9. Start the timer for Task T2
10. **The timer in the header blinks between the timer from T1 and the newly started timer for T2**

![5879176](https://github.com/user-attachments/assets/d9be8b8c-8973-4790-80a5-6f291f0b766a)

For the third issue (**I3**):
1. In the project app, (create a project and a task and) start then stop a timer. Log the time
2. Open the timesheet app
3. **A timer is running**

## Cause
The issues are introduced by the following commit: https://github.com/odoo/enterprise/commit/f4c7115fdf.
The commit aimed to resolve an issue in which timers for sample data would start automatically, and the *Stop* button would throw an error. The issue was addressed by updating the condition that defines the `timerRunning`
variable, which controls whether the *Stop* button in the Timesheets app is displayed.

https://github.com/odoo/enterprise/blob/ac186aa71cd7e1b80b307ea12c7eaca246afd649/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L57-L64

Issue **I1** is a side effect of this change in the Project app, where the `timerRunning` variable is evaluated to `true`, causing the timer to be displayed when it should not.

The multiple timers running simultaneously (**I2**) stems from the `timerRunning` variable being initiated to false by default in the props.

https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L47-L50

The *Stop* button appearing after logging a task (**I3**) stems from the condition of the patch using `is_timer_running` over `timer_start`.

https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/timesheet_grid/static/src/hooks/sample_server_patch.js#L9-L15

## Fix
This commit reverts the problematic segments from the previous commit.

opw-5870756
opw-5879176
opw-5961764

Forward-Port-Of: odoo/enterprise#107014

Steps to reproduce:
------------------------------------
1. Install Timesheets Module with demo data
2. Create a new Employee with: 
    * Payroll Page > Contract > Start from 1st March
    * Payroll Page > Working hours set to 'Standard 40 hours/week'
3. Go to Timesheets > All Timesheets
4. Add Timesheet for any task as follows:
    * Select a date in a past week (e.g., 14th April)
    * Hours: 8 hours
    * Select the newly created employee
5. Go to Timesheets > All Timesheets:
    * Filter by the new employee
    * Navigate to the same past week
    * Observe the remaining hours for the employee (e.g, -32:00)
6. Open the newly created employee form:
    * Click on '+' to create a new contract version
    * Set the version date before the timesheet date (e.g., 12th April)
    * Change Working Hours to Standard 38 hours/week.
7. Repeat Step 5

Observation:
------------------------------------
The Remaining Hours shows -32:00, meaning the system still uses the 40 hours/week schedule instead of the updated one. The expected value should be -30:00 based on the 38 hours/week schedule.

Issue:
------------------------------------
The method `_get_contracts_valid_periods` determines which working calendar applies for which time period. It uses `contract.contract_date_start` and `contract.contract_date_end` to build calendar validity intervals, but these are the contract employment dates (shared across all versions of the same contract), NOT the version-specific effective dates.
Both versions share the same `contract_date_start`, so both claim the entire period as valid. The 40h calendar produces larger work intervals that win when combined via Intervals union, so the old 40h schedule is used instead of the current 38h one.

Solution:
------------------------------------
Replace `contract.contract_date_start` / `contract.contract_date_end` with `contract.date_start` / `contract.date_end`
These dates represent each version's effective validity period, computed from `date_version` and bounded by the next version's start date. Using these ensures each calendar is only valid during the period its version was actually in effect correctly splitting the working hours at version boundaries.

opw-6142137

Forward-Port-Of: odoo/odoo#264114
Forward-Port-Of: odoo/odoo#260614

Issue
--------------
When refreshing checks on account returns (e.g. from rapid successive clicks or component re-renders), multiple concurrent RPC calls to `refresh_checks` were being dispatched to the server. This created a race condition that resulted in duplicate `account.return.check` records being generated in the database.

steps to reproduce demonstrated in video: https://drive.google.com/file/d/1-A0ZHdYGdv-UL0dqClqK6Kos_iVXoZai/view?usp=sharing

When this happen the `runAllReturnChecks` method fires parallel RPC calls to [`refresh_checks`](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1974-L1992) on the server. In the case of instant multiple RPC calls, parallel threads are dispatched which causes the data preparation stage to run simultaneously.


Because both threads run in parallel, Thread 2 runs its [preparation and existing ](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1986-L1987 )check mechanism before Thread 1 has reached the actual `create()` function [trigger](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1998-L1999).  Consequently, Thread 2's existence check fails to find the record (since Thread 1 hasn't committed it to the database yet), and it considers the record eligible for creation—even though the exact same record is already prepared for creation by Thread 1. This race condition leads to duplicate `account.return.check` records.

   
   
 Logs to demonstrate the thread execution:
--------

```python
2026-04-16 08:30:51,493 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.000 0.002
2026-04-16 08:30:51,662 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "POST /web/dataset/call_kw/account.report/dispatch_report_action#account.report.dispatch_report_action HTTP/1.0" 200 - 17 0.006 0.012
2026-04-16 08:30:51,847 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "POST /web/dataset/call_kw/account.return/get_views#account.return.get_views HTTP/1.0" 200 - 26 0.009 0.025
2026-04-16 08:30:52,099 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:52] "POST /web/dataset/call_kw/account.return/web_read_group#account.return.web_read_group HTTP/1.0" 200 - 95 0.029 0.064
2026-04-16 08:30:52,320 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:52] "POST /web/dataset/call_kw/account.return/get_next_returns_ids#account.return.get_next_returns_ids HTTP/1.0" 200 - 2 0.001 0.004
                 THREAD NAME: odoo.service.http.request.137360481711808 Thread ID:  137360481711808
                 REFRESH CHECK START:--------------------------------------------
                 Thread ID:   137360481711808 -------------DATA PREPARING STAGE------------
                 Thread ID:   137360481711808
                 Thread ID:   137360481711808     RECORD EXISTING CHECK:  None
2026-04-16 08:30:53,842 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:53] "GET /odoo/tax-report/tax-return?debug=1 HTTP/1.0" 200 - 29 0.020 0.021
2026-04-16 08:30:54,066 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/webclient/load_menus HTTP/1.0" 200 - 4 0.002 0.009
2026-04-16 08:30:54,351 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/manifest.webmanifest HTTP/1.0" 200 - 6 0.003 0.005
2026-04-16 08:30:54,493 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/webclient/translations?hash=bb5aa713d587cc7dd07b13d1d7efc2c525517e99&lang=en_US HTTP/1.0" 200 - 1 0.000 0.002
2026-04-16 08:30:54,586 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/bundle/web_tour.interactive?lang=en_US&debug=1 HTTP/1.0" 200 - 1 0.001 0.003
2026-04-16 08:30:54,640 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/action/load_breadcrumbs HTTP/1.0" 200 - 7 0.003 0.006
2026-04-16 08:30:54,710 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/ir.http/lazy_session_info#ir.http.lazy_session_info HTTP/1.0" 200 - 2 0.001 0.004
2026-04-16 08:30:54,753 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /bus/websocket_worker_bundle?v=19.0-2 HTTP/1.0" 304 - 3 0.004 0.006
2026-04-16 08:30:54,766 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/image?model=res.users&field=avatar_128&id=2 HTTP/1.0" 304 - 9 0.012 0.013
2026-04-16 08:30:54,777 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /mail/data HTTP/1.0" 200 - 34 0.034 0.020
2026-04-16 08:30:54,824 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/account.return/get_views#account.return.get_views HTTP/1.0" 200 - 3 0.001 0.010
2026-04-16 08:30:54,934 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/account.return/web_read_group#account.return.web_read_group HTTP/1.0" 200 - 88 0.029 0.051
2026-04-16 08:30:55,107 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:55] "POST /web/dataset/call_kw/account.return/get_next_returns_ids#account.return.get_next_returns_ids HTTP/1.0" 200 - 2 0.001 0.005
                 THREAD NAME: odoo.service.http.request.137360513177280 Thread ID:  137360513177280
                 REFRESH CHECK START:--------------------------------------------
                 Thread ID:   137360513177280 -------------DATA PREPARING STAGE------------
                 Thread ID:   137360513177280
                 Thread ID:   137360513177280     RECORD EXISTING CHECK:  None
2026-04-16 08:30:55,589 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:55] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.001 0.006
2026-04-16 08:30:56,702 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:56] "GET /web/service-worker.js HTTP/1.0" 200 - 1 0.000 0.003
2026-04-16 08:30:58,893 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:58] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.006 0.023
2026-04-16 08:31:05,296 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:31:05] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.001 0.002
                 Thread ID:   137360481711808     DATA to_create:  168
                 Thread ID:   137360481711808 done process create  
2026-04-16 08:31:10,132 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:31:10] "POST /web/dataset/call_kw/account.return/refresh_checks#account.return.refresh_checks HTTP/1.0" 200 - 513 11.611 6.039
                 Thread ID:   137360513177280     DATA to_create:  168
                 Thread ID:   137360513177280 done process create 

```

- OPW: 5917459

Forward-Port-Of: odoo/enterprise#114045

**Problem:**
In view Inventory valuation, generate entry doesn't work when 
multiple companies are selected. 

In the view only the main company matters. 
That means that even if multiple companies are selected, only the stock 
variation lines related to the main company selected are displayed
(which is expected).
But if you then click on 'generate entry' the account move lines created
will have wrong values (not matching the values appearing in the view)

**Steps to reproduce:**
- create 2 new companies (to have clean accounting)
- create a warehouse for both companies
- for both comp, in settings for the 'fiscal localization' set 
Package : Generic Chart of account, if not already set
(to have account journals).

From company 1 : 
- create a storable prod with avco perpetual category
- confirm PO for 2  @ 10, receive 
- bill only 1 @ 10

From company 2: 
- make sure the category is also perpetual average from this 
other company
- confirm PO for 2 @ 50, receive, don't bill

Notice how from the 'Inventory Valuation' view, rightfully,
only the main company matters (no matter what 
other comp are selected):
- If main comp is comp 1 there is stock variation lines
for amount of 10 (which is expected because we have 
20 in stock and only 10 in stock valuation account)
- If main comp is comp 2 there is stock variation lines
for amount of 100 (which is expected because we have 
100 in stock and only 0 in stock valuation account)

With comp 1 and 2 selected and comp 1 as main company: 
- click on 'Generate Entry'

**Current behavior:**
- both line have a balance of 110

**Expected behavior:**
- they should have a balance of 10 as we saw 
on the 'inventory valuation' view

**Cause of the issue:**
To generate the data from the 'inventory valuation' 
view, inside _get_report_data() we call stock_value() 
and stock_accounting_value() to compare values 
from inventory and value from accounting. 
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/report/stock_valuation_report.py#L36-L37

stock_value() sums total_value() of each product in 
the valued accounts
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L90-L94
Whereas stock_acounting_value(), sums the balance 
of each account move line of each valuation account
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L112-L114
All of this is related to the main company because 
we call _get_report_data() with context 'allowed_company_ids' 
set to only the main company
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/report/stock_valuation_report.py#L13

But when we click on generate entry, 
_get_stock_valuation_account_vals() is called with no context
modification to 'allowed_company_ids' so when we call 
stock_value(),
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L238-L239
total_value will be based on both company
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L92

Note that stock_accounting_value() is still rightfully based only 
on main company because we use self.id in the domain
https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L105-L108

opw-6168699

Forward-Port-Of: odoo/odoo#262776

Steps to Reproduce (Fresh Database):
--------------------------------------
1. Install `Manufacturing` (mrp) and `PLM` (mrp_plm) modules
2. Create a product > New -- Name: "Test Product" > Save
3. Create BoM v1
   - Go to Manufacturing > Products > Bills of Materials > New --Product: Test Product
   - Add component: any
4. Create and apply ECO 1 on BoM v1
   - Go to PLM > ECOs > New-- Product: Test Product | Apply on: Bill of Materials
   - BoM: Test Product (v1) > Confirm > Apply Changes
   - This creates BoM v2 (previous_bom_id = BoM v1)
5. Create and apply ECO 2 on BoM v2
   - Same as step 4 but select BoM v2
   - This creates BoM v3 (previous_bom_id = BoM v2)
6. Create a separate unrelated BoM for the same product
   - Go to Manufacturing > Bills of Materials > New
   - Product: Test Product | Component: "Component B" > Save
7. Create ECO 3 on the separate BoM
   - Go to PLM > ECOs > New - Product: Test Product | Apply on: Bill of Materials
   - BoM: select the separate BoM from step 6 > Confirm

Observed Bug:
-------------
- Open BoM v3 > ECO(s) stat button shows count = 2
- Click the button > opens 3 records (ECO 3 incorrectly included)

Explain:- 
----------
The ECO stat button on the BoM form was showing a mismatched count vs
the actual records opened when clicking it. This happened because
[button_mrp_eco](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L56) was using all keys from [_get_previous_boms](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L67)() as the
domain, which includes BoMs from unrelated lineages of the same product
template, while [_compute_eco_data](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L20) only counts ECOs belonging to the
current BoM's version lineage.

Fixed by filtering the domain to only include BoM IDs whose lineage set
contains the current BoM ID, making the opened records consistent with
the displayed count.

Before Fix
<img width="1901" height="875" alt="image" src="https://github.com/user-attachments/assets/3208aed5-ebd3-47a3-a457-a7d61b7743cb" />

```
In [24]: labo = self.env['mrp.bom'].browse(710)
In [25]: previous_boms_mapping = labo._get_previous_boms()
In [26]: Test = ['&', ('bom_id', 'in', list(previous_boms_mapping.keys())), ('type', '=', 'bom')]
In [27]: Test
Out[27]:
['&',
 ('bom_id',
  'in',
  [710,
   1991,
   2049,
   1913,
   1840,
   1823,
   1676,
   1759,
   1794,
   1651,
   1604,
   1544,
   1537,
   1527,
   1506,
   1460,
   1265,
   1259,
   1196,
   1221,
   1223,
   1060,
   1029,
   960,
   858,
   850,
   791,
   739,
   723,
   698]),
 ('type', '=', 'bom')]
```

With My Fix
<img width="1824" height="947" alt="image" src="https://github.com/user-attachments/assets/0d68fdbc-7e42-4ce4-a326-2fb030ba1d06" />

```
In [15]: labo = self.env['mrp.bom'].browse(710)
In [16]: previous_boms_mapping = labo._get_previous_boms()
In [17]: previous_boms_mapping
Out[17]:
{710: {710},
 1991: set(),
 2049: set(),
 1913: set(),
 1840: set(),
 1823: set(),
 1676: set(),
 1759: set(),
 1794: set(),
 1651: set(),
 1604: set(),
 1544: set(),
 1537: set(),
 1527: set(),
 1506: set(),
 1460: set(),
 1265: set(),
 1259: set(),
 1196: set(),
 1221: set(),
 1223: set(),
 1060: set(),
 1029: set(),
 960: set(),
 858: set(),
 850: set(),
 791: set(),
 739: set(),
 723: set(),
 698: {710}}
In [18]: relevant_bom_ids = [
    ...:     bom_id
    ...:     for bom_id, current_bom_set in previous_boms_mapping.items()
    ...:     if labo.id in current_bom_set
    ...: ]
In [19]: relevant_bom_ids
Out[19]: [710, 698]
```

Task-6065020

Forward-Port-Of: odoo/enterprise#114039

**Steps to reproduce:**
- Create a new marketing campaign with two activities
- Set them to occur some number of days after the beginning
- Save the campaign and start it
- Modify one of the activities to occur some number of days after the
other activity and save
- Modify the child activity by changing the number of days after its
parent that it should run and save
- An error will be thrown

**Issue:**
The trace related to the child activity has no parent when trying to reschedule it in `_update_schedule_date`. This causes an issue when trying to get the first mailing_trace_ids using index 0 in this line:
`base_dt_str = trace.parent_id.schedule_date or trace.parent_id.mailing_trace_ids[0].write_date or trace.participant_id.create_date`

**Fix:**
Prevent the activity hierarchy to be modified on started campaigns.
We also change the indexing to avoid further out of range issue and
properly default on the participant create value.

Trying to match existing traces to their parents has too many edge cases when trying to avoid duplicates, and might often need to reset the whole trace chain to work properly. This approach avoids user mistakes on running
campaigns, but if a user tries to launch a test (even on draft campaign) he won't be able to modify the hierarchy further without deleting/recreating some activities/traces. So we should ignore this for test traces, but it could
impact the behavior between test and actual executions.

opw-5362978

Forward-Port-Of: odoo/enterprise#107556

## Issue
When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive.

## Steps to reproduce
1. Install *United States - Payroll* (`l10n_us_hr_payroll`)
2. Set the current company's State to Colorado
3. Create an employee and a contract
    - Wage: $0
    - (Set the contract's status to *Running*)
    - (In the payroll tab) State Withholding Allowance: $1000
4. Create a Payslip for the employee
    - Structure: *"United States: Regular Pay"*
5. Compute Sheet
6. **In the _Salary Computation_ tab, the _CO State Income Tax_ line has a positive value**

## Justification
This fix is similar to the one applied for the AL(abama) state income tax by https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6. That modification was justified by CAS (PO of US localizations for Payroll) in opw-5137280:

> *"Payroll taxes are always funds withheld from employee's paychecks, if there is a positive value it means the tax is a refund, not a withholding. Refunds happen when individuals file their income."*

## Note to reviewer
The test [`test_069_al_state_tax_0_income`](https://github.com/odoo/enterprise/blob/219d2a797ee2099c9d77c2defc9c9c5e1d504ffe/test_l10n_us_hr_payroll_account/tests/test_salary_rules.py#L957-L989) (added by the aforementioned commit https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6) is wrongly indented and thus never executed. The test passes with the dedicated fix, and fails without it, as expected. Let me know if you want me to indent it correctly (in this commit or in an additional one).



opw-5999856

Forward-Port-Of: odoo/enterprise#116653
Forward-Port-Of: odoo/enterprise#112724

__

## Short functional explanation of the error
When we create 2 shifts for the same day for an employee, on a non-working day for their schedule. When trying to create the second one after setting the end date to midnight, we get the error:
`ValueError: Expected singleton: hr.attendance.overtime.line(2, 3)`

## Reproduction Steps
1. Create an Employee. In the Payroll tab, Make sure they have an active contract. Set their Working Hours to a fixed schedule, where they have saturdays as non-working days. In the Settings tab, set an Overtime Ruleset.
2. Click on the overtime ruleset. Then, for each rule, under Action, set the Work Entry Type To Use as Overtime Hours.
3. Go to Attendances. In Configuration > Settings, under Extra Hours, set the Extra Hours Validation as Approved By Manager.
4. Create an attendance for your Employee on a Saturday, from 12h to 18h.
5. Create a second attendance for your Employee on that same Saturday, from 18h to 00h00. Try to Save.
Note: the timezone of your computer, the working schedule and the employee should be set at Brussels time. 

### Expected behavior
The Overtime is registered.

### Unexpected behavior
An error occurs:
`ValueError: Expected singleton: hr.attendance.overtime.line(2, 3)`

## Origin of the issue
The end time of the overtime is defined as follows: https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L54-L56 However, in the case where our shift ends after the computed end of the day (in our case, the end time of the shift is 00:00:00 and the end of the day is set at 23:59:59), it creates some problems. The end time of the overtime is set 1 second too early. Later we compute the start time of the overtime as follows: https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L57 Thus, the time start of the overtime is also set one second too early. As our second shift starts right after the first one, after the execution of this code, we will get a second shift that starts before the end of the first one.
Then, we add these values in a list:
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L59 which will contain overlapping timeframes, and with which we create an Interval:
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L60 But when we create an Interval with overlapping timeframes, we obtain only one interval as the timeframes are merged.
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L173 As a result, `overtime_intervals` will contain only one time frame with 2 different corresponding overtimes, which causes a singleton error when reaching:
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L179 __
opw-6096454

Forward-Port-Of: odoo/enterprise#114147

Steps to reproduce:
------------------------------------
1. Install Timesheets Module with demo data
2. Create a new Employee with: 
    * Payroll Page > Contract > Start from 1st March
    * Payroll Page > Working hours set to 'Standard 40 hours/week'
3. Go to Timesheets > All Timesheets
4. Add Timesheet for any task as follows:
    * Select a date in a past week (e.g., 14th April)
    * Hours: 8 hours
    * Select the newly created employee
5. Go to Timesheets > All Timesheets:
    * Filter by the new employee
    * Navigate to the same past week
    * Observe the remaining hours for the employee (e.g, -32:00)
6. Open the newly created employee form:
    * Click on '+' to create a new contract version
    * Set the version date before the timesheet date (e.g., 12th April)
    * Change Working Hours to Standard 38 hours/week.
7. Repeat Step 5

Observation:
------------------------------------
The Remaining Hours shows -32:00, meaning the system still uses the 40 hours/week schedule instead of the updated one. The expected value should be -30:00 based on the 38 hours/week schedule.

Issue:
------------------------------------
The method `_get_contracts_valid_periods` determines which working calendar applies for which time period. It uses `contract.contract_date_start` and `contract.contract_date_end` to build calendar validity intervals, but these are the contract employment dates (shared across all versions of the same contract), NOT the version-specific effective dates.
Both versions share the same `contract_date_start`, so both claim the entire period as valid. The 40h calendar produces larger work intervals that win when combined via Intervals union, so the old 40h schedule is used instead of the current 38h one.

Solution:
------------------------------------
Replace `contract.contract_date_start` / `contract.contract_date_end` with `contract.date_start` / `contract.date_end`
These dates represent each version's effective validity period, computed from `date_version` and bounded by the next version's start date. Using these ensures each calendar is only valid during the period its version was actually in effect correctly splitting the working hours at version boundaries.

opw-6142137

Forward-Port-Of: odoo/odoo#260614

**Description of the issue/feature this PR addresses:**
The `WebsiteEvent._getEventObjectId` method lacks a specific match case for the root directory, causing event ID retrieval to fail on the homepage.

In order to resolve this, I've implemented a default return of 0 when the URL pattern matching fails [following the pattern established by later revisions of this code](https://github.com/odoo/odoo/blob/2199f71070ce3e9a4717eb6b750c14485406f7aa/addons/website_event/static/src/website_builder/event_page_option_plugin.js#L67).

**Steps to reproduce bug:**
1. Create an event website
2. Create an event and visit it
3. On the page click Site > Properties
4. Enable `Is Homepage`
5. Return to the homepage of the application and open the editor

https://drive.google.com/file/d/1OpCUAp4LJKqkoStciWeJEGVVlR3qpw1R/view?usp=drive_link

**Current behavior before PR:**

https://drive.google.com/file/d/1c7ACqaQx03mePzJSV_RoPn8mlLWSMa1I/view?usp=drive_link

**Desired behavior after PR is merged:**

https://drive.google.com/file/d/1L3Ne9h6-yB3v7VbXipjly9OrDSkZvDOu/view?usp=drive_link

opw-6101680

Forward-Port-Of: odoo/odoo#262886
Forward-Port-Of: odoo/odoo#258502

Before commit:
The Norwegian VAT XML export fails Skatteetaten validation due to incorrect
decimal formatting, mathematical rounding mismatches between base and tax
amounts, missing mandatory legal notes, and invalid KID number formats.

Fix:
To strictly follow Skatteetaten validation rules for the Norway VAT XML, the
following changes were implemented:
- Ensured standard rates drop the decimal (e.g, `25.0` to `25`), and formatted 
  fractional rates like `11.11` to `11,11` in XML.
- Rounded down the `tax_amount` to align precisely with government mathematical
  expectations.
- `base_amount` converted into absolute value to ensuring the calculation
  (`base * rate = tax`) resolves perfectly.
- Add the mandatory `<merknad>` explaining the reverse charge method for codes
  81, 83, 86, 88, and 91.
- Clean the `company_kid` by safely stripping the 'NO' prefix, and 'MVA' suffix.

Expect:
The generated XML payload now adheres perfectly to Skatteetaten's strict
structural and mathematical rules, allowing the VAT return to pass government
validations successfully.

Related Community PR: https://github.com/odoo/odoo/pull/258390

Task-6033027

Forward-Port-Of: odoo/enterprise#116962
Forward-Port-Of: odoo/enterprise#110792

A traceback occurs when sending an invoice to Peru UBL if a combo product
invoice line does not have any taxes applied.

Steps to reproduce the error:
- Install ``l10n_pe_edi`` module with demo data
- Switch to PE Company
- Create an invoice > Add a Office Combo product > unset the taxes > Confirm
- Process now

https://github.com/odoo/enterprise/blob/d7f71a68fbd5ff9c7cd52f96e1616671a6b8d77c/l10n_pe_edi/models/account_edi_xml_ubl_pe.py#L549-L552
Here, the ``grouping_key`` becomes ``None`` when no taxes are present on the invoice line.
Normally, invoices without taxes are restricted at [1],
but combo products are excluded from this validation at [2].
As a result, combo product lines without taxes bypass the restriction and trigger a traceback.

[1]: https://github.com/odoo/enterprise/blob/d7f71a68fbd5ff9c7cd52f96e1616671a6b8d77c/l10n_pe_edi/models/account_edi_format.py#L928-L929

[2]: https://github.com/odoo/odoo/blob/42b8852df9b323984364c41a13cf27d19fbe04a7/addons/account/models/account_move_line.py#L3433-L3434

sentry-7430552834

**Steps to reproduce:**

- Install `quality_control` and `mrp` modules with demo data
- Go to Quality → Quality Points → Create(New)
- In the `Type` field, observe that options such as
  'Print Label', 'Register Production', etc. appear
  regardless of the selected `Operations`

**Issue**:

Types like `print_label`, `register_production`,
`register_byproducts`, and `register_consumed_materials`
are displayed even when the Operations is not
Manufacturing and when no work order operation is defined.

**Expected behavior**:

These `types` should only be available when:
- `Operations` Type = Manufacturing
- `work order operation` is set

**Cause**:

The custom search logic for the `allow_registration` boolean field
relied on receiving a direct `True` or `False` value.
https://github.com/odoo/enterprise/blob/de3682c7f50b68c19d3a3429fa3768c447074f50/mrp_workorder/models/quality.py#L104
Before `saas-18.3`, the `value` passed to the domain search method was
a plain boolean(True/False).
https://github.com/odoo/enterprise/blob/de3682c7f50b68c19d3a3429fa3768c447074f50/mrp_workorder/models/quality.py#L21-L24

Starting from `saas-18.3`, the value is passed as
`OrderedSet([True])`. while the operator received is `in`
or `not in`.
Because the value always arrives `OrderedSet([True])`, 
the condition checking the `value` is always
evaluated as truthy. As a result, the code never reaches the
else branch of the logic, which causes the incorrect domain
behavior.


The issue is caused by how Odoo optimizes boolean domains.
When we pass:
    ('allow_registration', '=', False)
the value correctly reaches the base domain logic as
`allow_registration = False`.
But during domain processing at:

https://github.com/odoo/odoo/blob/347c46f8ecff7ae97c2a686bf5750374b6c3e2d3/odoo/orm/domains.py#L967

it optimize it to:
    ('allow_registration', 'in', [False])
Then `_optimize()` is called, which again calls
`_optimize_step()`:

https://github.com/odoo/odoo/blob/347c46f8ecff7ae97c2a686bf5750374b6c3e2d3/odoo/orm/domains.py#L459

Inside `_optimize_step()` at:

https://github.com/odoo/odoo/blob/347c46f8ecff7ae97c2a686bf5750374b6c3e2d3/odoo/orm/domains.py#L971

it is further simplified to:n ('allow_registration', 'not in', [True])
Similarly, when we pass:  ('allow_registration', '=', True)
it becomes:  ('allow_registration', 'in', [True])
This is expected behavior.

The custom search method for `allow_registration`
was not handling these optimized forms correctly,
which caused Issue.

**FIX:**

- Use the domain `operator (in / not in)` to determine the intended
boolean condition instead of relying on the received value(OrderedSet([True])).

- This is correct because Odoo normalizes boolean domains to only two
forms during optimization: in [True] and not in [True]. Therefore,
the operator reliably indicates whether the condition expects
True or False, allowing the search method to handle the domain
correctly.

---
opw-5915197

## Issue
When making a request for quotation for a subcontracted product and returning the delivery "for exchange", the new incoming delivery does not have the correct destination. Instead of having the stock of the user, the destination of the new incoming delivery is the same as its source: the subcontracting location.

<img width="1254" height="257" alt="5479900" src="https://github.com/user-attachments/assets/c7e6d392-8328-4a03-a71e-466e768f448b" />

## Steps to reproduce
1. Install MRP Subcontracting (`mrp_subcontracting`) and Purchase (`purchase`)
2. In Settings, enable *Subcontracting*
3. Create a Product P and a subcontracting BoM with Subcontractor S
4. Create a Request for Quotation
    - Vendor: Subcontractor S
    - Product: Product P (any quantity > 0)
5. Confirm the RFQ, receive the PO, validate the picking
6. On the validated picking, click *Return*, set the quantity of products to return, and click *Return for Exchange*
    - This creates two new pickings, one to return the product(s) we received, and one to receive new products
7. Validate the two new pickings
8. **In Inventory > Reporting > Moves History, the very last `stock.move.line` has the same location in the *From* (`location_id`) and the *To* (`location_dest_id`) columns**

## Cause
The `location_dest_id` of the new `stock.move` is updated in `StockReturnPickingLine._prepare_move_default_values`.

https://github.com/odoo/odoo/blob/fb534f1eadcb8ef74e2ee6fd5b68872dddb978e3/addons/mrp_subcontracting/wizard/stock_picking_return.py#L20-L25

The condition added by https://github.com/odoo/odoo/commit/5404b426aac9 sets the destination of all returned subcontracted moves to the subcontractor location. This is incorrect when using "return for exchange", as in this case, the return move is directed towards the user's stock. In fact, when using "return for exchange", the following pickings are created:

| id | name         | return_id |   |
|:--:|--------------|:---------:|---|
| 1  | WH/IN/00001  |           | Initial RFQ delivery |
| 2  | WH/OUT/00001 |     1     | Return of the initial RFQ delivery |
| 3  | WH/IN/00002  |     2     | New products delivery to replace the initial delivery. The stock.move.line of this stock.picking has a wrong `location_dest_id` |

## Fix
In the context of return for exchanges, the returned item must be directed to the *Subcontracting Location* while the new item must be directed to   the *Stock*. In the `_prepare_move_default_values`, we should only set   the `location_dest_it` to the subcontractor location for outgoing pickings.

opw-5479900

**Steps to reproduce:**
* Install the *Accounting* module with French localization (*l10n_fr_account*).
* Create a *Sales Tax* with:
  * A new tax group (e.g., 'Codifab').
  * Enable *Affect Base of Subsequent Taxes*.
* Create a *Sales Order*:
  * Add the first tax (with *Affect Base of Subsequent Taxes*).
  * Then add the second tax (eg VAT tax).
* Confirm the *Sales Order*.
* Create a *Down Payment Invoice* (percentage-based).
* Open the generated invoice and:
  * Remove the first tax (the one affecting the base).

**Observed behavior:**
* The amount of the second tax group does not update after removing the first tax, leading to incorrect tax computation.

**Cause:**
* In `_import_base_line_extra_tax_data`, the condition: `all(str(tax.id) in extra_tax_data['manual_tax_amounts'] for tax in sorted_taxes)` only ensured partial matching of taxes.
* This allowed reuse of stale `manual_tax_amounts` when taxes were removed or modified, causing incorrect base values for dependent taxes (e.g., *Affect Base of Subsequent Taxes*).

**Fix:**
* Update the condition to enforce an exact match between current taxes and cached `manual_tax_amounts` by checking both size and membership.
* Prevent reuse of outdated tax data when taxes change, ensuring proper recomputation of dependent taxes.
* Align Python logic with the JS implementation for consistency between `account_tax.py` and `account_tax.js`.

opw-6063970

Sending the final invoice of a sale order to ZATCA crashed with `ValueError: Expected singleton: account.move(a, b)` when the sale order had multiple down-payment references.

Steps to reproduce:
1. Configure a SA company and setup ZATCA
2. Create a sale order and confirm it
3. Deliver the product line.
3. From the sale order, create a down-payment invoice (fixed amount, e.g. 115) and post it (DP1).
4. On DP1, click "Credit Note" and choose "Full refund and new draft invoice"; validate. DP1 becomes `reversed` and a new draft down-payment DP2 is created. Post DP2.
5. From the sale order, create the final regular invoice and post it.
6. Send the final invoice to ZATCA (or generate its XML) -> `ValueError: Expected singleton: account.move(a, b)`.

Root cause: _l10n_sa_get_line_prepayment_vals looks up the related down-payment move through the down-payment sale order line shared with the product line. The filter matched any out_invoice with _is_downpayment() == True, so the reversed DP1 and the active DP2 both ended up in the recordset, and reading .name raised the singleton error.

Prefer non-reversed down-payment moves when available, but fall back to reversed ones if no alternative exists (e.g.
when generating a credit note of the final invoice after the original down-payment was itself reversed).

opw-6116265

Forward-Port-Of: odoo/odoo#260980
Forward-Port-Of: odoo/odoo#259384

[IMP] l10n_be_hr_payroll: restrict dimona flx category

FLX in employee_type is selectable only for certain CPs (Joint Committees) and NACE codes of the company
    Ref list link: https://emploi.belgique.be/fr/themes/contrats-de-travail/contrats-de-travail-particuliers/contrat-de-travail-flexi-job#toc_heading_3

1 - I created a new allowed_employee_types_ids M2M field to determine which employee types will be shown in the selection box (or flex will be shown or not)
    1.1 - If the egov3 code of the joint committee is one of the determined codes in the ref link, the flex type is shown.
    1.2 - Sometimes egov3 code of joint committee and NACE code of the company need to be combined

2 - In hr_version, joint committee field in UI was reseting after changing employee type to Flex or changing type from Flex to False, now it remains unchanged

3 - In employee form view, allowed_employee_types_ids is added as a domain to employee_type_id to show flex type or not

task - 6131721

Alphabetical order differs from one language to another. For example, in Estonian, Z comes after S and before T.

This means that the order of strings displayed to the end users needs to be adapted depending on the current locale.

This commit introduces the `localeCompare` utility function, which allows comparing two strings in a locale-sensitive way.

### What's wrong with the default behavior of `Array.prototype.sort`?
`Array.prototype.sort` compares strings according to the UTF-16 code unit values of their characters. This results in behaviors that may not be what the end user expects. For example, "Zebra" is sorted before "apple", as uppercase letters come before lowercase letters in the ASCII table. "Élise" is not grouped with "Elise", and two same accented letters with different normalization forms aren't considered to be equivalent.

### Why not just use `String.prototype.localeCompare`?
- Our `localeCompare` uses `user.lang` by default, which the string method doesn't
- Our `localeCompare` comes with sensible defaults, such as sorting numbers based on their numerical value rather than their position in the ASCII table (i.e. "User 9" should come before "User 10000")
- Our `localeCompare` always reuses the same instance of `Intl.Collator`, sparing the theoretical cost of instantiating it every time.

Community: https://github.com/odoo/odoo/pull/264047

Some flows post an invoice and then perform additional work that may fail or at least delay the database
commit (e.g. `_cron_post_process()` on `payment.transaction`). This extra work can raise standard Odoo exceptions, and even without them, concurrent transactions or database deadlocks are possible.

The invoice is committed on Avalara's side within `_post()`, so a later rollback of the Odoo transaction leaves a committed ghost invoice on Avalara's side. Accountants need to find these and manually void them to stop Avalara from filing incorrect tax returns.

To avoid this, we move the Avalara commit into a postcommit hook. Since `account_external_tax` already calls
`_get_external_taxes()` just before `_post()` to calculate taxes, the postcommit call is unlikely to fail. If it does, we log an activity on the invoice to notify the user, who will then need to resolve it manually (either by cancelling on the Odoo side and retrying, or by recreating the entry directly in the Avalara portal).

opw-6192702

Issue
--------------
When refreshing checks on account returns (e.g. from rapid successive clicks or component re-renders), multiple concurrent RPC calls to `refresh_checks` were being dispatched to the server. This created a race condition that resulted in duplicate `account.return.check` records being generated in the database.

steps to reproduce demonstrated in video: https://drive.google.com/file/d/1-A0ZHdYGdv-UL0dqClqK6Kos_iVXoZai/view?usp=sharing

When this happen the `runAllReturnChecks` method fires parallel RPC calls to [`refresh_checks`](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1974-L1992) on the server. In the case of instant multiple RPC calls, parallel threads are dispatched which causes the data preparation stage to run simultaneously.


Because both threads run in parallel, Thread 2 runs its [preparation and existing ](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1986-L1987 )check mechanism before Thread 1 has reached the actual `create()` function [trigger](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1998-L1999).  Consequently, Thread 2's existence check fails to find the record (since Thread 1 hasn't committed it to the database yet), and it considers the record eligible for creation—even though the exact same record is already prepared for creation by Thread 1. This race condition leads to duplicate `account.return.check` records.

   
   
 Logs to demonstrate the thread execution:
--------

```python
2026-04-16 08:30:51,493 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.000 0.002
2026-04-16 08:30:51,662 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "POST /web/dataset/call_kw/account.report/dispatch_report_action#account.report.dispatch_report_action HTTP/1.0" 200 - 17 0.006 0.012
2026-04-16 08:30:51,847 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "POST /web/dataset/call_kw/account.return/get_views#account.return.get_views HTTP/1.0" 200 - 26 0.009 0.025
2026-04-16 08:30:52,099 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:52] "POST /web/dataset/call_kw/account.return/web_read_group#account.return.web_read_group HTTP/1.0" 200 - 95 0.029 0.064
2026-04-16 08:30:52,320 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:52] "POST /web/dataset/call_kw/account.return/get_next_returns_ids#account.return.get_next_returns_ids HTTP/1.0" 200 - 2 0.001 0.004
                 THREAD NAME: odoo.service.http.request.137360481711808 Thread ID:  137360481711808
                 REFRESH CHECK START:--------------------------------------------
                 Thread ID:   137360481711808 -------------DATA PREPARING STAGE------------
                 Thread ID:   137360481711808
                 Thread ID:   137360481711808     RECORD EXISTING CHECK:  None
2026-04-16 08:30:53,842 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:53] "GET /odoo/tax-report/tax-return?debug=1 HTTP/1.0" 200 - 29 0.020 0.021
2026-04-16 08:30:54,066 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/webclient/load_menus HTTP/1.0" 200 - 4 0.002 0.009
2026-04-16 08:30:54,351 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/manifest.webmanifest HTTP/1.0" 200 - 6 0.003 0.005
2026-04-16 08:30:54,493 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/webclient/translations?hash=bb5aa713d587cc7dd07b13d1d7efc2c525517e99&lang=en_US HTTP/1.0" 200 - 1 0.000 0.002
2026-04-16 08:30:54,586 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/bundle/web_tour.interactive?lang=en_US&debug=1 HTTP/1.0" 200 - 1 0.001 0.003
2026-04-16 08:30:54,640 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/action/load_breadcrumbs HTTP/1.0" 200 - 7 0.003 0.006
2026-04-16 08:30:54,710 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/ir.http/lazy_session_info#ir.http.lazy_session_info HTTP/1.0" 200 - 2 0.001 0.004
2026-04-16 08:30:54,753 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /bus/websocket_worker_bundle?v=19.0-2 HTTP/1.0" 304 - 3 0.004 0.006
2026-04-16 08:30:54,766 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/image?model=res.users&field=avatar_128&id=2 HTTP/1.0" 304 - 9 0.012 0.013
2026-04-16 08:30:54,777 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /mail/data HTTP/1.0" 200 - 34 0.034 0.020
2026-04-16 08:30:54,824 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/account.return/get_views#account.return.get_views HTTP/1.0" 200 - 3 0.001 0.010
2026-04-16 08:30:54,934 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/account.return/web_read_group#account.return.web_read_group HTTP/1.0" 200 - 88 0.029 0.051
2026-04-16 08:30:55,107 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:55] "POST /web/dataset/call_kw/account.return/get_next_returns_ids#account.return.get_next_returns_ids HTTP/1.0" 200 - 2 0.001 0.005
                 THREAD NAME: odoo.service.http.request.137360513177280 Thread ID:  137360513177280
                 REFRESH CHECK START:--------------------------------------------
                 Thread ID:   137360513177280 -------------DATA PREPARING STAGE------------
                 Thread ID:   137360513177280
                 Thread ID:   137360513177280     RECORD EXISTING CHECK:  None
2026-04-16 08:30:55,589 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:55] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.001 0.006
2026-04-16 08:30:56,702 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:56] "GET /web/service-worker.js HTTP/1.0" 200 - 1 0.000 0.003
2026-04-16 08:30:58,893 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:58] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.006 0.023
2026-04-16 08:31:05,296 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:31:05] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.001 0.002
                 Thread ID:   137360481711808     DATA to_create:  168
                 Thread ID:   137360481711808 done process create  
2026-04-16 08:31:10,132 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:31:10] "POST /web/dataset/call_kw/account.return/refresh_checks#account.return.refresh_checks HTTP/1.0" 200 - 513 11.611 6.039
                 Thread ID:   137360513177280     DATA to_create:  168
                 Thread ID:   137360513177280 done process create 

```

- OPW: 5917459

Forward-Port-Of: odoo/enterprise#114045

Currently, an error occurs when a user attempts to mark a payslip as paid.

**Steps to Reproduce:**

 - Install the `hr_payroll` module without demo data.
 - Go to `Payslips` and click on `New Off-cycle`.
 - Create a record > `Compute` > `Validate`, and Pay.
 - In the wizard, enable `Include Unpaid` and select `CSV` mode.
 - Click `Mark as Paid`.

**Error:**
`UnboundLocalError: cannot access local variable 'rows' where it is not associated with a value`

The error occurs when a user tries to mark a payslip as paid with Include Unpaid enabled. 
When the wizard is created from here [1], the default unpaid payslips are empty. In this case, 
the system assigns an empty set of payslips to process [2].and the rows variable is not 
defined because there are no payslips to work on, which raises the error [3].

This commit ensures that when the wizard is created, the matched unpaid payslips are passed to 
the wizard. If the Include Unpaid option is enabled, the unpaid payslips are assigned for processing, 
similar to [4]. The unpaid payslips cannot be empty, as they always include the currently 
processed payslip.
Also, the rows are redefined for each payslip case and updated accordingly. Therefore, this commit 
ensures that the rows are created at the end from grouped payments.

[1] https://github.com/odoo/enterprise/blob/a784d118e076724b02e5c59d9ce5d1815c42b0bf/hr_payroll/models/hr_payslip.py#L792-L809

[2] https://github.com/odoo/enterprise/blob/e971fca0d09e564ae9029f3d7e166e078c44dcbb/hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L56

[3] https://github.com/odoo/enterprise/blob/e971fca0d09e564ae9029f3d7e166e078c44dcbb/hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L97

[4]: https://github.com/odoo/enterprise/blob/a784d118e076724b02e5c59d9ce5d1815c42b0bf/hr_payroll/models/hr_payslip_run.py#L274-L288

sentry-7436885639

Forward-Port-Of: odoo/enterprise#116787
Forward-Port-Of: odoo/enterprise#115090

Issue
-----
Putting a max weight on a package type causes getting a rate with Sendcloud to fail.

Steps to reproduce
-----
- Setup Mondial Relay using Sendcloud
- Set a default package type with max weight 2kg
- Create a product with a 500g weight
- Create a SO with the product
- Add delivery
	- Sendcloud Mondial Relay
	- Get rate

> Impossible to get a rate

Cause
-----
When retrieving the shipping method to use when retrieving a rate, we use the real weight of the order.

https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L67 https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L81

However, when making the rate call, we use the value returned by `_split_shipping`

https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L91

which is equal to the maximum weight of the package. This is blocking in some cases, like if
- the real weight is 750g
- the package max is 2kg
- Sendcloud returns a shipping method for [500g;1kg]

Asking a rate for this method & a 2kg package will fail (rightfully so).

Solution
-----
The shipment should be split into packages before retrieving the shipping methods. Otherwise the problem might be the other way around where we retrieve a shipping method for the whole order, only to split it into multiple packages because they don't fit in one.

Also, the `shipping_weight` returned by `_split_shipping` should only be different from the order's total weight if it is higher than the maximum deliverable weight.

-----
Ticket:
opw-5947199

Forward-Port-Of: odoo/enterprise#116909
Forward-Port-Of: odoo/enterprise#108315

When the network drops after eTIMS processes a transaction but before Odoo receives the confirmation, Odoo would retry with the same invoice number, causing eTIMS error 924 (Invoice number already exists).

For POS orders, the old code decremented the sequence on any error (including timeout), so the next retry consumed the same invcNo. If eTIMS had already recorded the original send, the retry was rejected with 924. Fix by introducing a fetch-first strategy: on retry, if a pending invcNo is found in l10n_ke_order_json, call selectInvoiceDetails before sending. If eTIMS already has the invoice, recover the receipt data directly without resending. If eTIMS does not have it, resend with the same invcNo safely. On timeout errors, the sequence is no longer decremented so the invcNo is preserved in l10n_ke_order_json for the next idempotent retry.

For customer invoices, the existing fetch-first logic only bailed out on TIM (timeout) errors, falling through on CON (connection) errors and retrying blindly. Additionally, if saveTrnsSalesOsdc returned 924, there was no recovery path and the invoice number would be cleared. Fix by also bailing on CON in the fetch block, and adding an explicit 924 handler that calls selectInvoiceDetails to recover the existing receipt instead of failing.

opw-6105693

Forward-Port-Of: odoo/enterprise#115649

**Steps to reproduce:**

- Download the German language
- Set the restaurant to QR + Ordering
- Set the Service at Table, pay after each order
- Set the language to German
- Go to the Self and order something while the language is German
- Chose table 12
- Go to the kitchen display
- The title is truncated, meaning we can't see the table number

**Why the fix:**

If the title is more than 150px it will be truncated and "..." will replace the table number. This has been introduced in 
ed5b010dc7b5c11bbbc8513c1edb0ec4f58778c1 but not being able to see the table number might be bad as some people would need to spend time trying to figure out which table the order is for, instead of just having to look at the kitchen display.

We now revert this change to break to a new line in the case where the card title is too long, so we can always see the table number.

Before:
<img width="317" height="156" alt="image" src="https://github.com/user-attachments/assets/25e76026-bdad-4639-9dfc-0d75ffa8d8c8" />

Afer:
<img width="329" height="174" alt="image" src="https://github.com/user-attachments/assets/f387dd5f-96d3-4148-bc76-215393c76e67" />


opw-6096111

Forward-Port-Of: odoo/enterprise#116594
Forward-Port-Of: odoo/enterprise#114859

### Steps to reproduce:

- In the settings enable "Packages"
- Create a storable product A and put 1 unit in a package P in stock
- Inventory > Products > Packages > open your package P
- Set a parent package PP as container
- Inventory > Operations > Adjustments > Physical Inventory
- Select you product line for A > Request a count (from the control panel button)
- Enable Show Expected Quantity and confirm
- Go to the barcode app > Count Inventory (1)
- scan your parent package PP
#### > traceback: Uncaught Promise > Cannot create property 'inventory_quantity' on boolean 'false'

### Cause of the issue:

When the Package scan is processed, we loop over all quants related to it:
https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L566-L569 https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L602-L617
And for each of these we try to find an existing line representing the quant to update or we do create a new line. Now, the issue, is that the subpackages of the quant are not provided to find the quant candidate line to update. As such, no line is found we enter the else clause and try to createa a NewLine:
https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L617-L627 This time however, the appropriate subpackage (the one of the quant) is provided to the arguments. And, since the line representing this quant is already existing, the `_createNewLine` will return False: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L393-L399 https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L423
This leads to a traceback at the end of the else close since `false.inventory_quantity` doe not make sense (Cannot create property 'inventory_quantity' on boolean 'false') https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L626-L627

Fix:

We adapt the `_processPackage` of the `BarcodeQuantModel` to mimic the existing 'update' behavior on the `BarcodePickingModel`: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_picking_model.js#L2110-L2133
Note that UOM converstion should not be required since quants are already uniformly expressed in the product uom:
https://github.com/odoo/odoo/blob/30b4edace6b0859cb1b1ba4f7f2ea80ba5398e3d/addons/stock/models/stock_quant.py#L52-L54

opw-5864591

Forward-Port-Of: odoo/enterprise#116715

**Steps to reproduce:**
- Create a new marketing campaign with two activities
- Set them to occur some number of days after the beginning
- Save the campaign and start it
- Modify one of the activities to occur some number of days after the
other activity and save
- Modify the child activity by changing the number of days after its
parent that it should run and save
- An error will be thrown

**Issue:**
The trace related to the child activity has no parent when trying to reschedule it in `_update_schedule_date`. This causes an issue when trying to get the first mailing_trace_ids using index 0 in this line:
`base_dt_str = trace.parent_id.schedule_date or trace.parent_id.mailing_trace_ids[0].write_date or trace.participant_id.create_date`

**Fix:**
Prevent the activity hierarchy to be modified on started campaigns.
We also change the indexing to avoid further out of range issue and
properly default on the participant create value.

Trying to match existing traces to their parents has too many edge cases when trying to avoid duplicates, and might often need to reset the whole trace chain to work properly. This approach avoids user mistakes on running
campaigns, but if a user tries to launch a test (even on draft campaign) he won't be able to modify the hierarchy further without deleting/recreating some activities/traces. So we should ignore this for test traces, but it could
impact the behavior between test and actual executions.

opw-5362978

Forward-Port-Of: odoo/enterprise#107556

Issue:
----------------------------------------
When having an employee with `l10n_us_filing_status` not in `['single', 'jointly']` and evaluating the rule parameter `l10n_us_qualified_overtime_deduction_cap` an error occurs.

Cause:
----------------------------------------
`l10n_us_filing_status` can have 5 values: `['single', 'jointly', 'separately', 'head', 'survivor']` But only `['single', 'jointly']` are defined for `l10n_us_qualified_overtime_deduction_cap` ([src](https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/l10n_us_hr_payroll/data/hr_rule_parameters_data.xml#L48)).

When running the rule "Qualified Overtime", the custom Python crashes because we read a key that is not there:

https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/l10n_us_hr_payroll/data/hr_salary_rule_data.xml#L56

Solution:
----------------------------------------
In the custom Python condition, we first check if the key is there.

The custom Python computation also tries to read the key, but it is run only if the condition is validated. So we don't need to change it.

Also fixed indentation of test 069.

opw-6129657

Forward-Port-Of: odoo/enterprise#116913
Forward-Port-Of: odoo/enterprise#115754

Before commit:
The Norwegian VAT XML export fails Skatteetaten validation due to incorrect
decimal formatting, mathematical rounding mismatches between base and tax
amounts, missing mandatory legal notes, and invalid KID number formats.

Fix:
To strictly follow Skatteetaten validation rules for the Norway VAT XML, the
following changes were implemented:
- Ensured standard rates drop the decimal (e.g, `25.0` to `25`), and formatted 
  fractional rates like `11.11` to `11,11` in XML.
- Rounded down the `tax_amount` to align precisely with government mathematical
  expectations.
- `base_amount` converted into absolute value to ensuring the calculation
  (`base * rate = tax`) resolves perfectly.
- Add the mandatory `<merknad>` explaining the reverse charge method for codes
  81, 83, 86, 88, and 91.
- Clean the `company_kid` by safely stripping the 'NO' prefix, and 'MVA' suffix.

Expect:
The generated XML payload now adheres perfectly to Skatteetaten's strict
structural and mathematical rules, allowing the VAT return to pass government
validations successfully.

Related Community PR: https://github.com/odoo/odoo/pull/258390

Task-6033027

Forward-Port-Of: odoo/enterprise#116962
Forward-Port-Of: odoo/enterprise#110792

Currently an error occurs when the user removes the Source Entity Id Type on Super Contributions.

**Steps to Reproduce:**
 - Install `l10n_au_hr_payroll_account` with demo data.
 - Switch to an `Australian` company.
 - Go to `Payroll` > `Reporting` > `Australia` > `Super Contributions`.
 - Open an existing record or create a new one.
 - Remove the `Source Entity Id Type` value and click anywhere.

`ValueError: Compute method failed to assign l10n_au.super.stream(<NewId origin=1>,).source_entity_id`

After [change] in the selection field behavior, when the user removes the Source Entity Id 
Type, the compute method is triggered to compute the Source Entity ID. However, the 
condition in the compute method is not match, so no value is assigned. As a result, 
the method fails and raises an error.

This commit ensures that if the condition is not match, the Source Entity ID is explicitly 
set to False.

[1]- https://github.com/odoo/enterprise/blob/9d523d7aabffda277e1ef734caf2b0e434545dca/l10n_au_hr_payroll_account/models/l10n_au_super_stream.py#L61-L65

[change]: https://github.com/odoo/odoo/pull/214422/changes/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef

__

## Short functional explanation of the error
When we have a subscription product that has already been sold. If we try to import a product with the same ID but where we change the subscription type of the product, the import is executed without issue. However, this leads to undesired behavior:
when we go to the product page and try to manually change the subscription type (set it back to subscription), the change is not applied as a warning is raised.

## Reproduction Steps
Make sure you have debug mode enabled.
1. Create a product, and check the Subscription box.
2. Click on Orders and create a Quotation with this product, then confirm.
3. Go to Products > Products. Select the list view and search for the product you just created. Select it, and click Actions > Export.
4. Check the import compatible field. Select the fields to export: name, id and recurring_invoice. Upon exporting, a file is downloaded.
5. Access that file and change the recurring_invoice to FAUX or FALSE if your computer is in English. Save the changes.
6. Unselect the product and click on the cog, top right > Import. Click on Upload Data File and select the file that you have downloaded upon exporting, then import.

### Expected behavior
A user warning is raised: we shouldn't be able to change the subscription type of the product when it has already been sold.

### Unexpected behavior
The import is processed normally. Then, when we access the product page, and try to check the Subscriptions box again, a warning is raised.

## Origin of the issue
Nothing prevents the import from occurring in that case.

__
opw-6143789

Forward-Port-Of: odoo/enterprise#117046
Forward-Port-Of: odoo/enterprise#115046

Currently the query to get the closing difference account move is done by searching for the reference of the move, which is not very efficient. This commit optimizes this query by adding the journal to the search criteria, which allows us to benefit from the index on the journal_id field.

Here is an example of the before after on a database with 39 million account_move records. Meanwhile only 10-20K account_move are linked to specific journals used in POS payment methods.

All measures are performed with a warmed up cache

[Explain Before](https://explain.dalibo.com/plan/h8edf56c09d7dfd7)

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of am</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>38982635</td>
			<td>~17s</td>
			<td>~22ms</td>
		</tr>
	</tbody>
</table>

[Explain After](https://explain.dalibo.com/plan/be2397f176a6b29d)

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

Forward-Port-Of: odoo/odoo#262148

**Problem:**
account move created by stock valuation layer 
does not take analytic account from PO

**Steps to reproduce:**
- make sure you have at least one analytic account
- create a storable product with categ standard automated
- set a positive cost
- create a PO for 1 quantity 
- on the PO line of the product, in the analytic distribution 
column (might need to be unfiltered) set an analytic account
- confirm PO and validate receipt
- click on the valuation smart button and on the book widget
of the stock valuation layer

**Current behavior:**
the account move lines have no analytic distribution

**Expected behavior:**
The account move lines should inherit the analytic account 
from the purchase order line like it's the case for the bill.

For the analytic distribution of the Bill, the selection is : 
1) take analytic distribution from PO if one
2) if not, take from distribution model if there is one
3) empty

Currently for the account move lines of the svl the selection is: 
1) take from distribution model if there is one
2) empty
But we should use same selection as for the bill

**Cause of the issue:**
When setting the analytic distribution we first 
try to use the one from PO/SO by calling 
_related_analytic_distribution()
https://github.com/odoo/odoo/blob/4cc1e6884be673523f768d5ec471a1ffa19c5fb4/addons/account/models/account_move_line.py#L1157
But since the account move lines have no purchase_line_id
no analytic distribution will be returned
https://github.com/odoo/odoo/blob/4cc1e6884be673523f768d5ec471a1ffa19c5fb4/addons/purchase/models/account_invoice.py#L540-L545


opw-6022695

Steps to reproduce
1. In a French company with Intrastat enabled, set up a product whose commodity code has a CN supplementary unit (e.g. 8802 30 00, "p/st") and set `intrastat_supplementary_unit_amount` on it.
2. Post EU customer invoices for that product.
3. Export the DEBWEB2 XML from the Intrastat report.

Issue
The FR export collapses engine rows a second time in `_group_items`, because the DEBWEB2 format groups more aggressively than the SQL. The aggregator only declares `value` and `weight`: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/models/account_intrastat_report.py#L308-L313 Items are then rebuilt as `dict(zip(grouping_key, key_tuple)) | grouped_item_values`. `SU_code` survives (it is in the grouping key), but the numeric `supplementary_units` is in neither side and is silently dropped as soon as two engine rows merge. The template then skips the element because of its `t-if="item.get('supplementary_units')"` guard: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/data/intrastat_export.xml#L61

opw-6139657

Steps to reproduce
-----
- Modules: Sale, Purchase, Mrp, Accounting
- Enable automatic accounting & anglo-saxon valuation
- Create an AVCO Product category (AVCO automatic valuation)
- Create a Kit product storable & AVCO
    - Kit bom
    - Comp as a component (storable & AVCO)
- Settings > Decimal Accuracy > Product Price > set to 4 digits
- Purchase 3 units of Comp at 3.3333 piece & validate reception
- Make 2 sales for 1 unit of Comp each & validate both deliveries
- Create a SO for 1 Kit and 1 Comp & confirm
- Create & confirm invoice
- Go to the delivery, force quantity on the component and try to validate delivery

> Error message: "You are trying to reconcile some entries that are already reconciled."

/!\ Fun(?) fact: this error doesn't occur if the order of the moves is inverted.

Cause
-----
When the purchase delivery is validated, a stock valuation layer is created for 3 units with a value of 10. As they are sold individually, these 3 units generate a valuation layer for 3.33 per unit summing to 9.99.

When we validate the last delivery, the 0.01 difference is detected and an adjustment is made on the valuation layer in `_prepare_out_svl_vals`.

However this adjustment is made for the product when the invoice line concerns the kit. As a result, the first reconciliation fails and the line is added to the list to be reconciled later.

Then, when handling the line for COMP2, it will successfully reconcile the lines while it is still in the pool to be reconciled, resulting in an error when attempting to reconcile it later.

This is caused by `_stock_account_anglo_saxon_reconcile_valuation` where the `product_stock_moves` only contains the kit move when called with the kit product as argument, but it contains both moves when called with the component itself as argument. This leads to the same AML being reconciled twice.

https://github.com/odoo/odoo/blob/f0b9f4c234cd0101f5cb259e58620e1cf65bb2b7/addons/stock_account/models/account_move.py#L222-L225

-----
Ticket:
opw-5722072

Forward-Port-Of: odoo/odoo#258013