- This aggregation expression used to have 'cross_report' as subformula. Though, it was useless (since the aggregation only uses term from the same report), and the subformula was removed from the data file without explicitly resetting it to False. This became a problem in 18.3, because the cross_report syntax changes. Because of that, a migrated report failed to open, since it still was using the old syntax on that expression. We fix that by explicitly emptying the subformula.

see https://github.com/odoo/odoo/pull/193106

```python3
Opération invalide

Dans le rapport "Section I (LU)", à la ligne "472 - Autres Ventes / Recettes", avec le libellé "balance",
Le format de l'expression de rapport croisé est invalide.

Format attendu : cross_report(<report_id>|<xml_id>)
Exemple : cross_report(my_module.my_report) ou cross_report(123)
```

opw-6103170
upg-4166654(lu)
upg-4163103(it)
upg-4175631(ug)
upg-4177165(es)

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#258826

This error occurs when clicking on any cell for `Undistributed Profits/Losses` in the `Trial Balance` report.

Steps to reproduce:
- Install `Accounting` module
- Create `Journal Entry` with past-year `Accounting Date` (eg: 31-12-2025) and include one `Journal Items` for  `Undistributed Profits/Losses`
- Open `Trail Balance` report and click on any cell for `Undistributed Profits/Losses`

Traceback:
`KeyError: 'report_line_id'`

Before this [commit], we were returning fields with `null/None` values. After the commit, fields containing `null/None` [value] are removed, and only fields with valid values are returned. As a result, when the `dispatch_report_action` function is called, the `report_line_id` is missing in `params`.

[commit]: https://github.com/odoo/enterprise/pull/102808/changes/b92dc397bef029472a40223f51b611cdf5b631dc
[value]: https://github.com/odoo/enterprise/blob/626b8157bcea2e3843cd9d5d0c0036e302b8e5ce/account_reports/utils/report_data_objects.py#L42-L43

sentry-7372351871
opw-6119913

Forward-Port-Of: odoo/enterprise#113421

Currently, an error occurs when retrieving account report information.
```
  File "/home/odoo/odoo18/enterprise/account_reports/models/account_report.py", line 1475, in _create_hierarchy
    render_lines(root_account_groups, current_level, root_line_id, skip_no_group=False)
  File "/home/odoo/odoo18/enterprise/account_reports/models/account_report.py", line 1373, in render_lines
    child_line.update
    ^^^^^^^^^^^^^^^^^
AttributeError: 'AccountReportLineData' object has no attribute 'update'
```
After the [recent commit], all lines, columns, format_params, and annotations are converted into custom objects (AccountReportLineData). However, the code still attempts to use the update() method on these objects, which raises an error [1] since AccountReportLineData does not have an update method.

This commit ensures that the update_value() method is used to update AccountReportLineData objects, as intended, like here [2].

[recent commit]: https://github.com/odoo/enterprise/commit/6608d5c21a7fb9d57786c2a7618b878e244bd420

[1]- https://github.com/odoo/enterprise/blob/cde4e05de82476655764f8c9fe8734416d4a35bf/account_reports/models/account_report.py#L1373-L1377

[2]- https://github.com/odoo/enterprise/blob/cde4e05de82476655764f8c9fe8734416d4a35bf/account_reports/models/account_report.py#L6565

sentry-7403925422

Forward-Port-Of: odoo/enterprise#113668

Issue 1:
---
Capturing/voiding transaction is failing with the error:
`The payment provider rejected the request. Original pspReference required for this operation`

Steps to reproduce:
1- Setup Adyen payment provider.
2- Enable `Capture amount manually`.
3- Create a SO and confirm.
4- Generate a payment link and pay.
5- In SO, capture the full amount.

Cause:
---
After https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97, in the payment `_void()`/`_capture()`, a child tx is created.
However the child tx is missing the `provider_reference` required to send the payment provider.


Issue 2:
---
The child tx created for capture/void is always remains in draft state.

Cause:
---
This is reproduced after https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97 which we create a child tx in capture/void. But in `_search_by_reference` which is called by webhook to find the tx, we are returning the source tx. As a result only the state of the source tx is changed.

opw-6120846
opw-6120071

Forward-Port-Of: odoo/odoo#259223

### Issue before this commit:
When importing vendor bills from XML files containing a pension fund (e.g., type TC08), the pension fund tax was not correctly applied to the invoice lines. As a result, the imported bills were missing the expected tax association.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Set the pension fund type as TC08 (or another one is also fine) in the Advanced Tab of 4% F.Pens. tax
3. Try to upload an XML for vendor bills with a TC08 tax
4. The tax is not associated

### Cause of the issue:
The issue was caused by the handling of the VAT rate (AliquotaIVA) when its value was 0.00. The code incorrectly treated this value as falsy, preventing the correct identification and assignment of the pension fund tax during the import process.

### Reason to introduce the fix:
The fix ensures that a VAT rate of 0.00 is correctly interpreted as a valid value rather than being ignored. This allows the system to properly detect and apply the pension fund tax during XML import, ensuring accurate tax assignment and compliance with expected accounting behavior.

opw-6093352

Forward-Port-Of: odoo/odoo#258341

- This aggregation expression used to have 'cross_report' as subformula. Though, it was useless (since the aggregation only uses term from the same report), and the subformula was removed from the data file without explicitly resetting it to False. This became a problem in 18.3, because the cross_report syntax changes. Because of that, a migrated report failed to open, since it still was using the old syntax on that expression. We fix that by explicitly emptying the subformula.

see https://github.com/odoo/odoo/pull/193106

```python3
Opération invalide

Dans le rapport "Section I (LU)", à la ligne "472 - Autres Ventes / Recettes", avec le libellé "balance",
Le format de l'expression de rapport croisé est invalide.

Format attendu : cross_report(<report_id>|<xml_id>)
Exemple : cross_report(my_module.my_report) ou cross_report(123)
```

opw-6103170
upg-4166654(lu)
upg-4163103(it)
upg-4175631(ug)
upg-4177165(es)

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#258826

Currently, an error occurs when user tries to open unassigned opportunities assigned to a team.

Steps to replicate:
- Install `crm` with demo.
- Open `CRM > Sales > Teams` and click `Sales` team.
- Remove the `salesperson` from any lead, then return to `Teams` via breadcrumbs.
- On the kanban card for Sales, click “Unassigned Leads”.

Error:
```
  File '/home/odoo/src/odoo/saas-19.2/addons/crm/models/crm_team.py', line 728, in action_open_unassigned_opportunities
    context = self.env['crm.lead']._evaluate_context_from_action(action)
  File '/home/odoo/src/odoo/saas-19.2/addons/crm/models/crm_lead.py', line 727, in _evaluate_context_from_action
    return literal_eval(context_str)
  File '/home/odoo/src/odoo/saas-19.2/odoo/_monkeypatches/ast.py', line 28, in literal_eval
    return orig_literal_eval(expr)
  File 'ast.py', line 66, in literal_eval
    node_or_string = parse(node_or_string.lstrip(' \t'), mode='eval')
  File 'ast.py', line 52, in parse
    return compile(source, filename, mode, flags,
IndentationError: unexpected indent (<unknown>, line 8)
```

Cause:
- Error occurs after a recent [PR].
- As we called `literal_eval()` on the context string that we passed on to the `act_window` [1], it tries to parse the string using python like rules, the context is received as this:

```
"{\n 'search_default_team_id': [False],
 \n'default_team_id': False,
 \n'default_type': 'opportunity',
 \n'default_user_id': 2,
 \n'show_lead_gen_button': True
 }\n       "
    ^^^^^^^
```

- The extra whitespace/indentation (coming from the `act_window` context definition) makes the string invalid for strict parsing, causing `literal_eval()` to fail.

- Additionally, in the above given context string the `search_default_team_id` and `default_team_id`are  both `False`  because we called `_evaluate_context_from_action()` method on an empty recordset and when we try to [substitute] `active_id` with `self.id`(which is False because we dont have any record) we get another JS Error that is caused by not receiving any results for the search default on team.

Solution:
- Using `strip()` function removed the extra whitespaces.
- Passed the `team_id` through context (as we cant add new parameters to a function in stable) and assigned it in place of `active_id`.

[1]: https://github.com/odoo/odoo/blob/746ea418da2af2a6d36daea4dc544bdf3bc28495/addons/crm/views/crm_team_views.xml#L41-L48
[PR]: https://github.com/odoo/odoo/pull/240202/changes#diff-595d3dbbabdc4f766a380a320c1c1a43b143385bc7487c7275e80f76a9fbabc2R724
[substitute]: https://github.com/odoo/odoo/blob/e00dd21880c3c4e5c22d65567c700e02541f7259/addons/crm/models/crm_lead.py#L726

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

*: timesheet_grid,timesheet_grid_hr_attendance,helpdesk_timesheet

# [FIX] timesheet_grid_hr_attendance: open timesheet systray on check-in
Before this commit, the user had to re-open the systray in order to open the timesheet systray. Now, it is directly showed to the user upon check-in, without having the systray being closed automatically.

# [FIX] web_enterprise: required project is not underlined bolder when hovered
In this commit, we ensure that the border under the project in the timesheet inline form is bolder when hovered.

# [FIX] timesheet_grid,helpdesk_timesheet: prefill timesheets in systray
In this commit, we enable timesheets in the systray to be prefilled with project, tasks, and helpdesk tickets if the user opens the systray from any of these views, provided that the fields were empty.

Further, say a project is already set, then any opened task from that project will also be populated upon opening the systray under the condition that both projects match. The same reasoning applies to helpdek tickets.

# [FIX] sale_timesheet_enterprise: conditionnal class on timesheet timer
After closing the systray, the 'billable' radio button ended up on a new line because the class on the timer was not correctly removed.

With this commit, the button will remain on the same line as the timer, even after closing and re-opening the systray.

# [FIX] sale_timesheet_enterprise: hide assistant button
This commit adds conditions to display the button opening the timesheet assistant. Prior to this, the button was displayed even if the setting is not active on the user.

See odoo/odoo#257930

task-6088779

Steps to reproduce:
---------------------------------
1. Install Calendar module with demo
2. For both Users: User > Preferences > Notifications > In Odoo
3. Log in through Admin > Calendar > New meeting
4. Set a start time in the near future
5. Add Marc Demo as an attendee
6. Under Options > Reminders, add a reminder that triggers shortly before the meeting (e.g., 15 minutes)
7. Save the meeting
8. Log in as Marc Demo in another browser window
9. Wait until the reminder time is reached

Observation:
---------------------------------
The reminder notification is displayed for Marc Demo. The Administrator (Mitchell Admin) does not receive any notification.

Issue:
---------------------------------
In `_notify_next_alarm`, the domain
`('group_ids', 'in', self.env.ref('base.group_user').ids)`
 was used to filter internal users. However, the admin user does not have
`base.group_user` directly in their `group_ids`, it is only present in `group_ids.all_implied_ids` (inherited through group hierarchy). This caused the admin user to be excluded from the user search, so no bus alarm notification was sent to them.

Solution:
---------------------------------
The `share` field on `res.users` correctly identifies internal users (`share=False`) vs portal/public users (`share=True`) by checking the full group hierarchy, including implied groups. This ensures the admin (and all internal users) receive alarm notifications while still excluding portal and public users.
https://github.com/odoo/odoo/blob/b261223c8e15c412a06a0d938d217bdf0ab9f9ff/odoo/addons/base/models/res_users.py#L459-L464

opw-6010337

Forward-Port-Of: odoo/odoo#255263

### Issue before this commit:
When importing vendor bills from XML files containing a pension fund (e.g., type TC08), the pension fund tax was not correctly applied to the invoice lines. As a result, the imported bills were missing the expected tax association.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Set the pension fund type as TC08 (or another one is also fine) in the Advanced Tab of 4% F.Pens. tax
3. Try to upload an XML for vendor bills with a TC08 tax
4. The tax is not associated

### Cause of the issue:
The issue was caused by the handling of the VAT rate (AliquotaIVA) when its value was 0.00. The code incorrectly treated this value as falsy, preventing the correct identification and assignment of the pension fund tax during the import process.

### Reason to introduce the fix:
The fix ensures that a VAT rate of 0.00 is correctly interpreted as a valid value rather than being ignored. This allows the system to properly detect and apply the pension fund tax during XML import, ensuring accurate tax assignment and compliance with expected accounting behavior.

opw-6093352

Forward-Port-Of: odoo/odoo#258341

- This aggregation expression used to have 'cross_report' as subformula. Though, it was useless (since the aggregation only uses term from the same report), and the subformula was removed from the data file without explicitly resetting it to False. This became a problem in 18.3, because the cross_report syntax changes. Because of that, a migrated report failed to open, since it still was using the old syntax on that expression. We fix that by explicitly emptying the subformula.

see https://github.com/odoo/odoo/pull/193106

```python3
Opération invalide

Dans le rapport "Section I (LU)", à la ligne "472 - Autres Ventes / Recettes", avec le libellé "balance",
Le format de l'expression de rapport croisé est invalide.

Format attendu : cross_report(<report_id>|<xml_id>)
Exemple : cross_report(my_module.my_report) ou cross_report(123)
```

opw-6103170
upg-4166654(lu)
upg-4163103(it)
upg-4175631(ug)
upg-4177165(es)

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#258826

Steps to reproduce:
---------------------------------
1. Install Calendar module with demo
2. For both Users: User > Preferences > Notifications > In Odoo
3. Log in through Admin > Calendar > New meeting
4. Set a start time in the near future
5. Add Marc Demo as an attendee
6. Under Options > Reminders, add a reminder that triggers shortly before the meeting (e.g., 15 minutes)
7. Save the meeting
8. Log in as Marc Demo in another browser window
9. Wait until the reminder time is reached

Observation:
---------------------------------
The reminder notification is displayed for Marc Demo. The Administrator (Mitchell Admin) does not receive any notification.

Issue:
---------------------------------
In `_notify_next_alarm`, the domain
`('group_ids', 'in', self.env.ref('base.group_user').ids)`
 was used to filter internal users. However, the admin user does not have
`base.group_user` directly in their `group_ids`, it is only present in `group_ids.all_implied_ids` (inherited through group hierarchy). This caused the admin user to be excluded from the user search, so no bus alarm notification was sent to them.

Solution:
---------------------------------
The `share` field on `res.users` correctly identifies internal users (`share=False`) vs portal/public users (`share=True`) by checking the full group hierarchy, including implied groups. This ensures the admin (and all internal users) receive alarm notifications while still excluding portal and public users.
https://github.com/odoo/odoo/blob/b261223c8e15c412a06a0d938d217bdf0ab9f9ff/odoo/addons/base/models/res_users.py#L459-L464

opw-6010337

Forward-Port-Of: odoo/odoo#255263

Pre-requisites:
---------------
1. Create or duplicate any `hr.applicant` email template.
2. Archive the newly created template.
3. Archive the email template linked to a refuse reason.

Steps to reproduce:
-------------------------
1. Install hr_recruitment.
4. Go to Recruitment > Applications > All Applications and open an applicant.
5. Click on the "Refuse" button to open the refuse wizard.
6. Click on the "Email Template"  and click on 'Search More'
7. Observe available templates

Issue:
-------
If a refuse reason is linked to an archived email template,
the wizard automatically pre-fills that archived template

Cause:
----------
The `_compute_template_id` method automatically assigns
the template from the refuse reason without checking whether
the template is active, which allows archived templates to be
pre-filled in the wizard.
https://github.com/odoo/odoo/blob/aa2a7c0e5a5de970cdb8f6a7ba9f02ad75cf5078/addons/hr_recruitment/wizard/applicant_refuse_reason.py#L91-L96


Solution:
-----------
- Update `_compute_template_id` to ensure only active templates are
  automatically assigned.


opw-5974244




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

Forward-Port-Of: odoo/odoo#257580
Forward-Port-Of: odoo/odoo#251186

**[FIX] handle Turkey timezone when tzdata-legacy not installed**

In #236660 we switched from pytz to zoneinfo.

The library `pytz` has `Turkey` in **pytz.all_timezones_set**. 
On the other hand starting from ubuntu 24.04 as tzdata was split and `Turkey` was [moved](https://documentation.ubuntu.com/release-notes/24.04/#tzdata-package-split) out of tzdata to tzdata-legacy. 

If we run a db which has reference to `Turkey` timezone, on a server which is ubuntu 24.04 and tzdata-legacy not installed, we will get an error as we did not have fallback for `Turkey` while we have for `Türkiye`. Because zoneinfo will not have `Turkey` in `zoneinfo.available_timezones()`

Issue was discovered during upgrade of db which has res.partners with timezone=`Turkey` from 19.0 to saas~19.1. The upgrading docker container was nobel and it did not have tzdata-legacy.

For fixing the issue we added fallback for `Turkey`. 
Tbh I do not think we need a fallback for `Türkiye` but I wanted to not change the old behaviour.


###

**[FIX] handle America/{Catamarca,Godthab} timezones**

As we moved from `pytz` to `zoneinfo` in **saas~19.1**
we have 2 more timezones which were existing in `pytz`
but not in `tzdata` adn we do not have fallback for them.
They are in `tzdata-legacy`:
- America/Catamarca
- America/Godthab

We added fallback for them.
We already have a failing upgrade request because of
America/Catamarca.

Turkey:
```
   File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 742, in _compute_field_value
    return super()._compute_field_value(field)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/addons/mail/models/mail_thread.py", line 495, in _compute_field_value
    return super()._compute_field_value(field)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 4271, in _compute_field_value
    determine(field.compute, self)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 83, in determine
    return needle(*args)
           ^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 503, in _compute_recurrence
    event_values = event._get_recurrence_params()
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 1341, in _get_recurrence_params
    event_date = self._get_start_date()
                 ^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 1573, in _get_start_date
    return start.replace(tzinfo=UTC).astimezone(ZoneInfo(self.event_tz)).date()
                                                ^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/_monkeypatches/zoneinfo.py", line 130, in __new__
    z = super().__new__(cls, key)
        ^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/lib/python3.12/zoneinfo/_common.py", line 24, in load_tzdata
    raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
 zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key Turkey'
```

Catamarca:
```
Traceback (most recent call last):
   File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 335, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 348, in mock_action
    return self.mock_act_window(action)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 508, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 541, in mock_view_form
    [data] = record.read(fields_list)
             ^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 2735, in read
    self._origin.fetch(fields)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 3067, in fetch
    fetched.mapped(field_name)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 5479, in mapped
    return [getter(record) for record in records]
            ^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 1794, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 1965, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 4271, in _compute_field_value
    determine(field.compute, self)
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 83, in determine
    return needle(*args)
           ^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/addons/base/models/res_users.py", line 455, in _compute_tz_offset
    user.tz_offset = datetime.datetime.now(ZoneInfo(user.tz or 'UTC')).strftime('%z')
                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/_monkeypatches/zoneinfo.py", line 130, in __new__
    z = super().__new__(cls, key)
        ^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/lib/python3.12/zoneinfo/_common.py", line 24, in load_tzdata
    raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
 zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key America/Catamarca'
```

tbg-2529

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

### Steps to reproduce:
	- Install project_timesheet_forecast module
	- Configure your database to have a far timezone (Montevideo/Uruguay in my case)
	- Create a public holiday starts from 12AM to 11:59PM with a calendar
	- Create a planning slot for a resource that overlap with the public holiday
	- Check the Timesheets / Planning analysis report
	- Group by employees > day 
	**- Check the date of the public holiday and notice there are still planned hours shown**
	- Remove the calendar from the public holidays that we created previously
	- Check the report once again 
	**- Notice the day of the public holiday and the day after has no planned hours**

### Cause:
In the query we are using to exclude the leave days from the report we only exclude the ones that has calendar_id assigned, not taking into consideration that some of the public holiday are general and is not applied to just one working schedule.

Also if we have a leave starting midnight to 11:59PM since we store dates in database as UTC for timezone like Uruguay's one it will shift the end with one day which will introduce inconsistencies

### Fix:
We check if the calendar_id is null on the resource_calendar_leaves and make sure we take timezone of the resource into account when checking the dates of the leaves.

opw-5027070

Forward-Port-Of: odoo/enterprise#111846

**Issue**:
Making a product a kit could prevent confirming deliveries.

**Steps to reproduce**:
- Make sure the account application is installed
- Create a product P without kit
- Create a SO and confirm it
- Make the product P a kit
- Validate the delivery associated to the SO
-> A traceback occurs: the record does not exist anymore

**Cause**:
While confirming the delivery:
https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L168 It first filters which moves are out (`moves_out`). On the move associated with product P, since the kit is not exploded yet: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L172 Then explodes the kit:
https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L174 https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mrp/models/stock_move.py#L357-L361 By doing so, the original move associated to the product P are deleted: https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mrp/models/stock_move.py#L399 Thus, `moves_out` contains moves that no longer exist, and eventually, and eventually while accessing `product_id`: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L179 A traceback is thrown

**Aditionnal information**
Validating a delivery of a kit product whose moves were not exploded will trigger their explosion and require a second validation.
Therefore, no stock valuation errors will be created.

opw-6063602

Forward-Port-Of: odoo/odoo#258403

### Issue before this commit:
When importing vendor bills from XML files containing a pension fund (e.g., type TC08), the pension fund tax was not correctly applied to the invoice lines. As a result, the imported bills were missing the expected tax association.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Set the pension fund type as TC08 (or another one is also fine) in the Advanced Tab of 4% F.Pens. tax
3. Try to upload an XML for vendor bills with a TC08 tax
4. The tax is not associated

### Cause of the issue:
The issue was caused by the handling of the VAT rate (AliquotaIVA) when its value was 0.00. The code incorrectly treated this value as falsy, preventing the correct identification and assignment of the pension fund tax during the import process.

### Reason to introduce the fix:
The fix ensures that a VAT rate of 0.00 is correctly interpreted as a valid value rather than being ignored. This allows the system to properly detect and apply the pension fund tax during XML import, ensuring accurate tax assignment and compliance with expected accounting behavior.

opw-6093352

Forward-Port-Of: odoo/odoo#258341

Steps to reproduce:
---------------------------------
1. Install Calendar module with demo
2. For both Users: User > Preferences > Notifications > In Odoo
3. Log in through Admin > Calendar > New meeting
4. Set a start time in the near future
5. Add Marc Demo as an attendee
6. Under Options > Reminders, add a reminder that triggers shortly before the meeting (e.g., 15 minutes)
7. Save the meeting
8. Log in as Marc Demo in another browser window
9. Wait until the reminder time is reached

Observation:
---------------------------------
The reminder notification is displayed for Marc Demo. The Administrator (Mitchell Admin) does not receive any notification.

Issue:
---------------------------------
In `_notify_next_alarm`, the domain
`('group_ids', 'in', self.env.ref('base.group_user').ids)`
 was used to filter internal users. However, the admin user does not have
`base.group_user` directly in their `group_ids`, it is only present in `group_ids.all_implied_ids` (inherited through group hierarchy). This caused the admin user to be excluded from the user search, so no bus alarm notification was sent to them.

Solution:
---------------------------------
The `share` field on `res.users` correctly identifies internal users (`share=False`) vs portal/public users (`share=True`) by checking the full group hierarchy, including implied groups. This ensures the admin (and all internal users) receive alarm notifications while still excluding portal and public users.
https://github.com/odoo/odoo/blob/b261223c8e15c412a06a0d938d217bdf0ab9f9ff/odoo/addons/base/models/res_users.py#L459-L464

opw-6010337

Forward-Port-Of: odoo/odoo#255263

This error occurs when clicking on any cell for `Undistributed Profits/Losses` in the `Trial Balance` report.

Steps to reproduce:
- Install `Accounting` module
- Create `Journal Entry` with past-year `Accounting Date` (eg: 31-12-2025) and include one `Journal Items` for  `Undistributed Profits/Losses`
- Open `Trail Balance` report and click on any cell for `Undistributed Profits/Losses`

Traceback:
`KeyError: 'report_line_id'`

Before this [commit], we were returning fields with `null/None` values. After the commit, fields containing `null/None` [value] are removed, and only fields with valid values are returned. As a result, when the `dispatch_report_action` function is called, the `report_line_id` is missing in `params`.

[commit]: https://github.com/odoo/enterprise/pull/102808/changes/b92dc397bef029472a40223f51b611cdf5b631dc
[value]: https://github.com/odoo/enterprise/blob/626b8157bcea2e3843cd9d5d0c0036e302b8e5ce/account_reports/utils/report_data_objects.py#L42-L43

sentry-7372351871
opw-6119913

Forward-Port-Of: odoo/enterprise#113421

Currently, an error occurs when retrieving account report information.
```
  File "/home/odoo/odoo18/enterprise/account_reports/models/account_report.py", line 1475, in _create_hierarchy
    render_lines(root_account_groups, current_level, root_line_id, skip_no_group=False)
  File "/home/odoo/odoo18/enterprise/account_reports/models/account_report.py", line 1373, in render_lines
    child_line.update
    ^^^^^^^^^^^^^^^^^
AttributeError: 'AccountReportLineData' object has no attribute 'update'
```
After the [recent commit], all lines, columns, format_params, and annotations are converted into custom objects (AccountReportLineData). However, the code still attempts to use the update() method on these objects, which raises an error [1] since AccountReportLineData does not have an update method.

This commit ensures that the update_value() method is used to update AccountReportLineData objects, as intended, like here [2].

[recent commit]: https://github.com/odoo/enterprise/commit/6608d5c21a7fb9d57786c2a7618b878e244bd420

[1]- https://github.com/odoo/enterprise/blob/cde4e05de82476655764f8c9fe8734416d4a35bf/account_reports/models/account_report.py#L1373-L1377

[2]- https://github.com/odoo/enterprise/blob/cde4e05de82476655764f8c9fe8734416d4a35bf/account_reports/models/account_report.py#L6565

sentry-7403925422

Forward-Port-Of: odoo/enterprise#113668

Related Ticket: https://www.odoo.com/odoo/project/49/tasks/6037414

### Description of the issue/feature this PR addresses:
Generating the "VAT Books" Excel report causes severe performance bottlenecks and MemoryError crashes on databases with a massive volume of invoice lines. This PR introduces strict memory management and query optimizations to prevent server crashes and drastically speed up the XLSX export process.

### Current behavior before PR:
When exporting the VAT Books report for a large dataset, the system attempts to hold the entire workbook structure in RAM. Additionally, the ORM unnecessarily prefetches fields when iterating over the account.move.line recordset and performs excess sub-queries to look up move_type for journal entries. This combination results in massive memory consumption, slow load times, and eventual server crashes.

### Desired behavior after PR is merged:
The VAT Books report generates successfully and efficiently, even on massive databases, with a significantly reduced memory footprint. Specifically:
- The ORM bypasses cache bloat by disabling field prefetching (prefetch_fields=False) during the recordset iteration.
- The query execution is optimized by changing the search domain from move_type to move_id.move_type, leveraging the existing join table rather than triggering expensive sub-queries.

### Benchmark:
The model is iterating through ~1.1M journal items when generating the full report. 

For Memory:
| # Input Data | Before PR | After PR|
| -------- | -------- | -------- |
| ~7,800 journal items | 1.4GB| 202 MB |
| ~32,000 journal items | MemoryError | 278 MB |
| ~141,500 journal items | MemoryError | 760 MB |
| ~1.1M journal items | MemoryError | 1.4 GB |

For Speed:
| # Input Data | Before PR | After PR|
| -------- | -------- | -------- |
| ~7,800 journal items | 2 min | 1.5s |
| ~32,000 journal items | MemoryError | 4s |
| ~141,500 journal items | MemoryError | 12s |
| ~1.1M journal items | MemoryError | 56s |

### Reference

opw-6037414

-----------------------------------------------------------------
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/enterprise#112230

In Mexico, the basic salary must be calculated based on the total calendar days of the period. This ensures that both worked days and non-working days (e.g. Sundays) contribute equally to the total payment. This calculation also applies to the daily schedule, as the proportional daily wage must be divided equivalently across the hours of the day.

Current behavior:
When an employee has an unpaid leave, the basic salary is incorrectly prorated using only the registered days/hours.
Example: For a monthly wage of 30,000 MXN in a month with 22 scheduled days (21 attendances + 1 unpaid leave), the implicit daily rate becomes 1,363.63 (30,000 / 22). This leads to an incorrect basic salary of 28,636.36 MXN for the days worked. This also happens with unpaid leave for x hours, e.g., for 2 hours, the unpaid leave is calculated as 2 hours * (30,000 / (22 days * 8 hours)) = 340.90 MXN, which is incorrect.

Expected behavior:
The basic salary should be derived from the full period (e.g., 30 days for a month, 15 for a bi-weekly period).
Example: For a 30,000 MXN wage, the daily rate should be 1,000 MXN (30,000 / 30 days). If there is 1 unpaid leave, the basic salary should be 29,000 MXN (29 days * 1,000 MXN), regardless of the number of scheduled working days in the calendar. For unpaid leaves by hours, e.g., for 2 hours, the unpaid leave should be calculated as 2 hours * (30,000 / (30 days * 8 hours)) = 250.00 MXN.

To achieve this, the calculation of the days in the `_get_worked_day_lines` is:
* Adjust worked days/hours for out-of-contract entries where necessary, ensuring that rest days(Sundays) are included in the count.
* Get all worked hours in the lines.
* Calculate the number of days to pay based on the total hours and the hours per day.

### Case: payslip does not cover the complete pay period
Current behavior:
If a payslip is created for a partial period, the total amount is the full period wage.

Expected behavior:
The total amount should be pro-rated based on the days of the period. For example, if a payslip is created for 25 days(with a monthly schedule pay), the total amount should be the daily salary multiplied by 25 days.

To achieve this, `_compute_amount` is updated to calculate the wage based on the `l10n_mx_daily_salary`.

Changes on tests:
* Add:
  * `test_monthly_payslip_with_partial_leave`, `test_partial_payslip`, `test_partial_payslip_new_hire_month_31_days` and `test_partial_payslip_new_hire_month_28_days`.
  * `test_hourly_payslip_by_attendance` to validate when `Work Entry Source` is set to "attendance".
* Update:
  * `test_hourly_payslip`, `test_monthly_payslip` and `test_partial_payslip_new_hire` to align with the new calculation.
  * Adjust payslips dates to match the `schedule_pay` in `test_regular_payslip_subsidy` and `test_weekly_schedule_pay_no_code`
  * Fix a one-day difference in `TestMxEdiHrPayrollCommon`(16 days instead of 15 days for a bi-weekly schedule), and update the corresponding CFDI values.
* Refactor tests and add new helpers.

### Error on [warning issues generation][1] and [`_compute_is_wrong_duration`][2]

The warning: `"The duration of the payslip is not accurate according to the structure type."` appears with these custom periods for Mexican Payroll, although the period is correct:
* `10_days`
* `14_days`
* `bi-weekly`

Steps to replicate:
* Install `l10n_mx_hr_payroll` module.
* Switch to "INNOVACION VALOR Y DESARROLLO SA SA" company.
* Go to Employees and open "Cesar Osbaldo Cruz Solorzano".
* Click on "Payroll" tab, change the "Pay Schedule" to any option listed above, for example "Bi-weekly".
* Go to Payroll > Payslips > Payslips and create a new pay run.
* Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Bi-weekly' and the Period '01/01/2026 -> 01/15/2026'.
* Click on "Continue", select Cesar and click on "Select".
* It appears the warning issue.

Problem:
The warning is raised because of `slip.date_from + slip._get_schedule_timedelta() != slip.date_to` condition, because `_get_schedule_timedelta` function calls [`self._schedule_timedelta(schedule, self.date_from)`][3] without the `country_code` argument.
In the Mexican Payroll [_schedule_timedelta is overriden][4] but it is necessary to call it with the country code to use the custom periods; similar to how the [`date_end` is computed][5].

Solution:
Call `_get_schedule_timedelta` passing the `country_code`

[1]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip.py#L1367
[2]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip.py#L1454
[3]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip.py#L275
[4]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/l10n_mx_hr_payroll/models/hr_payslip.py#L58
[5]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip_run.py#L211

target: 19.0
task-6073601

### Steps to reproduce:
	- Install project_timesheet_forecast module
	- Configure your database to have a far timezone (Montevideo/Uruguay in my case)
	- Create a public holiday starts from 12AM to 11:59PM with a calendar
	- Create a planning slot for a resource that overlap with the public holiday
	- Check the Timesheets / Planning analysis report
	- Group by employees > day 
	**- Check the date of the public holiday and notice there are still planned hours shown**
	- Remove the calendar from the public holidays that we created previously
	- Check the report once again 
	**- Notice the day of the public holiday and the day after has no planned hours**

### Cause:
In the query we are using to exclude the leave days from the report we only exclude the ones that has calendar_id assigned, not taking into consideration that some of the public holiday are general and is not applied to just one working schedule.

Also if we have a leave starting midnight to 11:59PM since we store dates in database as UTC for timezone like Uruguay's one it will shift the end with one day which will introduce inconsistencies

### Fix:
We check if the calendar_id is null on the resource_calendar_leaves and make sure we take timezone of the resource into account when checking the dates of the leaves.

opw-5027070

Forward-Port-Of: odoo/enterprise#111846

## Issue
Currently, the Barcode app doesn't work very well when the user scans packaging and lots. If they want to apply one or multiple packagings to a specific lot, the quantity is not quite exact since scanning a lot
already increases the quantity by 1.
Also, if there is multiple lots, the packaging quantity isn't added to the last scanned lot which is problematic.

## How to reproduce
1. Active "Units of Measure & Packagings" and "Lots & Serial Numbers"    settings;
2. Create a product tracked by lots with a barcode;
3. In the "Sales" tab, add a packagings (for example, "Pack of 6");
4. Configuration > Units & Packagings > Selected the added UoM > Click on "Packaging Barcodes";
5. Create a new barcode for the created product;
6. Create and confirm a receipt for 12 units of this product and open the operation in Barcode app;
7. Scan the product's barcode, then a lot then the packaging barcode
   :arrow_right: First issue: the line has 7 units.
8. Scan a second lot and scan the packaging again
   :arrow_right: Second issue: the packaging quantity is added to the first line, not the second one.

## Explanation
About the first issue, it is the expected behavior. When the user scans a lot, we increase the line quantity by 1. When the user scans a packaging, we increase the line quantity by this packaging quantity.
The issue here is the user expects to scan a lot and then to apply a packaging quantity to it. For example, scanning a lot then a pack of six should result by a line with 6 units, not 7.

About the second issue, it is caused by some conditions in the `_findLine` method which don't prioritize the right line.

[OPW-6045395](https://www.odoo.com/odoo/project.task/6045395)

**Steps to reproduce:**
- Install the `l10n_cz_reports` module and switch to a `CZ Company`
- Create an invoice for a customer with a VAT number, add a product, and 
  set the Transaction Code (enable it from the optional columns if needed).
- Navigate to Reporting > VIES Summary Report.
- Observe the value in the `VAT Number` column (includes country code).
- From the dropdown, export the report as XML.

**Observation:**
In the generated XML file, the `c_vat` field contains the VAT number 
including the country code (e.g., `CZ12345679`) instead of only the 
numeric part (`12345679`).

**Root cause:**
At [1], the VAT number is directly taken from the report lines without 
removing the country code.

**Fix:**
This commit ensures that the `c_vat` field contains only the VAT number without 
the country code, complying with the official VIES XML format requirements.

Ref: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV#:~:text=Tax%20identification%20number%20of%20the%20purchaser%20(only%20the%20numeric%20part)

[1]:
https://github.com/odoo/enterprise/blob/c4f2c3442f30f5ac972dd136a3642acc5bcc6da2/l10n_cz_reports_2025/models/l10n_cz_vies_summary_handler.py#L29-L62

opw-6093259

Forward-Port-Of: odoo/enterprise#113083

Current behavior:
When reconciling a bank statement line whose journal currency differs from the company currency and whose foreign_currency_id equals the company currency, mounting a vendor bill with force-full-match and re-tagging the auto_balance line to a company-currency account raises UserError: "The entry is not balanced." on Validate.

Expected behavior:
The reconciliation should validate successfully with the exchange difference carried on the counterpart line.

Required Modules
- account_accountant
- l10n_au (any company-currency localization reproduces, AU used here)

Steps to reproduce:

1. Install account_accountant and l10n_au. Company currency = AUD.

2. Activate JPY and add a rate for 2025-10-01: 109.6788 JPY/AUD.

3. Create a bank journal:
   Name: ANZ EUR Account (JPY)
   Type: Bank
   Currency: JPY

4. Create an account:
   Code: 1082
   Name: Deposits - Paid to Mazak
   Type: Current Assets
   Currency: (leave empty — accepts any)

5. Create vendor partner "Yamazaki".

6. Add a second JPY rate for 2025-11-01: 105.069 JPY/AUD (creates the FX gap between bill date and statement date).

7. Create and post a vendor bill:
   Vendor: Yamazaki
   Currency: JPY
   Bill date: 2025-10-01
   One line: JPY 37,000,000, no tax

8. Create a bank statement line on the JPY journal:
   Date: 2025-11-01
   Amount: -33,331,248 (JPY)
   Foreign currency: AUD, amount: -303,898.18

9. Open reconciliation on the statement line.

10. Manual Operations → mount the vendor bill with "Allow partial" OFF so the bill is force-matched fully. The widget now displays four lines: liquidity, new_aml (Trade Creditors), exchange_diff (Exchange Rate Loss), and auto_balance (AUD).

11. Click the auto_balance line and change its account to 1082 Deposits - Paid to Mazak.

12. Click Validate.

Expected result
The move posts: ANZ -303,898.18 / Trade Creditors +352,149.54 / Deposits -48,251.36, Σ = 0.

Actual result
UserError: The entry is not balanced.

Cause of the issue:
In _lines_prepare_auto_balance_line (bank_rec_widget.py:424-475), the auto_balance line's amount_currency is computed from the JPY gap converted at the transaction rate while its balance is computed independently as the company-currency plug. When the statement line's foreign_currency_id equals the company currency, currency_id on the auto_balance line resolves to the company currency, yet the two numbers disagree. account.move.line._inverse_amount_currency (account_move_line.py:1250-1260) enforces balance = amount_currency whenever currency_id == company_currency_id, so at move.write the balance is silently clamped to amount_currency, dropping the FX component. _validation_lines_vals (bank_rec_widget.py:1382-1406) has already squashed the exchange_diff into the new_aml, so the FX stays on the JPY side while its AUD-side offset is clamped away. _check_balanced (account_move.py:2462-2474) then raises.

Fix:
In _lines_prepare_auto_balance_line, when transaction_currency_id == company_currency_id, force amount_currency = open_balance before returning the vals. The line then reaches account.move.write already satisfying the _inverse_amount_currency invariant, the clamp is a no-op, and the FX squashed into new_aml is preserved.

opw-6122823

### Steps to reproduce:
	- Install project_timesheet_forecast module
	- Configure your database to have a far timezone (Montevideo/Uruguay in my case)
	- Create a public holiday starts from 12AM to 11:59PM with a calendar
	- Create a planning slot for a resource that overlap with the public holiday
	- Check the Timesheets / Planning analysis report
	- Group by employees > day 
	**- Check the date of the public holiday and notice there are still planned hours shown**
	- Remove the calendar from the public holidays that we created previously
	- Check the report once again 
	**- Notice the day of the public holiday and the day after has no planned hours**

### Cause:
In the query we are using to exclude the leave days from the report we only exclude the ones that has calendar_id assigned, not taking into consideration that some of the public holiday are general and is not applied to just one working schedule.

Also if we have a leave starting midnight to 11:59PM since we store dates in database as UTC for timezone like Uruguay's one it will shift the end with one day which will introduce inconsistencies

### Fix:
We check if the calendar_id is null on the resource_calendar_leaves and make sure we take timezone of the resource into account when checking the dates of the leaves.

opw-5027070

Forward-Port-Of: odoo/enterprise#111846

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#259384