Odoo Changelog — 2026-02-09

Monday, February 9, 2026

13 changes · 19.0

Bug Fixes(13)

Resolved issues and error corrections

[FIX] industry_fsm_sale: fix borders in field service report tables

Enterprise19.0industry_fsm_sale

This update fixes a visual inconsistency in the Field Service Report generated from the Bubble document layout. Previously, table borders appeared with mixed rounded and sharp edges. The fix adds a consistent border style to the tables, ensuring a cleaner and more professional appearance for this report.

Original PR description

Steps to reproduce: -------------------------------- 1. Install `industry_fsm_sale` module 2. Go to Settings > Configure Document Layout 3. Select the Bubble document layout and save 4. Open any…

Steps to reproduce:
--------------------------------
1. Install `industry_fsm_sale` module
2. Go to Settings > Configure Document Layout
3. Select the Bubble document layout and save
4. Open any Field Service task
5. Use the Products smart button to add one or more products
6. Click the Settings icon > Print > Field Service Report

Observation:
--------------------------------
In Time & Material tables using the Bubble layout, table borders show a mix of rounded corners and sharp edges, resulting in inconsistent visuals

Issue:
--------------------------------
The table tags in the report were missing the `table-borderless` class. As a result, the layout-applied rounded borders conflicted with the default table borders

Solution:
--------------------------------
Add the `table-borderless` class to the affected table tags so the tables inherit consistent rounded borders from the document layout


Before:
<img width="787" height="317" alt="before_css" src="https://github.com/user-attachments/assets/dac136a8-022a-4c36-8cdb-1c0fbb048f3e" />


After:
<img width="816" height="372" alt="after_css" src="https://github.com/user-attachments/assets/b5f96e75-2cd3-44cf-89e3-9a3b564c8369" />


opw-5401612

Forward-Port-Of: odoo/enterprise#105616

#reports#field service#visuals

[FIX] *: display message when failing a check

PR #106711

Enterprise19.0quality_mrp_workorderMEDIUM

This update fixes an issue where failure messages weren't shown when a quality check was marked as failed. The change ensures that the correct failure message appears immediately after a quality check is marked as failed, improving user feedback and process clarity. This was achieved by correctly passing the view to display the failure message.

Original PR description

*= quality_control, quality_mrp_workorder, mrp_workorder

Currently, when a user fails a quality check using the quick-action button, the failure message defined for that quality control point isn’t shown.

**Steps to produce:**
* Install `Quality` and `Manufacturing` with demo data
* Go to MRP > Configuration > Operations > Manual Assembly
* Create a pass/fail quality point with a failure message
* Create and confirm an MO for `Table Top`
* Go to Shop Floor > Activate work centers if inactive > Manual Assembly
* Fail the assembly using the quick-action button

Replication video: [Link](https://drive.google.com/file/d/1gBHrvQEAavhjU4lS-bKQHQjAa9qDHj6-/view?usp=sharing)

**Observed Behavior:**
* No failure message is displayed when the quality check is failed.

**Root cause:**
* This happens because pressing the quick-action button triggers `failCheck` [1] , which calls `doActionNext` [2], which then runs the server function `action_fail_and_next` [3]. That function sets `quality_state = fail` and calls [4] to get the view. But since [3] wraps that view inside a dictionary, the check in [5] never passes, so the message never appears.

**Solution:**
* Pass the view correctly to display the failure message. Since the quick action already marks the quality state as failed we can hide the Confirm and Back buttons by passing the context and checking it in the view to show a single OK button, similar to earlier versions.


**Before:**
<img width="1673" height="813" alt="image" src="https://github.com/user-attachments/assets/029e347b-5f2c-463a-833e-3b55677137b6" />

**After:**
<img width="1687" height="829" alt="image" src="https://github.com/user-attachments/assets/e4c85093-ea0d-44ca-bc9c-0fab5ac08fbc" />


[1]:
https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/static/src/mrp_display/quality_check.js#L83-L86 
[2]:
https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/mrp_workorder/static/src/mrp_display/mrp_record_line/quality_check.js#L147-L163 
[3]:
https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/models/quality.py#L86-L89 
[4]:
https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/models/quality.py#L48-L68 
[5]:
https://github.com/odoo/enterprise/blob/19.0/mrp_workorder/static/src/mrp_display/mrp_record_line/quality_check.js#L154-L161

opw-5403465

Forward-Port-Of: odoo/enterprise#102095

#quality#mrp#workflow

[FIX] hr_work_entry_attendance: prevent error when removing employee working hours

PR #103811

Enterprise19.0hr_work_entry_attendance

This update resolves an error that occurred when creating attendance records for employees without defined 'Working Hours'. The fix prevents a system crash caused by attempting to access data within an empty dictionary, ensuring smoother attendance creation processes. This improves the reliability of the attendance module.

Original PR description

This error occurs when attempting to create an attendance for an employee who has no `Working Hours` defined.

Steps to reproduce:
- Install `hr_work_entry_attendance` module
- Employees > `Administrator` > Settings > Set `Default Ruleset` in Overtime Ruleset > Payroll > Set Contract and `Work Entry Source` is in `Attendance`
- Attendance > Create New Attendance(with Extra Hours) and Save
- Remove `Working Hours` of employee

Traceback:
`KeyError: 52`

We encounter this error at [1] because `lunch_by_resource` is empty "**{}**", and we attempt to access a key in this empty dictionary.

[1]- https://github.com/odoo/enterprise/blob/b94ae7a4f8ae91ad98977a439db41a6939a6b617/hr_work_entry_attendance/models/hr_version.py#L80

sentry-7168309352

#attendance#hr#error

[FIX] account_reports: wrong link to journal items from reports

PR #106793

Enterprise19.0account_reports

This update resolves an issue where journal items displayed in reports were incorrectly linked to account groups, causing errors starting with Odoo 18.3. The fix ensures accurate linking by adjusting how Odoo queries for related accounts, preventing a previous error related to a changed data field.

Original PR description

Currently journal items shown don't belong to the account group that
they should belong to, and from saas-18.3 an error will be generated
after following the below steps or step mentioned in ref PR [1].

- Install `Accounting (accountant)` with demo data
- Create account groups e.g., name as `Test 1` and code prefix `1 to 1`
- Go to the general ledger report
- Click on `Journal Items` of the account group line `1 Test 1`

Error from saas-18.3:
`ValueError: Cannot convert account.account.group_id to SQL because it is ...`

This error occurs because PR with ref [1] in 17.0 added the` group_id` field of the
`account.account` model to the search domain. However, in 18.0, commit [2] modified
this field so that it is no longer stored. As a result, when a search domain includes
this `non-stored` field, Odoo skips the domain evaluation and logs a error at code
line [3]. Consequently, the changes introduced by commit [1] have no functional effect from 18.0.

Also, starting from saas-18.3, passing such a non-stored field in a domain raises an
explicit error at code line [4], instead of being silently ignored.

This commit resolves the issue by introducing an SQL query that
returns the account ids related to `record_id(account group id)`
include `record_id` as `None`.

[1]: https://github.com/odoo/enterprise/pull/100191
[2]: https://github.com/odoo/odoo/commit/854c3b27aa5476c208572f19e64f8f3364bfc381#diff-19ef5a530c506fdee93fe0d113e61946b87fae7dd2d360558da69c0014f766b2R114-R767
[3]: https://github.com/odoo/odoo/blob/71e86f38c7699aaea980c929c67835a3495edf55/odoo/osv/expression.py#L1166-L1174
[4]: https://github.com/odoo/odoo/blob/00517e9e085c6fa9e00bedb8aee122a60e407fea/odoo/orm/fields.py#L1201

sentry-7100657414

Forward-Port-Of: odoo/enterprise#103137

#reporting#accounting

[FIX] account_reports: ensure you can change account audit statuses in bulk

PR #104818

Enterprise19.0account

This update resolves an issue preventing users from efficiently changing the status of multiple audit accounts. Previously, a technical error would occur when attempting bulk updates. The fix ensures a smoother workflow for managing audit statuses, improving operational efficiency.

Original PR description

### Steps to reproduce:
- In Accounting, make sure you have the accountant model. Then, from Review > Audit > Working Files, click Balances.
- Select more than 1 account lines and try to change their statuses.
- If you don't have an Audit, create a new one and go back to Working files, then click balances.
### Cause:
The client gets a traceback when they try to change the statuses of the audits for the accounts in bulks.
opw-5474248

#accounting#audit#workflow

[FIX] l10n_be_reports: include all partners in VAT listing XML export

PR #106134

Enterprise19.0l10n_be_reportsMEDIUM

This update fixes an issue where the XML export for Belgium VAT listings was incomplete, only including the initial batch of partners. The change adjusts the export process to ensure all partners, regardless of the 'Load More' setting, are correctly included in the generated XML file. This improves the accuracy of VAT reporting.

Original PR description

# Observed behavior:
* The XML file contains only the first batch of partners.
* Partners shown after clicking **Load More** are missing from the export.

# Cause:
* In v17, the XML export button was defined as:
https://github.com/odoo/enterprise/blob/42ef1fe589fc4e7fe4b611736253251c44506578/l10n_be_reports/models/partner_vat_listing.py#L53-L59
* This meant clicking the button would go through the [export_file](https://github.com/odoo/enterprise/blob/42ef1fe589fc4e7fe4b611736253251c44506578/account_reports/models/account_report.py#L4927)
method, which sets `options['export_mode'] = 'file'` before calling the export function. The test in v17 explicitly sets `export_mode = 'file'` to simulate what `export_file` does in production.

* In v19, the architecture changed:
- The XML export is now triggered via the account.return workflow and a submission wizard [1.](https://github.com/odoo/enterprise/blob/19.0/l10n_be_reports/wizard/vat_listing_submission_wizard.py)
- The wizard's `print_xml` method calls [_get_closing_report_options()](https://github.com/odoo/enterprise/blob/19.0/account_reports/models/account_return.py#L1601) which does NOT set `export_mode = 'file'`.
- The controller then calls `dispatch_report_action(options, file_generator)` directly, bypassing `export_file`.

* Why the test changed:
- In v17 test: `export_mode = 'file'` was set to mimic the `export_file` → `partner_vat_listing_export_to_xml` flow.
- In v19 test: `export_mode = 'file'` should NOT be needed in the test because the fix is to set `export_mode = 'file'` inside `partner_vat_listing_export_to_xml` itself.

# Fix:
* Enable **export mode** when generating the XML.
* Ensures all partners are included regardless of the load limit.

opw-5494247

#reporting#VAT#Belgium

[FIX] l10n_au_hr_payroll: Fees and Deductions rule update

PR #104911

Enterprise19.0l10n_au_hr_payroll

This update corrects a minor issue in the Australian Payroll module related to the calculation of union and professional association fees. The change ensures these fees are accurately reflected in employee deductions, improving payroll accuracy and compliance. This fix addresses a technical detail impacting payroll reporting.

Original PR description

. Update `Union and professional association fees` code in computations of `Fees and Deductions` rule

task-5402666

#payroll#australia#fees#deductions

[FIX] l10n_es_reports: use correct report period for Modelo 390

PR #106788

Enterprise19.0l10n_es_reportsMEDIUM

This update corrects an issue where Modelo 390 reports for past years were generating empty BOE files. The fix ensures the report period is correctly identified, pulling accurate data for the specified year from the Spanish tax agency. This resolves a reporting discrepancy impacting tax compliance.

Original PR description

### Issue: When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0 ### Cause: In `export_boe()`, the `report_lines` were get based on the `section_report`…

### Issue:
When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0

### Cause:
In `export_boe()`, the `report_lines` were get based on the `section_report` options
However, `section_reports` do not store the date
or return periodicity of the selected report
As a result, using their options always fetched data for the current period instead of the specified year

### Note:
`_generate_mod_390_page2()` also had issues:
some lines were missing or incorrectly indexed

The mod 360 format, it strict in the structure with specific index so it may produce invalid documents

The latest documentation for mod 390:
https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx

### Steps to reproduce:
- Install `l10n_es_reports` and switch to ES Company
- Create an Invoice and a Bill (Any product, Price: 100.00, Tax: 21%, Invoice Date: 01/01/2025)
- Open Tax Return, switch to Mod 390, and set year to 2025
- You should see data in the 2 first sections
- Use the gear icon, and download the BOE
- Use the gear icon to download the BOE, fill the wizard (Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345), and generate the file Before the fix: all values in the BOE were 0 instead of matching the report

opw-5457374

Forward-Port-Of: odoo/enterprise#106676
Forward-Port-Of: odoo/enterprise#104928

#reporting#es#tax#mod390

[FIX] sale_subscription_timesheet: hide remaining hours on subscription tasks

PR #106807

Enterprise19.0sale_subscription_timesheet

This update simplifies the sales order interface for subscription customers. We’ve hidden a confusing field that inaccurately reflected remaining service hours due to the recurring nature of subscriptions. This change ensures a cleaner, more intuitive experience for our customers and avoids potential misinterpretations.

Original PR description

This change hides the `remaining_hours_so` field when the sales order line is linked to a subscription. Unlike standard service or time-based sales orders, where this field reflects the difference between the quantity ordered and the quantity delivered, the concept does not translate well to subscription logic.

In the context of a subscription, the service is delivered on a recurring period (monthly, yearly, etc.). Delivery quantities continuously accumulate over time, and because the subscription renews indefinitely until cancellation, the “remaining hours” calculation quickly becomes misleading. In many cases it can drift into negative values, giving the impression of an error or over-consumption when, in reality, the subscription is simply following its recurring delivery cycle.

To avoid confusing end-users and to maintain a clean, intuitive interface, we hide this field whenever the line is part of a subscription.

opw-5246238

Forward-Port-Of: odoo/enterprise#99813

#subscriptions#reporting#UI

[FIX] account_accountant: fixes sepa installation

PR #106033

Enterprise19.0account_accountantMEDIUM

This update resolves a bug preventing users from installing modules after setting up a Belgian company with the account_accountant module. The issue stemmed from a registry reload delay during module installation, now corrected to ensure proper module installation.

Original PR description

Encountered this bug while trying to reproduce a bug from one of my ticket.

**STEP TO REPRODUCE**
On a fresh db with module account_accountant.
1. Create a new company with country set to Belgium. After l10n_modules are install, and the chart template loaded:
2. Try installing a module, and notice you can't.

**CAUSE**
button_install() doesn't reload the registry, so the sepa modules states are set to `to install` but are not install until the registry is reloaded, which doesn't happen on its own.
button_immediate_install() does the same as button_install(), and reload the registry which trigger the actual installation process.

Indirectly related to opw-5880247: when trying to reproduce the bug, I had to create a company, setup a chart of account on it. I created a belgium company -> setting it to belgium trigger the button_install, preventing me from installing payment module afterward.

#installation#SEPA#Belgium

[FIX] pos_iot_six: fix undefined user id

PR #106778

Enterprise19.0pos_iot_six

This update resolves a technical issue where the user ID was sometimes missing for payments processed through the POS IoT Six module. The fix restores a previous version that correctly identified the user, ensuring accurate payment tracking and reporting. This improves the reliability of the POS IoT Six payment process.

Original PR description

This PR reinstates https://github.com/odoo/enterprise/pull/98021 broken by https://github.com/odoo/enterprise/pull/98203

This fixes user id being undefined for pos_iot_six payments

Forward-Port-Of: odoo/enterprise#106737

#pos#iot#payments

[FIX] account_avatax: Restrict itemCode length for AvaTax API compatibility

PR #106656

Enterprise19.0account_avataxMEDIUM

This update resolves a problem where long item codes were causing errors in the AvaTax integration. The system now automatically limits item codes to 50 characters, ensuring successful tax calculations and preventing transaction failures. This improves the reliability of our tax processing.

Original PR description

Link to Avalara (Avatax) documentation: https://developer.avalara.com/api-reference/avatax/rest/v2/models/LineItemModel/ Expected Behaviour: The itemCode sent to the AvaTax API should be 50…

Link to Avalara (Avatax) documentation:
https://developer.avalara.com/api-reference/avatax/rest/v2/models/LineItemModel/

Expected Behaviour:
The itemCode sent to the AvaTax API should be 50 characters or fewer
to comply with Avalara's field length constraints.

Actual Behaviour before the Fix:
When an itemCode exceeded 50 characters, the system attempted to send
the request as-is. This resulted in the AvaTax API returning an error,
causing the transaction or tax calculation to fail.

Behaviour with the Fix:
The system now ensures that the itemCode adheres to the 50-character
limit before the API call is made, by trancating the code to the
first 50 characters if it exceeds 50 characters. This prevents API
rejection and ensures successful tax processing for items with
long identifiers.

Steps to reproduce:
1. Create or select a product/item with a reference (or barcode if
   using UPC) longer than 50 characters.
2. Trigger an action that calculates tax via the AvaTax
   integration (e.g., creating an invoice or updating a line item).
3. Observe the API response.

- Before fix: API returns a validation error regarding the
  itemCode length.
- After fix: Request is successful as the itemCode is
  properly handled/validated.

opw-5406451

Forward-Port-Of: odoo/enterprise#106085
Forward-Port-Of: odoo/enterprise#105017

#avatax#tax#item code#integration

[FIX] documents_hr_expense: prevent error while creating expense from document

PR #106843

Enterprise19.0documents_hr_expense

This update resolves an error that prevented non-employee users from creating expenses linked to uploaded documents. The issue stemmed from a required field ('employee_id') being unintentionally set to null. The fix now displays a user-friendly error message instead of crashing, ensuring a smoother experience for all users.

Original PR description

Currently an exception is generated when the non-employee user tries
to generate expenses from the documents.

Steps to produce an error:
- Install the `documents_hr_expense` module without demo data
- Delete employee `Administrator`
- Upload any PDF/image file inside the company's `Internal` folder
- Click on the uploaded document and click on the `Create an Expense` button

Error: `ValueError: NotNullViolation('null value in column "employee_id" of ...`

This error occurs because `employee_id` is required when creating an
expense. Since the current user is not linked to an employee record,
`employee_id is` set to false, which causes the issue.

This commit resolves the issue by raising a `UserError` when the current
user is not linked to an employee.

sentry-7192984733

Forward-Port-Of: odoo/enterprise#106649
Forward-Port-Of: odoo/enterprise#104762

#expense#user experience#non-employee

Steps to reproduce: -------------------------------- 1. Install `industry_fsm_sale` module 2. Go to Settings > Configure Document Layout 3. Select the Bubble document layout and save 4. Open any Field Service task 5. Use the Products smart button to add one or more products 6. Click the Settings icon > Print > Field Service Report Observation: -------------------------------- In Time & Material tables using the Bubble layout, table borders show a mix of rounded corners and sharp edges, resulting in inconsistent visuals Issue: -------------------------------- The table tags in the report were missing the `table-borderless` class. As a result, the layout-applied rounded borders conflicted with the default table borders Solution: -------------------------------- Add the `table-borderless` class to the affected table tags so the tables inherit consistent rounded borders from the document layout Before: <img width="787" height="317" alt="before_css" src="https://github.com/user-attachments/assets/dac136a8-022a-4c36-8cdb-1c0fbb048f3e" /> After: <img width="816" height="372" alt="after_css" src="https://github.com/user-attachments/assets/b5f96e75-2cd3-44cf-89e3-9a3b564c8369" /> opw-5401612 Forward-Port-Of: odoo/enterprise#105616

*= quality_control, quality_mrp_workorder, mrp_workorder Currently, when a user fails a quality check using the quick-action button, the failure message defined for that quality control point isn’t shown. **Steps to produce:** * Install `Quality` and `Manufacturing` with demo data * Go to MRP > Configuration > Operations > Manual Assembly * Create a pass/fail quality point with a failure message * Create and confirm an MO for `Table Top` * Go to Shop Floor > Activate work centers if inactive > Manual Assembly * Fail the assembly using the quick-action button Replication video: [Link](https://drive.google.com/file/d/1gBHrvQEAavhjU4lS-bKQHQjAa9qDHj6-/view?usp=sharing) **Observed Behavior:** * No failure message is displayed when the quality check is failed. **Root cause:** * This happens because pressing the quick-action button triggers `failCheck` [1] , which calls `doActionNext` [2], which then runs the server function `action_fail_and_next` [3]. That function sets `quality_state = fail` and calls [4] to get the view. But since [3] wraps that view inside a dictionary, the check in [5] never passes, so the message never appears. **Solution:** * Pass the view correctly to display the failure message. Since the quick action already marks the quality state as failed we can hide the Confirm and Back buttons by passing the context and checking it in the view to show a single OK button, similar to earlier versions. **Before:** <img width="1673" height="813" alt="image" src="https://github.com/user-attachments/assets/029e347b-5f2c-463a-833e-3b55677137b6" /> **After:** <img width="1687" height="829" alt="image" src="https://github.com/user-attachments/assets/e4c85093-ea0d-44ca-bc9c-0fab5ac08fbc" /> [1]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/static/src/mrp_display/quality_check.js#L83-L86 [2]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/mrp_workorder/static/src/mrp_display/mrp_record_line/quality_check.js#L147-L163 [3]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/models/quality.py#L86-L89 [4]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/models/quality.py#L48-L68 [5]: https://github.com/odoo/enterprise/blob/19.0/mrp_workorder/static/src/mrp_display/mrp_record_line/quality_check.js#L154-L161 opw-5403465 Forward-Port-Of: odoo/enterprise#102095

This error occurs when attempting to create an attendance for an employee who has no `Working Hours` defined. Steps to reproduce: - Install `hr_work_entry_attendance` module - Employees > `Administrator` > Settings > Set `Default Ruleset` in Overtime Ruleset > Payroll > Set Contract and `Work Entry Source` is in `Attendance` - Attendance > Create New Attendance(with Extra Hours) and Save - Remove `Working Hours` of employee Traceback: `KeyError: 52` We encounter this error at [1] because `lunch_by_resource` is empty "**{}**", and we attempt to access a key in this empty dictionary. [1]- https://github.com/odoo/enterprise/blob/b94ae7a4f8ae91ad98977a439db41a6939a6b617/hr_work_entry_attendance/models/hr_version.py#L80 sentry-7168309352

Currently journal items shown don't belong to the account group that they should belong to, and from saas-18.3 an error will be generated after following the below steps or step mentioned in ref PR [1]. - Install `Accounting (accountant)` with demo data - Create account groups e.g., name as `Test 1` and code prefix `1 to 1` - Go to the general ledger report - Click on `Journal Items` of the account group line `1 Test 1` Error from saas-18.3: `ValueError: Cannot convert account.account.group_id to SQL because it is ...` This error occurs because PR with ref [1] in 17.0 added the` group_id` field of the `account.account` model to the search domain. However, in 18.0, commit [2] modified this field so that it is no longer stored. As a result, when a search domain includes this `non-stored` field, Odoo skips the domain evaluation and logs a error at code line [3]. Consequently, the changes introduced by commit [1] have no functional effect from 18.0. Also, starting from saas-18.3, passing such a non-stored field in a domain raises an explicit error at code line [4], instead of being silently ignored. This commit resolves the issue by introducing an SQL query that returns the account ids related to `record_id(account group id)` include `record_id` as `None`. [1]: https://github.com/odoo/enterprise/pull/100191 [2]: https://github.com/odoo/odoo/commit/854c3b27aa5476c208572f19e64f8f3364bfc381#diff-19ef5a530c506fdee93fe0d113e61946b87fae7dd2d360558da69c0014f766b2R114-R767 [3]: https://github.com/odoo/odoo/blob/71e86f38c7699aaea980c929c67835a3495edf55/odoo/osv/expression.py#L1166-L1174 [4]: https://github.com/odoo/odoo/blob/00517e9e085c6fa9e00bedb8aee122a60e407fea/odoo/orm/fields.py#L1201 sentry-7100657414 Forward-Port-Of: odoo/enterprise#103137

### Steps to reproduce: - In Accounting, make sure you have the accountant model. Then, from Review > Audit > Working Files, click Balances. - Select more than 1 account lines and try to change their statuses. - If you don't have an Audit, create a new one and go back to Working files, then click balances. ### Cause: The client gets a traceback when they try to change the statuses of the audits for the accounts in bulks. opw-5474248

# Steps to reproduce: * Install **Accounting** and **l10n_be_reports**. * Enable **debug mode**. * Go to **Accounting → Reporting → Belgium → Partner VAT Listing**. * Create invoices with invoice lines with no product set on it, just a label, so that **more than 10 Belgian partners** appear in the report and ensure each partner has a **VAT number**. * Open the report **Options** tab and set **Load More Limit** to **5**. * Click **Load More** until all partners are visible. * Click **Returns** and create a return for the month you have created invoices for, and submit it. * Download the generated XML. # Observed behavior: * The XML file contains only the first batch of partners. * Partners shown after clicking **Load More** are missing from the export. # Cause: * In v17, the XML export button was defined as: https://github.com/odoo/enterprise/blob/42ef1fe589fc4e7fe4b611736253251c44506578/l10n_be_reports/models/partner_vat_listing.py#L53-L59 * This meant clicking the button would go through the [export_file](https://github.com/odoo/enterprise/blob/42ef1fe589fc4e7fe4b611736253251c44506578/account_reports/models/account_report.py#L4927) method, which sets `options['export_mode'] = 'file'` before calling the export function. The test in v17 explicitly sets `export_mode = 'file'` to simulate what `export_file` does in production. * In v19, the architecture changed: - The XML export is now triggered via the account.return workflow and a submission wizard [1.](https://github.com/odoo/enterprise/blob/19.0/l10n_be_reports/wizard/vat_listing_submission_wizard.py) - The wizard's `print_xml` method calls [_get_closing_report_options()](https://github.com/odoo/enterprise/blob/19.0/account_reports/models/account_return.py#L1601) which does NOT set `export_mode = 'file'`. - The controller then calls `dispatch_report_action(options, file_generator)` directly, bypassing `export_file`. * Why the test changed: - In v17 test: `export_mode = 'file'` was set to mimic the `export_file` → `partner_vat_listing_export_to_xml` flow. - In v19 test: `export_mode = 'file'` should NOT be needed in the test because the fix is to set `export_mode = 'file'` inside `partner_vat_listing_export_to_xml` itself. # Fix: * Enable **export mode** when generating the XML. * Ensures all partners are included regardless of the load limit. opw-5494247

### Issue: When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0 ### Cause: In `export_boe()`, the `report_lines` were get based on the `section_report` options However, `section_reports` do not store the date or return periodicity of the selected report As a result, using their options always fetched data for the current period instead of the specified year ### Note: `_generate_mod_390_page2()` also had issues: some lines were missing or incorrectly indexed The mod 360 format, it strict in the structure with specific index so it may produce invalid documents The latest documentation for mod 390: https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx ### Steps to reproduce: - Install `l10n_es_reports` and switch to ES Company - Create an Invoice and a Bill (Any product, Price: 100.00, Tax: 21%, Invoice Date: 01/01/2025) - Open Tax Return, switch to Mod 390, and set year to 2025 - You should see data in the 2 first sections - Use the gear icon, and download the BOE - Use the gear icon to download the BOE, fill the wizard (Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345), and generate the file Before the fix: all values in the BOE were 0 instead of matching the report opw-5457374 Forward-Port-Of: odoo/enterprise#106676 Forward-Port-Of: odoo/enterprise#104928

This change hides the `remaining_hours_so` field when the sales order line is linked to a subscription. Unlike standard service or time-based sales orders, where this field reflects the difference between the quantity ordered and the quantity delivered, the concept does not translate well to subscription logic. In the context of a subscription, the service is delivered on a recurring period (monthly, yearly, etc.). Delivery quantities continuously accumulate over time, and because the subscription renews indefinitely until cancellation, the “remaining hours” calculation quickly becomes misleading. In many cases it can drift into negative values, giving the impression of an error or over-consumption when, in reality, the subscription is simply following its recurring delivery cycle. To avoid confusing end-users and to maintain a clean, intuitive interface, we hide this field whenever the line is part of a subscription. opw-5246238 Forward-Port-Of: odoo/enterprise#99813

Encountered this bug while trying to reproduce a bug from one of my ticket. **STEP TO REPRODUCE** On a fresh db with module account_accountant. 1. Create a new company with country set to Belgium. After l10n_modules are install, and the chart template loaded: 2. Try installing a module, and notice you can't. **CAUSE** button_install() doesn't reload the registry, so the sepa modules states are set to `to install` but are not install until the registry is reloaded, which doesn't happen on its own. button_immediate_install() does the same as button_install(), and reload the registry which trigger the actual installation process. Indirectly related to opw-5880247: when trying to reproduce the bug, I had to create a company, setup a chart of account on it. I created a belgium company -> setting it to belgium trigger the button_install, preventing me from installing payment module afterward.

This PR reinstates https://github.com/odoo/enterprise/pull/98021 broken by https://github.com/odoo/enterprise/pull/98203 This fixes user id being undefined for pos_iot_six payments Forward-Port-Of: odoo/enterprise#106737

Link to Avalara (Avatax) documentation: https://developer.avalara.com/api-reference/avatax/rest/v2/models/LineItemModel/ Expected Behaviour: The itemCode sent to the AvaTax API should be 50 characters or fewer to comply with Avalara's field length constraints. Actual Behaviour before the Fix: When an itemCode exceeded 50 characters, the system attempted to send the request as-is. This resulted in the AvaTax API returning an error, causing the transaction or tax calculation to fail. Behaviour with the Fix: The system now ensures that the itemCode adheres to the 50-character limit before the API call is made, by trancating the code to the first 50 characters if it exceeds 50 characters. This prevents API rejection and ensures successful tax processing for items with long identifiers. Steps to reproduce: 1. Create or select a product/item with a reference (or barcode if using UPC) longer than 50 characters. 2. Trigger an action that calculates tax via the AvaTax integration (e.g., creating an invoice or updating a line item). 3. Observe the API response. - Before fix: API returns a validation error regarding the itemCode length. - After fix: Request is successful as the itemCode is properly handled/validated. opw-5406451 Forward-Port-Of: odoo/enterprise#106085 Forward-Port-Of: odoo/enterprise#105017

Currently an exception is generated when the non-employee user tries to generate expenses from the documents. Steps to produce an error: - Install the `documents_hr_expense` module without demo data - Delete employee `Administrator` - Upload any PDF/image file inside the company's `Internal` folder - Click on the uploaded document and click on the `Create an Expense` button Error: `ValueError: NotNullViolation('null value in column "employee_id" of ...` This error occurs because `employee_id` is required when creating an expense. Since the current user is not linked to an employee record, `employee_id is` set to false, which causes the issue. This commit resolves the issue by raising a `UserError` when the current user is not linked to an employee. sentry-7192984733 Forward-Port-Of: odoo/enterprise#106649 Forward-Port-Of: odoo/enterprise#104762