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

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

An issue is observed when two categories share the same name but are assigned to different websites, and a product is linked to both categories.

Steps to Reproduce:
====================
1. Create two Ecommerce categories with the same name, one assigned to Website 1 and the other to Website 2.
2. Create a product and assign both categories to it.
3. On Website 1, navigate to the product page and click the category breadcrumb → works correctly
4. On Website 2, navigate to the same product page and click the category breadcrumb → **404 error**

Cause:
======
In `_prepare_product_values`, when no category is passed in the URL, the fallback was:
https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/website_sale/controllers/main.py#L802

This blindly picks the **first** category from the product's public categories without checking which website it belongs to. If the first category (by ID order) belongs to Website 1, it gets used even when the user is browsing Website 2.
The breadcrumb then generates a slug pointing to Website 1's category. When clicked on Website 2, `can_access_from_current_website()` fails for that category, resulting in a 404.

Solution:
=========
Filter `public_categ_ids` through `can_access_from_current_website()` before selecting the first one.

opw-6070191

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

Forward-Port-Of: odoo/odoo#260391
Forward-Port-Of: odoo/odoo#258336

Since [1], the check in `search_for_channel_invite` that restricted the search to internal users was removed. As a result, the dataset to process has exploded and the query is very slow.

Moreover, the method is ordering on `LOWER(name)` which is not indexed, and another query is done to count the total results, which slows down the process even more.

This PR fixes those issues by:
- Removing the `LOWER` ordering. Ordering in a case sensitive fashion is not that big of a deal anyway.
- Removing the count query, fetching one more partner in the search is enough to know if there are more results, executing the same query twice is overkill.
- Reducing the number of partner returned: currently 30, but there isn't enough space to display them anyway.

task-4526176

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

- 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

### Issue:
If a payslip is split into multiple bank accounts (Salary Allocation), the generated SEPA file contains duplicate <InstrId> tags

### Cause:
The `_get_payments_vals` method, `InstrId` is based on the payslip ID
When a single payslip generates multiple transaction blocks, this ID is duplicated, violating the ISO 20022 requirement for unique instruction identifiers
https://knowledge.xmldation.com/support/iso20022/general_rules/instrid

This commit adds a unique suffix with the bank_account.id (slip.id-ba.id) to the `InstrId` for each transaction generated to ensure technical uniqueness

This is the part of the code that use the payment name:
https://github.com/odoo/enterprise/blob/194a8d35ef3e9b47ff566479b0c35c0f963fb42d/account_iso20022/models/account_journal.py#L294-L299

### Steps to reproduce:
- Install `hr_payroll_account_iso20022` with demo data
- On the Bank Journal, set a valid IBAN (e.g. BE04957751619131) for `Bank Account Number`
- Open the Employee page for Abigail Peterson
- In the Personal tab, add 2 Bank Accounts (Send Money: True, Account Number: any)
- Click on Salary Allocation and Save (You'll have a 50/50 ratio)
- Create a new Pay Run (for Abigail Peterson)
- Open the last PaySlip and Validate
- Create Payment Report (Export Format: SEPA)
- Download the Payment Report and check the <InstrId> tags

opw-6069670

Forward-Port-Of: odoo/enterprise#113113

You cannot increase the quantity of a combo product that has options with Sell when Out-of-Stock disabled

Steps to reproduce:
1. Install Inventory and eCommerce
2. Go to Website > eCommerce > Products and create a new product "Combo"
3. Set the Product Type to Combo, create and edit a Combo Choice "test" with two options "test 1" and "test 2". Both have Track Inventory enabled, 5 Quantity On Hand and Sell when Out-of-Stock disabled
4. Publish product "Combo" to the website
5. Click on smart button "Go to Website" to open the shop page of product "Combo"
6. Try to increase the quantity
7. The quantity is limited to 1

Solution:
Always set the quantity input's maximum when `has_max_combo_quantity` is true

Issue:
We only set the quantity input's maximum if `allow_out_of_stock_order` is false
This error was introduced in https://github.com/odoo/odoo/commit/0247538efe788a9ff9a4d58f64470325348a4eaa

opw-6050876

Forward-Port-Of: odoo/odoo#260523
Forward-Port-Of: odoo/odoo#257386

When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely.

Step to reproduce:
- Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025)
- Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method
- Compute the board and observe that entries from January to April 2026 are missing

Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal.

opw-6016834

Forward-Port-Of: odoo/enterprise#113521

- 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

**[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. Set language decimal separator to "," and thousands separator to "."
2. Open PoS, create an order (e.g. total 17.85)
3. Pay more than the total (e.g. 22)
4. Open the Tip popup — it shows 415 instead of 4,15
5. Confirm — tip is set to 415

Issue
When overpaying, the change is passed as `startingValue` to the NumberPopup via
`String(amount)` (https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L232),
which always uses "." as decimal separator. This value is used directly as the
display buffer in NumberPopup
(https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/components/popups/number_popup/number_popup.js#L53),
so the user already sees "415" instead of "4,15" when the popup opens. When the
user confirms, `computeNewTip` parses this value with the locale-aware `parseFloat`
from `@web/views/fields/parsers`
(https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L279
and https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/web/static/src/views/fields/parsers.js#L73-L83),
which uses `localization.thousandsSep` and `localization.decimalPoint` to interpret
the string. With "," as decimal separator and "." as thousands separator,
`parseFloat("4.15")` treats the "." as a thousands separator, strips it, and
returns 415 instead of 4.15.

opw-5895622

Steps to reproduce Bug 1:
  1. Login as a user with "All Timesheets" (Approver) access.
  2. Disable the "Timesheet Assistant" feature for this user.
  3. Ensure "Billing Rate Indicators" is enabled in settings.

Steps to reproduce Bug 2:
  1. Login as a user with "All Timesheets" (Approver) access.
  2. Disable the "Billing Rate Indicators" setting in company settings.
  3. Ensure "Timesheet Assistant" is enabled in settings.
 
Steps to reproduce Bug 3:
 1. Only install 'sale_timesheet_enterprise'.
 2. Go to Timesheets > Configuration > Settings.
 3. Toggle "Billing Rate Indicators" (timesheet_show_rates) or change the encoding unit (timesheet_encode_uom_id), then save and check the menus.

Issue:
1. The "Configuration" menu is hidden, preventing access to billing targets even if the user has "All Timesheets" access.
2. The "Billing Time Targets" menu is still visible inside Configuration even if the "Billing Rate Indicators" feature is disabled in the settings.
3. Menu visibility does not update immediately after saving the settings. Menus that should appear (e.g., "Employee Billing Time Targets" or "Timesheets Assistant") remain hidden, or vice versa, until the cache is cleared or the server is restarted.

Cause:
1. The `hr_timesheet_enterprise_menu_configuration` was restricted in XML to groups that excluded "All Timesheets" users.
2. The `_load_menus_blacklist` logic in Python only blacklisted billing menus for users who were both Managers and System Admins, leaving them visible to regular Approvers even when the feature was disabled.
3. The load_menus method is decorated with @ormcache and stored in the Registry LRU cache. Menu visibility depends on timesheet_show_rates and timesheet_encode_uom_id through _load_menus_blacklist. When this field is updated, the ORM does not automatically invalidate the cached load_menus result because these specific fields are not part of the configuration fields. As a result, the stale old menu remains in memory.

Fix:
- Updated XML to include `hr_timesheet.group_hr_timesheet_approver` in the Enterprise Configuration menu permissions.
- Refactored `_load_menus_blacklist` to:
    - Hide all billing-related menus for all users when the feature is disabled.
    - Hide the parent Configuration menu if it would otherwise be empty.
- Override the write method in res.company in both modules and explicitly call env.registry.clear_cache() when the relevant configuration fields are modified.

task-5428010

Steps to reproduce:
- Create a storable product "P1"
- Update on-hand quantity to 2 units
- Create a delivery with 2 units of P1 and keep it in draft state

Problem:
The forecast availability is displayed in red (not available), even though the stock is sufficient to fulfill the move.

Explication:
For draft consuming moves, the forecast availability is computed as: `virtual_available - move.product_qty`

In the case where stock exactly matches the demand, this results in 0. However, on the JS side, availability is evaluated with: `forecast_availability >= product_qty`

So with forecast_availability = 0 and product_qty = 2, the condition evaluates to False, incorrectly marking the move as not available.

https://github.com/odoo/odoo/blob/c7fede7f44c668ccc0a094d8341c3cae8879a7f1/addons/stock/static/src/widgets/forecast_widget.js#L31

Solution:
When the available quantity is sufficient to cover the move (using float_compare), set forecast_availability to the full available quantity instead of subtracting the move quantity. This ensures the JS condition correctly evaluates to True and the move is marked as available.

opw-5159142

Forward-Port-Of: odoo/odoo#258504
Forward-Port-Of: odoo/odoo#257354

Steps to reproduce
==================

- Install hr_payroll
- Use a mobile viewport
- Go to Employees
- Open a record
- Switch to the Salary Adjustments notebook tab

=> TypeError: undefined is not an object (evaluating 'props.activeActions.onDelete=this.onDelete.bind(this)'

Cause of the issue
==================

The SalaryAttachment2ManyField widget overrides the rendererProps to handle the delete action, but this isn't defined on mobile (because a kanban view is used)

See

https://github.com/odoo/odoo/blob/9f93f22ed5f6d5dbbafeb0a8c6fababdc2a65d45/addons/web/static/src/views/fields/x2many/x2many_field.js#L196-L212

Solution
========

Since there is no delete action on the kanban view, there is no need for an override.

While we are at it, there was no kanban view defined. Thus a default view was used

https://github.com/odoo/odoo/blob/138fad6d54a0b59885b1e5c712beb8f581c9555c/odoo/addons/base/models/ir_ui_view.py#L2835-L2846

It only contained the field description. Since that one is optional, records without a description were almost invisible..

Thus we also add a basic kanban view

opw-6047295

Forward-Port-Of: odoo/enterprise#113317

This commit refactors the import code of BIS3 Invoice to fix various issues about unsynchronized values between the imported invoice and the source XML file.

The new way we import BIS3 invoice can be categorized as:

- collecting all the values from the XML to a dictionary object
- prepare the values and amounts to write to the invoice in its entirety using the tax computation engine helpers
- write the whole processed values to the invoice (as a single write)
- (in 18.0 ~ 18.2) recalculate discrepancies and update the invoice lines (if needed) with the corrected amounts

This commit also includes a new test suite for BIS3 import, and a new approach of import testing, "Partial Imports", is introduced to better atomize the big import test files (and make it understandable). In the long term, `l10n_account_edi_ubl_cii_tests` will eventually be removed in favor of these small-but-many partial tests.

task-id: 5058687

Co-authored-by: Yosua Nicolaus <yoni@odoo.com>

Forward-Port-Of: odoo/odoo#260128
Forward-Port-Of: odoo/odoo#250160

### 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
-----
When using full packaging in barcode, leaving the operation and opening it again shows incorrect quantity for already scanned packages.

Steps to reproduce
-----
- Enable packages
- Create a product with one package in stock
- Operation Types > Delivery Orders, set Move Entire Packages to true
- Create a delivery for a package
- Scan the package barcode
- Exit the delivery
- Re-enter the delivery

> Quantity for the line is 1/false

Cause
-----
The line is picked, so it is considered as not reserved

https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/models/barcode_picking_model.js#L288-L289

when doing

https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/models/barcode_picking_model.js#L812-L813

This leads to `qtyDemand` returning false instead of 1

https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/components/package_line.js#L17-L18

-----
Ticket:
opw-5960629

Forward-Port-Of: odoo/enterprise#114451
Forward-Port-Of: odoo/enterprise#113816

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

### 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
-----
When using full packaging in barcode, leaving the operation and opening it again shows incorrect quantity for already scanned packages.

Steps to reproduce
-----
- Enable packages
- Create a product with one package in stock
- Operation Types > Delivery Orders, set Move Entire Packages to true
- Create a delivery for a package
- Scan the package barcode
- Exit the delivery
- Re-enter the delivery

> Quantity for the line is 1/false

Cause
-----
The line is picked, so it is considered as not reserved

https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/models/barcode_picking_model.js#L288-L289

when doing

https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/models/barcode_picking_model.js#L812-L813

This leads to `qtyDemand` returning false instead of 1

https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/components/package_line.js#L17-L18

-----
Ticket:
opw-5960629

Forward-Port-Of: odoo/enterprise#114451
Forward-Port-Of: odoo/enterprise#113816

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

Steps to reproduce
==================

- Install hr_payroll
- Use a mobile viewport
- Go to Employees
- Open a record
- Switch to the Salary Adjustments notebook tab

=> TypeError: undefined is not an object (evaluating 'props.activeActions.onDelete=this.onDelete.bind(this)'

Cause of the issue
==================

The SalaryAttachment2ManyField widget overrides the rendererProps to handle the delete action, but this isn't defined on mobile (because a kanban view is used)

See

https://github.com/odoo/odoo/blob/9f93f22ed5f6d5dbbafeb0a8c6fababdc2a65d45/addons/web/static/src/views/fields/x2many/x2many_field.js#L196-L212

Solution
========

Since there is no delete action on the kanban view, there is no need for an override.

While we are at it, there was no kanban view defined. Thus a default view was used

https://github.com/odoo/odoo/blob/138fad6d54a0b59885b1e5c712beb8f581c9555c/odoo/addons/base/models/ir_ui_view.py#L2835-L2846

It only contained the field description. Since that one is optional, records without a description were almost invisible..

Thus we also add a basic kanban view

opw-6047295

Forward-Port-Of: odoo/enterprise#113317

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)

Issue
-----
When using full packaging in barcode, leaving the operation and opening it again shows incorrect quantity for already scanned packages.

Steps to reproduce
-----
- Enable packages
- Create a product with one package in stock
- Operation Types > Delivery Orders, set Move Entire Packages to true
- Create a delivery for a package
- Scan the package barcode
- Exit the delivery
- Re-enter the delivery

> Quantity for the line is 1/false

Cause
-----
The line is picked, so it is considered as not reserved

https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/models/barcode_picking_model.js#L288-L289

when doing

https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/models/barcode_picking_model.js#L812-L813

This leads to `qtyDemand` returning false instead of 1

https://github.com/odoo/enterprise/blob/02f957b600bac3d86411091fd762d88e372db7c5/stock_barcode/static/src/components/package_line.js#L17-L18

-----
Ticket:
opw-5960629

Forward-Port-Of: odoo/enterprise#114451
Forward-Port-Of: odoo/enterprise#113816

Why this commit:
When loading the 'bills to receive' or 'Invoices to be Issued' The time zones ahead of UTC will face the discrepancy in the view.

e.g. etc/GMT-12 timezone is 12 hours ahead of UTC, So 12 AM UTC is 12 PM etc/GMT-12.
So report view will not include the invoices/bill with order_date of current day till its 12 AM[next day] IN UTC, Meaning etc/GMT-12 will be seeing today's bills/invoices  after 12 PM.

After this commit:
To resolve this discrepancy we use the context_today date to get the user
 local date. Which is required by the [domain sanitizer](https://github.com/odoo/odoo/blob/8bff78853f6ab8dc2cc951c03bb30181c0745834/odoo/orm/domains.py#L1572-L1574) too.
 
 Steps to reproduce (Possible in runbot) :
1. Select etc/GMT-12 timezone in preferences
[when UTC is between 13:00-24:00 ~ 1:00-12:00 GMT-12(of next day)]
2. Create a PO and Validate the quantity received.
3. Go to accounting>review>bills to receive.
4. the newly created PO won't be listed here.

OPW: 6083526

**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

**Description of the issue/feature this PR addresses:**

Odoo currently determines the tax treatment of EU B2B transactions primarily based on the customer's VAT country.
This leads to incorrect classification of some transactions as intra-Community supplies when the customer provides a valid foreign EU VAT number but the goods are delivered within the seller's country.

Under EU VAT rules (Directive 2006/112/EC, Articles 32 and 138), an intra-Community supply only exists if the goods are physically dispatched or transported from one Member State to another.
If the goods remain in the seller's country, the transaction must be treated as a domestic supply subject to local VAT, regardless of the customer's foreign VAT identification.

**Current behavior before PR:**
When a customer has a valid EU VAT number from another Member State, Odoo may apply intra-Community tax treatment (0% VAT) even if the delivery address is located in the seller's country and no cross-border movement of goods occurs.

This results in:

- Incorrect VAT exemption being applied.
- Transactions being treated as intra-Community supplies when they are legally domestic supplies.
- Potential inconsistencies with EU VAT compliance and reporting.

**Desired behavior after PR is merged:**
Tax determination takes into account the actual place of delivery of the goods.
If the goods are delivered within the seller's country and no intra-Community transport occurs, the transaction is treated as a domestic supply and local VAT is applied, even when the customer provides a valid foreign EU VAT number.

This ensures that intra-Community tax treatment is only applied when there is an actual cross-border movement of goods, aligning Odoo's behavior with EU VAT Directive requirements.

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

cc @Tecnativa 
ping @carlosdauden @juancarlosonate-tecnativa

**problem:**
On timesheets, the overtime indication next to an employee's name is incorrect when using flexible work schedules. for example: a "Flexible 20h" schedule (4h a day) shows 1h of negative overtime even when the employee has logged exactly 20h for the week.

**steps to reproduce:**
1. Create a new working schedule with flexible hours enabled for example (20h/week, 4h/day average)
2. Assign this schedule to an employee
3. Go to Timesheets, search for the employee
4. Navigate to a past week
5. Enter 4h on each working day
6. Observe the overtime indication shows incorrect value (-01:00)

**cause:**
In `resource/models/resource_calendar.py`, the flexible hours algorithm that determines the date range by converts UTC boundaries to the employee's timezone. When the employee's timezone has a positive UTC offset (UTC+1, like in brussels time zone), `Sun 23:59:59 UTC` becomes `Mon 00:59:59 CET`, pushing `end_date` to the next Monday. This creates an 8 day range instead of 7. The algorithm then starts a new weekly budget for the spillover day and allocates 1 extra hour, making `allocated_hours` 20.9999998 instead of 20.

**fix:**
- Use the UTC date before conversion to the employee's timezone when determining the flexible date range.


**note:**
Updating the test (test_no_carried_over_leaves_for_flexible_resource) in hr_holidays/tests/test_expiring_leaves.py expected duration logic, is to match the corrected inclusive day range and prevent asserting the
previous spillover behavior.

link to the enterprise PR: odoo/enterprise#112879

opw-5970511

---

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

**problem:**
On timesheets, the overtime indication next to an employee's name is incorrect when using flexible work schedules. for example: a "Flexible 20h" schedule (4h a day) shows 1h of negative overtime even when the employee has logged exactly 20h for the week.

**steps to reproduce:**
1. Create a new working schedule with flexible hours enabled for example (20h/week, 4h/day average)
2. Assign this schedule to an employee
3. Go to Timesheets, search for the employee
4. Navigate to a past week
5. Enter 4h on each working day
6. Observe the overtime indication shows incorrect value (-01:00)

**cause:**
In `resource/models/resource_calendar.py`, the flexible hours algorithm that determines the date range by converts UTC boundaries to the employee's timezone. When the employee's timezone has a positive UTC offset (UTC+1, like in brussels time zone), `Sun 23:59:59 UTC` becomes `Mon 00:59:59 CET`, pushing `end_date` to the next Monday. This creates an 8 day range instead of 7. The algorithm then starts a new weekly budget for the spillover day and allocates 1 extra hour, making `allocated_hours` 20.9999998 instead of 20.

**fix:**
- Use the UTC date before conversion to the employee's timezone when determining the flexible date range.
- prefer `self` when it is the flexible calendar being queried, so hr_contract's `_get_calendar_at()` override cannot substitute the contract's calendar parameters (full_time_required_hours, hours_per_day) for the flexible ones.

**note**
Updating the test (`test_no_carried_over_leaves_for_flexible_resource`) in `hr_holidays/tests/test_expiring_leaves.py` expected duration logic, is to match the corrected inclusive day range and prevent asserting the previous spillover behavior.
link to the enterprise PR: https://github.com/odoo/enterprise/pull/112879

link to the community PR: https://github.com/odoo/odoo/pull/257269

opw-5970511

---

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