Steps to reproduce ================== - Install web_studio,mrp - Go to Manufacturing > Operations > Manufacturing Orders - Open studio - Add a related field - Select Product > Image - Change the widget to the ImageField - Exit studio - Open any record - Go to the product - Edit the image - Go back to the list view => The old image is still displayed Cause of the issue ================== We add a unique parameter in the image url with the last record update. In the case of a

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

- Install web_studio,mrp
- Go to Manufacturing > Operations > Manufacturing Orders
- Open studio
- Add a related field
- Select Product > Image
- Change the widget to the ImageField
- Exit studio
- Open any record
- Go to the product
- Edit the image
- Go back to the list view => The old image is still displayed

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

We add a unique parameter in the image url with the last record update. In the case of a related field, the record has not been updated even if the image has changed.

Solution
========

We still need to pass a unique value in the URL because browser will not fetch twice the same URL in the same session. In that case, we can simply pass a random value

opw-4378605

Forward-Port-Of: odoo/odoo#196752
Forward-Port-Of: odoo/odoo#192036

The sales subscription performance test was adjusted to reflect a small extra system check introduced by new default quotation document settings. This keeps automated testing aligned with the updated sales order process without changing the user experience.

A new feature in the community version allows users to set default quotation documents for sales orders. This introduces an additional query in the sale order creation flow. 

This commit increases the max query count of a performance test to accommodate these new queries.

task-4307011

This update streamlines how planning and shift links are created by using one shared method instead of two separate ones. It helps keep Planning access links consistent and easier to maintain, with updated parameters for dates, employees, and access tokens.

In this PR we merge the _planning_get_url and _slot_get_url method and make a single method _planning_get_url.

we also change the some parameters
1. date_start
2. date_end
3. employees
4. planning_access_token

task-4156813

The Sign app no longer keeps an unused availability marker for signing options. This simplifies internal option handling now that options are created when needed and reused, with no expected change for everyday users.

This commit removes the 'available' field from the 'sign.item.option' model as it is not used anymore neither its logic.
After odoo/enterprise#75291 we create options on demand and reuse the previous options for avoiding duplicating it,
with the available field being True or False.

issue-from: 75291
task-4387560

The Web Studio editor now displays existing fields in alphabetical order. This makes it quicker and more predictable for users to find the field they need when customizing views.

**Before:**
The fields under `Existing Fields` were not displayed in alphabetical order.

**After:**
The fields under `Existing Fields` are displayed in alphabetical order.

task-4544703

This fixes an error that occurred when loading sample appraisal data in databases without demo data. The sample data now matches the updated goal manager setup, so users can try the Appraisal app without hitting a crash.

STEPS TO REPRODUCE:
1- Install a database without demo data
2- Go on Appraisal
3- Click on Load sample data

You will have a traceback

Reason:
Before a goal only has one manager, and now multiples managers can be linked to a goal (introduced by this commit : https://github.com/odoo/enterprise/commit/dd90f66a536539413a3886e0f165d30d8f79ef89 )

task-4563359

This update fixes two minor issues in the Czech reports module: a duplicated read-only setting in an accounting screen and inconsistent internal logic for a reporting code calculation. These changes help keep accounting report behavior cleaner and more consistent without changing user workflows.

This commit fixes the following issues of the module l10n_cz_reports:
1. The readonly attribute was duplicated in account move view.
2. The account_move_line supplies code compute method was different from that of the transaction code (although the logic is identical).

X-original-commit: https://github.com/odoo-dev/enterprise/commit/71279841b3db65f577804e0749b594aea386d67b

This fixes two small visual inconsistencies on the Helpdesk website form page. The form title now matches the standard front-end title styling, and the card background no longer depends on a theme color that may vary by customer setup.

This PR fixes two minor color issues on the `website_helpdesk` form page.

Prior to this PR, the title of the form was using a `text-muted`, which is inconsistent with the other titles design across the front-end.

There was also an issue about the card using a `bg-secondary` utility class to tweak its design, which doesn't work anymore with the new secondary color we introduced in 13d4d48 and highlight the fact we can't rely on utility classes for this scenario since we don't know what color will be set by the user.

| Master | This PR |
|--------|--------|
| ![image](https://github.com/user-attachments/assets/bf1a4d38-c277-4856-a6af-69ab3b6fd0e4) | ![image](https://github.com/user-attachments/assets/944601cd-103f-4696-9170-dc51a2bf7e34) | 

task-4498381

If a custom handler handles the caret builder, it used to only consider this function, and therefore not benefiting from the generic keys provided by the default function of the report engine. This can cause minor disadvantage such as when a user change himself the groupby keys of a report with a custom engine. In this case, the caret options won't be visible at all. With the change of this commit, the custom handler caret options will be used on top of the default ones. task-4557882 Forward

If a custom handler handles the caret builder, it used to only consider this function, and therefore not benefiting from the generic keys provided by the default function of the report engine. This can cause minor disadvantage such as when a user change himself the groupby keys of a report with a custom engine. In this case, the caret options won't be visible at all. With the change of this commit, the custom handler caret options will be used on top of the default ones.

task-4557882

Forward-Port-Of: odoo/enterprise#78800

Commit 1: [FIX] documents: fix showing alias fields on details panel Reproduce: 1. Go to a folder on the kanban view 2. If not configured, configure Email Servers, then redo 1. 3. Clear the domain of the alias 4. You are asked to configure servers again and you cannot set any value for the alias. Redirecting to the company settings is cumbersome and unlikely useful. Erp managers should be able to quick create here as in the company settings, as aliases are not company specific when

Commit 1:
[FIX] documents: fix showing alias fields on details panel

Reproduce:
1. Go to a folder on the kanban view
2. If not configured, configure Email Servers, then redo 1.
3. Clear the domain of the alias
4. You are asked to configure servers again and you cannot set
any value for the alias.

Redirecting to the company settings is cumbersome and unlikely
useful. Erp managers should be able to quick create here as in
the company settings, as aliases are not company specific when
receiving.

Technically, removing `load=False` on `documents_unique_folder_id`
(added when there is a `search_panel_default_folder_id` without
`no_documents_unique_folder_id` in context) is necessary to load
the existing `alias_domain_id`'s `display_name`.

Commit 2:

[FIX] documents: fix reloading only search panel

It is not necessary to reload the model when we
want to reload the search panel.

Commit 3: 

[FIX] documents: fix validation error on saving container

These records' methods are sometimes called when there is no point
(and don't work), because the record is not part of the view.

This can be seen for example when adding alias tags.


Commit 4: 

Reproduce:
As an internal user not documents manager,
open the details panel on a company root folder
with access_internal="edit".
The fields are not rendered as readonly as they should.

Test data updated in documents_spreadsheet.

Task-4543501

Forward-Port-Of: odoo/enterprise#79019
Forward-Port-Of: odoo/enterprise#78375

When creating a SOL on the fly from a project or a ticket, we try to match an existing product from what was typed in the field. However, we should be excluding recurring services Task-4354482 Forward-Port-Of: odoo/enterprise#79077 Forward-Port-Of: odoo/enterprise#74412

When creating a SOL on the fly from a project or a ticket, we try to match an existing product from what was typed in the field. However, we should be excluding recurring services

Task-4354482

Forward-Port-Of: odoo/enterprise#79077
Forward-Port-Of: odoo/enterprise#74412

In Chile localization it is possible to add a Related Document when creating an Invoice Document. These documents info are then added to the Electronic Invoice sent to the government. Currently, when creating a Boleta Electronica and adding a Cross Reference Document, the EDI system will not validate correctly the xml, with error `Error en Schema [0] LSX-00204: extra data at end of complex element` This occurs because the system first creates a dte from a common xml schema, then wrap

In Chile localization it is possible to add a Related Document when
creating an Invoice Document. These documents info are then added to the Electronic
Invoice sent to the government.

Currently, when creating a Boleta Electronica and adding a Cross
Reference Document, the EDI system will not validate correctly the xml,
with error
`Error en Schema [0] LSX-00204: extra data at end of complex element`

This occurs because the system first creates a dte from a common xml schema, then
wrap it with the appropriate envelope.
However the schema of Boletas slighly differs[1], as it doesn't have the
field FchRef, so it gets rejected by SII

A solution is to modify the code of dte_subtemplate to make sure that FchRef
only appears if the Schema corresponds to http://www.sii.cl/SiiDte EnvioDTE_v10.xsd,
and not to http://www.sii.cl/SiiDte EnvioBOLETA_v11.xsd

[1] https://www.sii.cl/factura_electronica/factura_mercado/formato_boletas_elec_202412.pdf

opw-4433202

Forward-Port-Of: odoo/enterprise#78177

ELM 5.0 Swissdec Certification Forward-Port-Of: odoo/enterprise#79026 Forward-Port-Of: odoo/enterprise#64454

ELM 5.0 Swissdec Certification

Forward-Port-Of: odoo/enterprise#79026
Forward-Port-Of: odoo/enterprise#64454

A standard such as RiBa that everyone calls RiBA should not have any invented translation like Payment Receipt (IT). Followup for the Ri.Ba. task: odoo/enterprise#74097 Documentation PR: odoo/documentation#11847 Task [link](https://www.odoo.com/odoo/project/967/tasks/4497749) task-4497749 Forward-Port-Of: odoo/enterprise#78927 Forward-Port-Of: odoo/enterprise#77991

A standard such as RiBa that everyone calls RiBA should not have any invented translation like Payment Receipt (IT). 

Followup for the Ri.Ba. task: odoo/enterprise#74097
Documentation PR: odoo/documentation#11847

Task [link](https://www.odoo.com/odoo/project/967/tasks/4497749)
task-4497749

Forward-Port-Of: odoo/enterprise#78927
Forward-Port-Of: odoo/enterprise#77991

Before this commit, the leaderboard data is fetched even if we are sure the feature is disabled. This commit checks the feature is enabled before getting leaderboard data. task-4509858 Forward-Port-Of: odoo/enterprise#79060 Forward-Port-Of: odoo/enterprise#78858

Before this commit, the leaderboard data is fetched even if we are sure the feature is disabled.

This commit checks the feature is enabled before getting leaderboard data.

task-4509858

Forward-Port-Of: odoo/enterprise#79060
Forward-Port-Of: odoo/enterprise#78858

The subsidy is now computed based on the daily UMA and a new rule parameter, a percentage. Task: 4465315 Forward-Port-Of: odoo/enterprise#78075

The subsidy is now computed based on the daily UMA and a new rule parameter, a percentage.

Task: 4465315

Forward-Port-Of: odoo/enterprise#78075

*: barcode, barcode_mrp This commit includes updates to and serial/lot number display features: - When the 'show sn/lot' feature is disabled for an operation type, unreserved serial/lot lines will no longer be highlighted with a red background. - The '/qty' demand field for sn/lot sublines is hidden when `Show Reserved SN/Lot` is disabled. Task: [3926998](https://www.odoo.com/odoo/my-tasks/3926998) Forward-Port-Of: odoo/enterprise#79118 Forward-Port-Of: odoo/enterprise#68153

*: barcode, barcode_mrp

This commit includes updates to and serial/lot number display
features:
- When the 'show sn/lot' feature is disabled for an operation type,
  unreserved serial/lot lines will no longer be highlighted with a
  red background.
- The '/qty' demand field for sn/lot sublines is hidden when
 `Show Reserved SN/Lot` is disabled.

Task: [3926998](https://www.odoo.com/odoo/my-tasks/3926998)

Forward-Port-Of: odoo/enterprise#79118
Forward-Port-Of: odoo/enterprise#68153

Previously, the database view generated for the meal vouchers report in the Belgian localization didn't have an id which caused an error on the runbot. This commit fixes this issue by generating the id. task-4463505 Forward-Port-Of: odoo/enterprise#76735

Previously, the database view generated for the  meal vouchers
report in the Belgian localization didn't have an id which
caused an error on the runbot.

This commit fixes this issue by generating the id.

task-4463505

Forward-Port-Of: odoo/enterprise#76735

ADHOC ticket 85864 Forward-Port-Of: odoo/enterprise#76488

ADHOC ticket 85864

Forward-Port-Of: odoo/enterprise#76488

Problem --------- Currently, there is a discrepancy between the year filter in the reports and spreadsheet. In the reports, when using the YEAR filter, it will use the fiscal year that ENDS in the set year. On the contrary, in spreadsheet, the filter will use the fiscal year that STARTS in the set year. For example, if the fiscal year starts on the 1st of April (01/04), - in the reports, the 2024 date range filters the moves between 01/04/2023 and 31/03/2024; - in spreadsheet, the 2024

Problem
---------
Currently, there is a discrepancy between the year filter in the reports and spreadsheet.

In the reports, when using the YEAR filter, it will use the fiscal year that ENDS in the set year. On the contrary, in spreadsheet, the filter will use the fiscal year that STARTS in the set year.

For example, if the fiscal year starts on the 1st of April (01/04),
- in the reports, the 2024 date range filters the moves between 01/04/2023 and 31/03/2024;
- in spreadsheet, the 2024 date range filters the moves between 01/04/2024 and 31/03/2025.

This behavior is explained by the fact that we use the current day to compute the fiscal year in the reports.

Objective
---------
Make the report year filter behave like in spreadsheet.

Solution
---------
Update the initiation of the date option in the report options so that, if the year filter is used, we compute the start of fiscal year that will begin in the selected year rather than the fiscal year we currently are in. We then use this fiscal year value to compute the relevant date range like before.

opw-4493556

Forward-Port-Of: odoo/enterprise#78486

The taxonomy for the Dutch tax reports was updated from [NT18 to NT19][1]. There were only changes in the namespaces. [1]: https://www.sbr-nl.nl/sites/default/files/bestanden/taxonomie/NT19_BD_20241211%20Versioning_rpt-from_NT18_20231213_to_NT19_20241211.zip [task-4373106](https://www.odoo.com/odoo/project.task/4373106) Forward-Port-Of: odoo/enterprise#78540

The taxonomy for the Dutch tax reports was updated from [NT18 to NT19][1]. There were only changes in the namespaces.

[1]: https://www.sbr-nl.nl/sites/default/files/bestanden/taxonomie/NT19_BD_20241211%20Versioning_rpt-from_NT18_20231213_to_NT19_20241211.zip

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

Forward-Port-Of: odoo/enterprise#78540

Bug introduced by this commit: https://github.com/odoo/enterprise/commit/4b312d56e7fa01ab4e8f534a1e62ef59e1421f77 Steps to reproduce the bug: - Create a storable product “P1” - Create two different MOs: - First MO: 1 unit of P1 - Second MO: 2 units of P1 - Confirm and mark them as done - Go to the manufacturing list view - Select both MOs - Print Cost Analysis Problem: The mo_qty is 2 units instead of 3; only the quantity of the last MO is taken into account. This is beca

Bug introduced by this commit: https://github.com/odoo/enterprise/commit/4b312d56e7fa01ab4e8f534a1e62ef59e1421f77

Steps to reproduce the bug:
- Create a storable product “P1”
- Create two different MOs:
    - First MO: 1 unit of P1
    - Second MO: 2 units of P1
- Confirm and mark them as done
- Go to the manufacturing list view
- Select both MOs
- Print Cost Analysis

Problem:
The mo_qty is 2 units instead of 3;
only the quantity of the last MO is taken into account. This is because, to calculate the total quantity of all MOs, we use a variable mo_qty, but it is initialized twice, once before the loop and again within the MO loop, so for each MO, the counter is reset to 0.

opw-4529333

Forward-Port-Of: odoo/enterprise#78731

### Steps to reproduce: - Create a bom for a product FP: - 1 x COMP (component) - operations: OP1: - instruction: - type: pass/fail, - Create and confirm an MO for 1 unit of FP - Go to the shopfloor, click on the instruction to open a dialog. - Spam the Pass button #### > Traceback: Uncaught Promise: Cannot read properties of undefined (reading 'resId') ### Cause of the issue: Clicking on a footer button of the `MrpQualityCheckConfirmationDialog` will trigger a

### Steps to reproduce:

- Create a bom for a product FP:
    - 1 x COMP (component)
    - operations: OP1:
        - instruction: - type: pass/fail,
- Create and confirm an MO for 1 unit of FP
- Go to the shopfloor, click on the instruction to open a dialog.
- Spam the Pass button

#### > Traceback: Uncaught Promise: Cannot read properties of undefined (reading 'resId')

### Cause of the issue:

Clicking on a footer button of the `MrpQualityCheckConfirmationDialog` will trigger a call of the `doActionAndClose` method: https://github.com/odoo/enterprise/blob/55c6292ff9d59ff09b1d81a61752765cf70d72c0/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.js#L93-L113 A the end of this call a `qualityCheckDone` is called to complete the operation which to work properly expects a `lastOpenedQualityCheck` to be set. However, at the end of this call, `displayInstruction` is called to generate a new MRP dialog for the next instuction if even exist. And, during this call if th ecurrent record (instruction) correspond to the `lastOpenedQualityCheck`, the value will be erased: https://github.com/odoo/enterprise/blob/55c6292ff9d59ff09b1d81a61752765cf70d72c0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L337-L340 This causes the error because if you click too fast you will clean the value that you are suppose to use in the next call `qualityCheckDone` which will explode.

### Fix:

We diasble the buttons of the Dialog once a a call of the `doActionAndClose` is triggered. That way, it becomes impossible to spam an action that is already processing the info. This is a backport the part of e4190f1ea2c89439d2cd4afa5137d0fedb06431e related to our issue. In addition to this bacport we apply this change on the `MrpRegisterProductionDialog` extending the `MrpQualityCheckConfirmationDialog` to limit the amount of rpc called performed by validating a registration (prior, you could spam the validate button to encode the exact same value multiple times).

### Note:

By opposition to e4190f1ea2c89439d2cd4afa5137d0fedb06431e we do not disable the buttons during the `openWorksheet` since a priori this action does not close the dialog and we might want to press other buttons on the dialog once this action has been performed.

opw-4352828

Forward-Port-Of: odoo/enterprise#79017
Forward-Port-Of: odoo/enterprise#74795

Forward-Port-Of: odoo/enterprise#79083

Forward-Port-Of: odoo/enterprise#79083

Before this PR: AEC file is sent encoded as base64. After this PR: we decode the file properly Forward-Port-Of: odoo/enterprise#79007

Before this PR: AEC file is sent encoded as base64.
After this PR: we decode the file properly

Forward-Port-Of: odoo/enterprise#79007

Demo combo products are now published on the eCommerce website, making them immediately available for testing. This helps teams validate the combo configurator more easily without extra setup.

Publishing the combo demo data on eCommerce makes it easier to test the combo configurator.

The Point of Sale screen now prevents users from clicking the Load Order button unless an order is selected. This avoids confusing or invalid actions and makes the checkout workflow clearer for staff.

Before it was possible to click on "load order" button even when there was no selected order. This commit disables the button when there is no selected order.

taskId: 4562723

Financial reports with custom grouping now keep the standard drill-down options while adding any custom ones. This helps users retain expected navigation options when they adjust how reports are grouped.

If a custom handler handles the caret builder, it used to only consider this function, and therefore not benefiting from the generic keys provided by the default function of the report engine. This can cause minor disadvantage such as when a user change himself the groupby keys of a report with a custom engine. In this case, the caret options won't be visible at all. With the change of this commit, the custom handler caret options will be used on top of the default ones.

task-4557882

This fix prevents an error when users update the duration of a manufacturing work order that depends on another unfinished work order. It improves reliability in manufacturing planning by allowing the change to be saved without interruption.

Steps to recreate the issue:

- Create a MO with the SEC-ASSEM bill of materials and confirm it
- Unblock the Drill 1 workcenter
- Start working on the packing work order
- Modify the duration on the long time assembly work order
- Save

Current behavior before PR:
Traceback

Desired behavior after PR is merged:
No traceback

When a work order depends on a another workorder, setting the duration on the depending work order will trigger a call to `_plan_workorder`, but all workorders don't necessarily have a leave_id as their depending on a non-finished work order.
The `min` and `max` functions can't work with False values, triggering the traceback.

task-id: 4282910

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

This fixes a website test flow that expected an extra menu button to always be available. The change prevents failures in single-app installations where there are fewer menus and that button may not appear.

The PR:
https://github.com/odoo/odoo/pull/197115
introduced some errors in the "single app" installation.

The step assumed that the "extra menu" button is always there to click it. It work on enterprise builds as there is so many menus that the "extra menu" button will always appear. But it's not the case in the single app tests.

To solve this issue, we partially revert a step to its original code

rb-116096

Installing the Monster recruitment integration no longer fails when all employment types have previously been removed. This prevents setup interruptions and lets businesses enable the recruitment connector even after customizing employment type records.

Currently a ``ParseError`` is arising when the user installs the ``hr_recruitment_integration_monster`` module after deleting all types from Employment Types.

Steps to reproduce:
---
- Install ``hr_contract`` module
- Open ``Employment Types`` and delete all types
- Now try to install the ``hr_recruitment_integration_monster`` module.

Traceback:
---
```
ParseError: while parsing /home/odoo/src/enterprise/18.0/hr_recruitment_integration_monster/data/hr_contract_type_data.xml:8, somewhere inside <record id="hr.contract_type_temporary" model="hr.contract.type">
            <field name="monster_id">2</field>
        </record>
 ```

This commit solves the above issue by using ``noupdate="1"`` and ``forcecreate="False"`` to bypass record creation if it violates checks.

sentry-5731062091

Fixed an issue where manually created variants of financial reports could initialize the same report options twice. This prevents duplicate action buttons, such as the Send button, and keeps report screens clearer for users.

To reproduce:
(Note that this needs to be donne before https://github.com/odoo/enterprise/commit/03fd8fa9ce59f3b052ba112612ee288cd44f045a ; you can easily replicate by indenting the add of the "Send" button one more level to the left, so that the button is always added, as it used to be)

1) Duplicate the Partner Ledger
2) Set the original Partner Ledger as the root report of the duplicate 3) Open the Partner Ledger, and select the duplicate in the variant selector

===> The "Send" button is displayed twice on top of the report.

This is due to the fact the custom handler is first called by the report itself (since the duplicate kept the same handler as the root Partner Ledger), then by the call to super() made in the _custom_options_initializer.

In the case of the Partner Ledger, we could have removed that super call (since it's a root report), but we prefer a more generic and cleaner fix that just makes sure we don't reinitialize the same custom options if we notice the handler is the same.

opw-4506968

**Current behavior:** After commit https://github.com/odoo/odoo/commit/7c808beaf36853b4d9171ef0981d1ec9c4b73a44 all writes on `date_start` would silently alter the written date value (totally unintuiative for a user & undesired behavior regardless). **Expected behavior:** Only when handling indirect writes on `date_start` from a linked-via-subcontract purchase order should we modify `date_start` to account for the manufacture delay. opw-4489485 Forward-Port-Of: odoo/odoo#196809 Forw

**Current behavior:**
After commit https://github.com/odoo/odoo/commit/7c808beaf36853b4d9171ef0981d1ec9c4b73a44 all writes on `date_start` would silently
alter the written date value (totally unintuiative for a user &
undesired behavior regardless).

**Expected behavior:**
Only when handling indirect writes on `date_start` from a
linked-via-subcontract purchase order should we modify
`date_start` to account for the manufacture delay.

opw-4489485

Forward-Port-Of: odoo/odoo#196809
Forward-Port-Of: odoo/odoo#195742

- saas-17.4 ### Steps to reproduce: - Install the hr_timesheet module. - Create a portal user. - Create a project, task, and sub-task (with timesheet entries). - Share the project with the portal user. - Log in as the portal user. - Open the shared project and navigate to the task. - Click on the Time Spent on Sub-tasks action. ### Issue: Traceback error ### Cause: Tries to load timesheet timer header. ### Solution: Remove the timesheet header from the portal list view. The

- saas-17.4

### Steps to reproduce:
- Install the hr_timesheet module.
- Create a portal user.
- Create a project, task, and sub-task (with timesheet entries).
- Share the project with the portal user.
- Log in as the portal user.
- Open the shared project and navigate to the task.
- Click on the Time Spent on Sub-tasks action.

### Issue:
Traceback error

### Cause:
Tries to load timesheet timer header.

### Solution:
Remove the timesheet header from the portal list view. The timesheet header is not displayed to internal users, so we can remove it for portal users.


task-4369891


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

Forward-Port-Of: odoo/odoo#190150

The installation of the demo data of module `industry_fsm_sale` module triggered the sending of an SMS. Now, the SMS API is unavailable during module installation. Forward-Port-Of: odoo/odoo#197356 Forward-Port-Of: odoo/odoo#196671

The installation of the demo data of module `industry_fsm_sale` module triggered the sending of an SMS.
Now, the SMS API is unavailable during module installation.

Forward-Port-Of: odoo/odoo#197356
Forward-Port-Of: odoo/odoo#196671

**Current behavior:** In the product catalog, a search Panel is displayed. The user can check filters to find their products. When a category or another filter is checked, the attributes filters are not updated accordingly, even if they are no longer present in the products of the selected category. **Expected behavior:** The attributes that do not have a positive count should disappear from the Search Panel. **Steps to reproduce:** 1. On a blank database, create two products:

**Current behavior:**
In the product catalog, a search Panel is displayed. The user can check filters to find their products. When a category or another filter is checked, the attributes filters are not updated accordingly, even if they are no longer present in the products of the selected category.

**Expected behavior:**
The attributes that do not have a positive count should disappear from the Search Panel.

**Steps to reproduce:**
1. On a blank database, create two products: 
        1.1 Product A, with category CA and attributes A1 and A2.
        1.2 Product B, with category CB and attributes B1 and B2.
3. Go to Sales Order, create a new one and open the product catalog
4. The left search Panel should display the categories CA and CB, and the attributes A1, A2, B1, and B2.
5. Check the category CB.
6. Attributes A1 and A2 are still present.

**Cause of the issue:**
The search Panel JS script is modified by the `product` model, to add the Attributes section. However, the attributes are not filtered based on the selected category, and are always displayed.

**Fix:**
- Add a filtering condition in the `product` model to only display the attributes that have a positive `count`.

![all_category](https://github.com/user-attachments/assets/2121ecbb-9bed-4d3c-9f5f-c4cf309350ff)
![fix_difference](https://github.com/user-attachments/assets/612e0eeb-09c5-47eb-948f-8c8be204f862)

opw-4516166

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

Forward-Port-Of: odoo/odoo#197116

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

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: - Create a storable product FP tracked by SN with a BOM: - 1 Operation: - instruction: Register Production type (per product) - 1 x Comp (storable product in stock) - Create and confirm an MO for one unit of FP. - Go to the shopfoor app > open the instruction of your operation - Type a non-existing serial number in the search bar > Create "new_sn" > This opens a form view of the stock.lot model - Save and close the new stock.lot > Invalid operation: You

### Steps to reproduce:

- Create a storable product FP tracked by SN with a BOM:
    - 1 Operation: - instruction: Register Production type (per product)
    - 1 x Comp (storable product in stock)
- Create and confirm an MO for one unit of FP.
- Go to the shopfoor app > open the instruction of your operation
- Type a non-existing serial number in the search bar > Create "new_sn"
> This opens a form view of the stock.lot model
- Save and close the new stock.lot
> Invalid operation: You are not allowed to create or edit a lot or serial number for the components with the operation type
> "Manufacturing". To change this, go on the operation type and tick the box "Create New Lots/Serial Numbers for
> Components"

#### Expected behavior:

The invalid operation should not be raised as the "required" option concerns only componenets and not final products.

### Cause of the issue:

Creating a stock lot will first launch a call of the `_check_create`: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/stock/models/stock_lot.py#L150-L153 However, since this check does not verifies that the product for which we create the lot is indeed related to a component of the MO it will raise the invalid operation even for final products: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/mrp/models/stock_lot.py#L11-L17

### Issue 2:

Currently, the `quickCreate` ("Create *sn_name*") option of the lot field of te "register production" dialog calls a `name_create` that will set an error message in the logs as the product_id required field can not be provided neither in the vals or the context of the `name_create`.  You then fall back on the same form dialog than the "Create and edit".  The `quickCreate` option should therefore just be disabled.

Enterprise: https://github.com/odoo/enterprise/pull/77265

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

Forward-Port-Of: odoo/odoo#197155
Forward-Port-Of: odoo/odoo#193965

Versions -------- - 16.0+ Steps ----- 1. Set up a company located in United Arab Emirates; 2. go to Payment Providers / Stripe; 3. click the Connect Stripe button; Issue ----- > **Validation Error** > Stripe Proxy error: an error occurred while setting up your Stripe account. > Stripe gave us the following information: 'individual' is not a supported business type in the country AE. Cause ----- The initial payload sent to Stripe to connect in live mode is with `business_type

Versions
--------
- 16.0+

Steps
-----
1. Set up a company located in United Arab Emirates;
2. go to Payment Providers / Stripe;
3. click the Connect Stripe button;

Issue
-----
> **Validation Error**
> Stripe Proxy error: an error occurred while setting up your Stripe account.
> Stripe gave us the following information: 'individual' is not a supported business type in the country AE.

Cause
-----
The initial payload sent to Stripe to connect in live mode is with `business_type: individual`. This default works for most locales, but for some, e.g. `l10n_ae`, a "registered business" is required.

Solution
--------
Connect to Stripe using `business_type: company`.

This value can still be changed later _after_ entering live mode via `connect.stripe.com`.

opw-4545565

Forward-Port-Of: odoo/odoo#197367
Forward-Port-Of: odoo/odoo#197222

Versions -------- - 17.0+ Steps ----- 1. Add 5+ lines to a product's eCommerce description; 2. add this product to your wishlist; 3. open wishlist. Issue ----- The table's border is broken, left of the image. Cause ----- Commit 196f34c6b5271 added the Bootstrap classes `d-none d-md-block` to the table row, in order to hide the image on small devices. The `d-md-block` class cancels out its existing `align-middle` class, which only affects `inline` or `table-cell` elements, not

Versions
--------
- 17.0+

Steps
-----
1. Add 5+ lines to a product's eCommerce description;
2. add this product to your wishlist;
3. open wishlist.

Issue
-----
The table's border is broken, left of the image.

Cause
-----
Commit 196f34c6b5271 added the Bootstrap classes `d-none d-md-block` to the table row, in order to hide the image on small devices. The `d-md-block` class cancels out its existing `align-middle` class, which only affects `inline` or `table-cell` elements, not `block` elements. Consequently, the `vertical-align: middle` CSS rule is ignored, leaving the image unaligned on top of the table.

Solution
--------
Replace `d-md-block` with `d-md-table-cell`.

opw-4260090

Forward-Port-Of: odoo/odoo#197304

Previously, the company check on a relational field was ensuring that at least one of the related records had a compatible company. This worked fine for many2one fields, which have a single related record, but not for one2many and many2many fields, which can have multiple related records (only one of them needed to have a compatible company for the check to succeed). This fix rewrites the company check to ensure that none of the related records have an incompatible company. Forward-Port-Of:

Previously, the company check on a relational field was ensuring that at least one of the related records had a compatible company. This worked fine for many2one fields, which have a single related record, but not for one2many and many2many fields, which can have multiple related records (only one of them needed to have a compatible company for the check to succeed).

This fix rewrites the company check to ensure that none of the related records have an incompatible company.

Forward-Port-Of: odoo/odoo#189847

Before this PR: Placeholder for empty char/text fields were disappearing in editor. <br> Steps to reproduce: 1. Open any appointment page with an operator assigned. 2. Go into edit mode. 3. The field with the placeholder "Add a function here..." will disappear. > Similar issue can be seen for any char/text field types. <br> The issue occurs after the https://github.com/odoo/odoo/pull/165197 update, which uses the fillEmpty utility function to add: - \<br> in empty **block** fields

Before this PR:
Placeholder for empty char/text fields were disappearing in editor.
<br>

Steps to reproduce:
1. Open any appointment page with an operator assigned.
2. Go into edit mode.
3. The field with the placeholder "Add a function here..." will disappear.
> Similar issue can be seen for any char/text field types.
<br>

The issue occurs after the https://github.com/odoo/odoo/pull/165197 update, which uses the fillEmpty utility function to add:
- \<br> in empty **block** fields (char/text)
- and Zero Width Space (ZWS) in empty **inline** fields (char/text)

Since placeholders for fields are added via SCSS targeting empty fields, the char/text fields are no longer considered empty due to the \<br> tag and ZWS. As a result, placeholders are not displayed.
<br>

This fix ensures that the SCSS now applies the same styling to fields if they are empty, contain only a \<br> tag, or contain only ZWS.

Additionally, the value for `data-oe-zws-empty-inline` attribute is now updated dynamically, enabling CSS to target fields with only ZWS content, as ZWS cannot be selected directly from CSS.
<br>

task-4297507

Forward-Port-Of: odoo/odoo#187892

When having other modules that depend on the module, if they make an inheritance of the method `_cart_update` like it is on the original method from module `website_sale` (with parameters and then `kwargs`) the inheritance of this module fails, because neither `product_id` nor `set_qty` came on the `kwargs` values instead they came in the `args`.  ![Website Loyalty error with PDB](https

When having other modules that depend on the module, if they make an inheritance of the method `_cart_update` like it is on the original method from module `website_sale` (with parameters and then `kwargs`) the inheritance of this module fails, because neither `product_id` nor `set_qty` came on the `kwargs` values instead they came in the `args`.

![Website Loyalty error](https://github.com/user-attachments/assets/ebe7a8dc-7b7c-4f11-8064-bcc7c24218bf)

![Website Loyalty error with PDB](https://github.com/user-attachments/assets/2bf85807-f230-4e65-9090-b6c1e390682e)


By inheriting the way the original method is set, it will avoid having to check on the `args` or `kwargs` for the `product_id` and `set_qty` values and use the parameters instead.

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

Forward-Port-Of: odoo/odoo#197290
Forward-Port-Of: odoo/odoo#197032

Comparing times may give false error because of the precision and time to run a test. This commit adds a delta into which two datetime are considered the same in order to not make the test failing by mistake. runbot : 112119 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#196833 Forward-Port

Comparing times may give false error because of the precision and time to run a test. This commit adds a delta into which two datetime are considered the same in order to not make the test failing by mistake.

runbot : 112119

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#196833
Forward-Port-Of: odoo/odoo#195457

**Current behaviour before PR:** When single cell is selected in a table, trying to apply color closes color palette and color is not getting applied on it. This happens because applying color on single cell changes selection and cell gets deselected in _onSelectionChange. **Desired behaviour after PR:** Now, it is possible to apply color on a single cell. task-3433784 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Por

**Current behaviour before PR:**

When single cell is selected in a table, trying to apply color closes color palette and color is not getting applied
on it. This happens because applying color on single cell changes selection and cell gets deselected in _onSelectionChange.


**Desired behaviour after PR:**

Now, it is possible to apply color on a single cell.

task-3433784




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

Forward-Port-Of: odoo/odoo#196255
Forward-Port-Of: odoo/odoo#173845

**Current behavior:** The `report.stock.quantity` view may attribute and incorrect destination location with a move when building the report: Specifically, it will coalesce a move's `location_dest_id` and `location_final_id` regardless of the state of the move and where the product qty was actually transferred to. **Expected behavior:** If the move is completed, the actual location of where it moved product should be used to fill in the destination location. **Steps to reproduce:*

**Current behavior:**
The `report.stock.quantity` view may attribute and incorrect
destination location with a move when building the report:

Specifically, it will coalesce a move's `location_dest_id` and
`location_final_id` regardless of the state of the move and
where the product qty was actually transferred to.

**Expected behavior:**
If the move is completed, the actual location of where it moved
product should be used to fill in the destination location.

**Steps to reproduce:**
1. Enable 2-step delivery

2. Create an in move for some tracked productA -> validate

3. Create a sale order for the same productA, confirm, then
validate the first picking in the chain

4. Look at the forecast for productA, observe that it has the
positive quantity from the in move furter in the past then it
should

**Cause of the issue:**
When a StockMove was completed, it's `location_final_id` was
taken over its `location_dest_id`, which meant the actual
location that the move transferred product to was not reflected
in the quantity report, meaning you could have a case as
described above where the forecast quantity becomes imbalanced
because it is not properly counting moves against would-be
offsetting ones.

**Fix:**
Don't prefer `location_final_id` when `move.state == 'done'`.

opw-4311583

Forward-Port-Of: odoo/odoo#192440

Version: 16.0 to master Browser: Firefox only Steps to Reproduce: 1. Open website in edit mode (In Desktop) 2. Open inspect element, switch to mobile view (Inspector mobile view) 3. Click burger menu to open 4. Traceback occurs Reason for Change: In Firefox, when the inspector's mobile view is used, it simulates touch events. Clicking the burger menu returns undefined, causing an error. This PR ensures that the page does not crash by handling the undefined case. task-398098

Version: 16.0 to master
Browser: Firefox only

Steps to Reproduce:
1. Open website in edit mode (In Desktop)
2. Open inspect element, switch to mobile view (Inspector mobile view)
3. Click burger menu to open
4. Traceback occurs

Reason for Change:
 In Firefox, when the inspector's mobile view is used, it simulates
 touch events. Clicking the burger menu returns undefined, causing an
 error. This PR ensures that the page does not crash by handling the
 undefined case.

task-3980983

Forward-Port-Of: odoo/odoo#173785

Steps to Reproduce: * Go to Website --> Edit Mode. * Drag and drop the form snippet. * Click inside the submit button such that the entire label "Submit" is selected. * Press the right arrow key. * The website will become unresponsive. **Changes made:** Assign `previousSelection` with the following properties: `anchorNode: selection.anchorNode` `anchorOffset: selection.anchorOffset` `focusNode: selection.focusNode` `focusOffset: selection.focusOffset` **Reason:**

Steps to Reproduce:

* Go to Website --> Edit Mode.
* Drag and drop the form snippet.
* Click inside the submit button such that the entire label "Submit" is
  selected.
* Press the right arrow key.
* The website will become unresponsive.


**Changes made:**

Assign `previousSelection` with the following properties:
 `anchorNode: selection.anchorNode`
 `anchorOffset: selection.anchorOffset`
 `focusNode: selection.focusNode`
 `focusOffset: selection.focusOffset`

**Reason:**

The original code attempted to spread the Selection object into previousSelection using **{...selection}**, which is incorrect since **the Selection object is not iterable**. As a result, `previousSelection` was never updated correctly, potentially causing the while loop to run indefinitely.

This fix manually extracts key properties—anchorNode, anchorOffset, focusNode, and focusOffset—from the Selection object and stores them in a plain object. This ensures that previousSelection updates properly, allowing the `hasSelectionChanged` function to function as expected.

By implementing this change, we prevent infinite loops and ensure accurate selection tracking, improving the stability and functionality of the text editor.

task-4471656

Forward-Port-Of: odoo/odoo#197010
Forward-Port-Of: odoo/odoo#194061

## Versions: 17.0+ ## Issue: Translation of the English "Balance" word is displayed as "Balanza" in all Spanish files but should be "Balance" as well. "Balanza" meaning "Scale", the translation is sometimes right. opw-4461450 Forward-Port-Of: odoo/enterprise#78116

## Versions:
17.0+

## Issue:
Translation of the English "Balance" word is displayed as "Balanza" in all Spanish files but should be "Balance" as well. "Balanza" meaning "Scale", the translation is sometimes right.

opw-4461450

Forward-Port-Of: odoo/enterprise#78116

Different countries have different attendance rules and therefore customizing the attendance entries might be relevant. In order to be able to properly filter we introduce a domain retrieval method which can be properly inherited. Info: @wt-io-it Forward-Port-Of: odoo/enterprise#78195

Different countries have different attendance rules and therefore customizing the attendance entries might be relevant.
In order to be able to properly filter we introduce a domain retrieval method which can be properly inherited.

Info: @wt-io-it

Forward-Port-Of: odoo/enterprise#78195

Before when sending request to hmrc we had a fraud prevention headers creation but only with part of the data needed, client_data was provided for one of the two request. Another problem was the ips. If we are in a private network we should still send the public IP. task-4387562 Forward-Port-Of: odoo/enterprise#78964 Forward-Port-Of: odoo/enterprise#75383

Before when sending request to hmrc we had a fraud prevention headers creation but only with part of the data needed, client_data was provided for one of the two request.
Another problem was the ips. If we are in a private network we should still send the public IP.

task-4387562

Forward-Port-Of: odoo/enterprise#78964
Forward-Port-Of: odoo/enterprise#75383

No description available.

In Chile localization it is possible to add a Related Document when creating an Invoice Document. These documents info are then added to the Electronic Invoice sent to the government. Currently, when creating a Boleta Electronica and adding a Cross Reference Document, the EDI system will not validate correctly the xml, with error `Error en Schema [0] LSX-00204: extra data at end of complex element` This occurs because the system first creates a dte from a common xml schema, then wrap

In Chile localization it is possible to add a Related Document when
creating an Invoice Document. These documents info are then added to the Electronic
Invoice sent to the government.

Currently, when creating a Boleta Electronica and adding a Cross
Reference Document, the EDI system will not validate correctly the xml,
with error
`Error en Schema [0] LSX-00204: extra data at end of complex element`

This occurs because the system first creates a dte from a common xml schema, then
wrap it with the appropriate envelope.
However the schema of Boletas slighly differs[1], as it doesn't have the
field FchRef, so it gets rejected by SII

A solution is to modify the code of dte_subtemplate to make sure that FchRef
only appears if the Schema corresponds to http://www.sii.cl/SiiDte EnvioDTE_v10.xsd,
and not to http://www.sii.cl/SiiDte EnvioBOLETA_v11.xsd

[1] https://www.sii.cl/factura_electronica/factura_mercado/formato_boletas_elec_202412.pdf

opw-4433202

Forward-Port-Of: odoo/enterprise#78177

### Steps to reproduce: - Create a storable product FP tracked by SN with a BOM: - 1 Operation: - instruction: Register Production type (per product) - 1 x Comp (storable product in stock) - Create and confirm an MO for one unit of FP. - Go to the shopfoor app > open the instruction of your operation - Type a non-existing serial number in the search bar > Create "new_sn" > This opens a form view of the stock.lot model - Save and close the new stock.lot > Invalid operation: You

### Steps to reproduce:

- Create a storable product FP tracked by SN with a BOM:
    - 1 Operation: - instruction: Register Production type (per product)
    - 1 x Comp (storable product in stock)
- Create and confirm an MO for one unit of FP.
- Go to the shopfoor app > open the instruction of your operation
- Type a non-existing serial number in the search bar > Create "new_sn"
> This opens a form view of the stock.lot model
- Save and close the new stock.lot
> Invalid operation: You are not allowed to create or edit a lot or serial number for the components with the operation type
> "Manufacturing". To change this, go on the operation type and tick the box "Create New Lots/Serial Numbers for
> Components"

#### Expected behavior:

The invalid operation should not be raised as the "required" option concerns only componenets and not final products.

### Cause of the issue:

Creating a stock lot will first launch a call of the `_check_create`: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/stock/models/stock_lot.py#L150-L153 However, since this check does not verifies that the product for which we create the lot is indeed related to a component of the MO it will raise the invalid operation even for final products: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/mrp/models/stock_lot.py#L11-L17

### Issue 2:

Currently, the `quickCreate` ("Create *sn_name*") option of the lot field of te "register production" dialog calls a `name_create` that will set an error message in the logs as the product_id required field can not be provided neither in the vals or the context of the `name_create`.  You then fall back on the same form dialog than the "Create and edit".  The `quickCreate` option should therefore just be disabled.

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

opw-4452747
---

Forward-Port-Of: odoo/enterprise#78966
Forward-Port-Of: odoo/enterprise#77265

Forward-Port-Of: odoo/enterprise#79083

Forward-Port-Of: odoo/enterprise#79083

Previously, the database view generated for the meal vouchers report in the Belgian localization didn't have an id which caused an error on the runbot. This commit fixes this issue by generating the id. task-4463505 Forward-Port-Of: odoo/enterprise#76735

Previously, the database view generated for the  meal vouchers
report in the Belgian localization didn't have an id which
caused an error on the runbot.

This commit fixes this issue by generating the id.

task-4463505

Forward-Port-Of: odoo/enterprise#76735

Problem --------- Currently, there is a discrepancy between the year filter in the reports and spreadsheet. In the reports, when using the YEAR filter, it will use the fiscal year that ENDS in the set year. On the contrary, in spreadsheet, the filter will use the fiscal year that STARTS in the set year. For example, if the fiscal year starts on the 1st of April (01/04), - in the reports, the 2024 date range filters the moves between 01/04/2023 and 31/03/2024; - in spreadsheet, the 2024

Problem
---------
Currently, there is a discrepancy between the year filter in the reports and spreadsheet.

In the reports, when using the YEAR filter, it will use the fiscal year that ENDS in the set year. On the contrary, in spreadsheet, the filter will use the fiscal year that STARTS in the set year.

For example, if the fiscal year starts on the 1st of April (01/04),
- in the reports, the 2024 date range filters the moves between 01/04/2023 and 31/03/2024;
- in spreadsheet, the 2024 date range filters the moves between 01/04/2024 and 31/03/2025.

This behavior is explained by the fact that we use the current day to compute the fiscal year in the reports.

Objective
---------
Make the report year filter behave like in spreadsheet.

Solution
---------
Update the initiation of the date option in the report options so that, if the year filter is used, we compute the start of fiscal year that will begin in the selected year rather than the fiscal year we currently are in. We then use this fiscal year value to compute the relevant date range like before.

opw-4493556

Forward-Port-Of: odoo/enterprise#78486

ADHOC ticket 85864 Forward-Port-Of: odoo/enterprise#76488

ADHOC ticket 85864

Forward-Port-Of: odoo/enterprise#76488

This commit fixes the following issues of the module l10n_cz_reports_2025: 1. The `tax_office_name` was changed to `name` but that change was dropped in _rec_names_search of the tax office. 2. The readonly attribute was duplicated in account move view. 3. The account_move_line supplies code compute method was different from that of the transaction code (although the logic is identical). Forward-Port-Of: odoo/enterprise#78960

This commit fixes the following issues of the module l10n_cz_reports_2025:
1. The `tax_office_name` was changed to `name` but that change was dropped in _rec_names_search of the tax office.
2. The readonly attribute was duplicated in account move view.
3. The account_move_line supplies code compute method was different from that of the transaction code (although the logic is identical).

Forward-Port-Of: odoo/enterprise#78960

Before this commit: When using the sign app, after clicking on a signature field to sign, attempting to drag the signature field away, which is unnecessary and pointless, causes the app to crash. After this commit: Dragging a signed signature field is not possible since it is pointless. The file should remain unchanged, and no crash should occur. Merge Note: This fix should be applied for the branches > 17.0 and before 18.1. It should be ignored by 18.1 and after. task-4489008 Forw

Before this commit:

When using the sign app, after clicking on a signature field to sign, attempting to drag the signature field away, which is unnecessary and pointless, causes the app to crash.

After this commit:
Dragging a signed signature field is not possible since it is pointless. The file should remain unchanged, and no crash should occur.

Merge Note: This fix should be applied for the branches > 17.0 and before 18.1. It should be ignored by 18.1 and after.

task-4489008

Forward-Port-Of: odoo/enterprise#78823
Forward-Port-Of: odoo/enterprise#77325

The taxonomy for the Dutch tax reports was updated from [NT18 to NT19][1]. There were only changes in the namespaces. [1]: https://www.sbr-nl.nl/sites/default/files/bestanden/taxonomie/NT19_BD_20241211%20Versioning_rpt-from_NT18_20231213_to_NT19_20241211.zip [task-4373106](https://www.odoo.com/odoo/project.task/4373106) Forward-Port-Of: odoo/enterprise#78540

The taxonomy for the Dutch tax reports was updated from [NT18 to NT19][1]. There were only changes in the namespaces.

[1]: https://www.sbr-nl.nl/sites/default/files/bestanden/taxonomie/NT19_BD_20241211%20Versioning_rpt-from_NT18_20231213_to_NT19_20241211.zip

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

Forward-Port-Of: odoo/enterprise#78540