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

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