Odoo Changelog — 2026-04-17

Friday, April 17, 2026

5 changes · saas-18.2

Bug Fixes(5)

Resolved issues and error corrections

[FIX] appointment_google_calendar: prevent error while saving appointment

Enterprisesaas-18.2appointment_google_calendar

This update fixes a bug that prevented users from saving appointments when removing the organizer. The issue stemmed from a template rendering error triggered by a missing user ID. This change ensures appointments can be saved correctly, improving appointment scheduling functionality.

Original PR description

Currently an error is generated when the user tries to save an
appointment as follows:
- Install the appointment_google_calendar module without demo data
- Create a new appointment as below:
      - Remove Organizer (user_id)
      - Set the Google Meet link inside VideocallURL, e.g., https://meet.google.com/aaa-aaa-aaa
- An error occurs in the log and a message is shown to the user when save the record
- Also, an error occurs when trying to preview `Appointment: Attendee Invitation`
  after creating appointment as follows:
      - Set the Google Meet link inside Videocall URL > save
      - Remove Organizer (user_id)

Error: 
```
test odoo.addons.mail.models.mail_render_mixin: Failed to render QWeb template for Mail Template: 'Appointment: Appointment Booked' (ID: 12) - Context language:en_US
Target Model: calendar.event
Error: Error while render the template
ValueError: Expected singleton: res.users()
```


This is because the method `is_google_calendar_synced` expected a single
record, but since we removed `user_id` from the event (appointment),
it will generate a singleton error.

This commit will fix the above issue by not calling `is_google_calendar_synced`
when the event does not have `user_id`.

sentry-7393595716

Forward-Port-Of: odoo/enterprise#113966

#appointments#google calendar#bug fix

[FIX] l10n_be_hr_payroll: remove tracking on non-stored holiday pay f…

PR #114063

Enterprisesaas-18.2l10n_be_hr_payroll

This update resolves a test failure caused by an unnecessary calculation of a holiday pay field. The fix removes tracking from the field, ensuring it's only computed when needed, preventing early computations and restoring accurate test results. This improves the stability of the Belgian payroll module.

Original PR description

…ield

The computed, non-stored field `l10n_be_holiday_pay_recovered_n1` had tracking enabled. When writing to any field on the employee, the `write` method calls `_track_prepare` for tracked fields if `mail_notrack` is not set in the context. `_track_prepare` reads the current value of tracked fields to store initial values. Because `l10n_be_holiday_pay_recovered_n1` is non-stored with no dependencies, this triggered a computation at the very beginning of the test, before payslips existed. Later, when payslips were created, the field was never recomputed, causing incorrect values and test failures.

Previously, the `tracking_disable` context prevented early computation.

The fix removes the tracking attribute entirely, so the field is only computed when accessed, avoiding premature reads and fixing the tests.

task: 6095445

Forward-Port-Of: odoo/enterprise#113015

#payroll#holiday pay#Belgium

[FIX] account_reports: prevent line breaks on negative numbers

PR #113943

Enterprisesaas-18.2account

This update resolves an issue where negative numbers in accounting reports (like customer statements) were incorrectly split across lines, making them difficult to read. The fix ensures that negative numbers are displayed as a single line, maintaining proper formatting and clarity in printed reports. This improves the user experience and accuracy of financial statements.

Original PR description

When printing accounting reports such as customer statements, a negative number may be split across two lines, leaving the minus sign on the first line and the amount on the second.

Steps to reproduce:
- Make an invoice for [Partner] with a total of 10.0
- Make another invoice for [Partner] with a total of 100.0
- Create a credit note for this last invoice
- Open the customer statement report for [Partner]
- Print PDF

Issue: The first line of the partner section has fewer digits than the amounts of the subsequent journal items. On pdf, the column width is based on the smaller line, causing the longer negative strings to wrap and separate the minus sign from the amount.

opw-5951300

Forward-Port-Of: odoo/enterprise#113727

#reporting#accounting#PDF#formatting

[FIX] account_iso20022: no decimal for some currencies

PR #114102

Enterprisesaas-18.2accountMEDIUM

This update resolves an issue where ISO20022 payments using JPY were failing due to a hardcoded decimal format in the payment file. The fix dynamically adjusts the decimal places based on the currency, ensuring compatibility with banks and accurate payment processing. This prevents payment rejections and improves JPY payment functionality.

Original PR description

Steps to reproduce:
-------------------
1. Activate JPY and create a JPY bank journal with ISO20022 as an
   outgoing payment method
2. Create a vendor (with a country) and add a trusted bank account
3. Create and confirm a vendor bill in JPY (e.g. ¥1000), and pay it
   using the ISO20022 method on the JPY journal
4. Create a batch payment containing that payment, with Batch Type
   Outbound, on the JPY journal, with ISO20022 as payment method
5. Validate the batch — the XML file is generated and attached
6. Download it

-> The `<InstdAmt Ccy="JPY">` node outputs `1000.00`, while JPY has
no decimals. The file is rejected by banks.

The fix:
--------

Backport of 8da91d94ed1e8fad0e827f96172e3785e9f0e28d:

> Generating the xml file for iso20022 always generates the amount with
two decimals which is hard coded and can cause error for currencies without decimals for example JPY.
> The fix is to have the currency decimal number dynamically set through
the currency decimal places field.

opw-6103849

Forward-Port-Of: odoo/enterprise#113296

#iso20022#payment#currency#japan

[FIX] stock_barcode_product_expiry: accept due date on packagings

PR #113136

Enterprisesaas-18.2stockMEDIUM

This update ensures that when scanning a GS1 barcode on a packaging unit, the system correctly incorporates the packaging's expiration date when creating a new lot. Previously, the system overlooked this information, leading to inaccurate expiry tracking for packaged goods. This improvement enhances inventory management and compliance.

Original PR description

Issue
-----
Scanning a GS1 barcode containing:
- packaging
- lot
- due date

disregards the due date when creating the new lot.

Steps to reproduce
-----
- Enable GS1 nomenclature & packagings
- Create a product
    - barcode 23456789012344
    - packaging with barcode 01234567890128
    - some on hand quantity
- Create a delivery for a full packaging of the product
- Open the delivery in barcode
- Scan 02 01234567890128 15 270101 10 LOT1
- Validate
- Open the lot

> Expiration date is set to today

Cause
-----
The code expects the product be scanned, there is no logic to retrieve it from the packaging when missing.

-----
Ticket:
opw-6073489

Forward-Port-Of: odoo/enterprise#112490

#inventory#expiry#barcode#packaging

Currently an error is generated when the user tries to save an appointment as follows: - Install the appointment_google_calendar module without demo data - Create a new appointment as below: - Remove Organizer (user_id) - Set the Google Meet link inside VideocallURL, e.g., https://meet.google.com/aaa-aaa-aaa - An error occurs in the log and a message is shown to the user when save the record - Also, an error occurs when trying to preview `Appointment: Attendee Invitation` after creating appointment as follows: - Set the Google Meet link inside Videocall URL > save - Remove Organizer (user_id) Error: ``` test odoo.addons.mail.models.mail_render_mixin: Failed to render QWeb template for Mail Template: 'Appointment: Appointment Booked' (ID: 12) - Context language:en_US Target Model: calendar.event Error: Error while render the template ValueError: Expected singleton: res.users() ``` This is because the method `is_google_calendar_synced` expected a single record, but since we removed `user_id` from the event (appointment), it will generate a singleton error. This commit will fix the above issue by not calling `is_google_calendar_synced` when the event does not have `user_id`. sentry-7393595716 Forward-Port-Of: odoo/enterprise#113966

…ield The computed, non-stored field `l10n_be_holiday_pay_recovered_n1` had tracking enabled. When writing to any field on the employee, the `write` method calls `_track_prepare` for tracked fields if `mail_notrack` is not set in the context. `_track_prepare` reads the current value of tracked fields to store initial values. Because `l10n_be_holiday_pay_recovered_n1` is non-stored with no dependencies, this triggered a computation at the very beginning of the test, before payslips existed. Later, when payslips were created, the field was never recomputed, causing incorrect values and test failures. Previously, the `tracking_disable` context prevented early computation. The fix removes the tracking attribute entirely, so the field is only computed when accessed, avoiding premature reads and fixing the tests. task: 6095445 Forward-Port-Of: odoo/enterprise#113015

When printing accounting reports such as customer statements, a negative number may be split across two lines, leaving the minus sign on the first line and the amount on the second. Steps to reproduce: - Make an invoice for [Partner] with a total of 10.0 - Make another invoice for [Partner] with a total of 100.0 - Create a credit note for this last invoice - Open the customer statement report for [Partner] - Print PDF Issue: The first line of the partner section has fewer digits than the amounts of the subsequent journal items. On pdf, the column width is based on the smaller line, causing the longer negative strings to wrap and separate the minus sign from the amount. opw-5951300 Forward-Port-Of: odoo/enterprise#113727

Steps to reproduce: ------------------- 1. Activate JPY and create a JPY bank journal with ISO20022 as an outgoing payment method 2. Create a vendor (with a country) and add a trusted bank account 3. Create and confirm a vendor bill in JPY (e.g. ¥1000), and pay it using the ISO20022 method on the JPY journal 4. Create a batch payment containing that payment, with Batch Type Outbound, on the JPY journal, with ISO20022 as payment method 5. Validate the batch — the XML file is generated and attached 6. Download it -> The `<InstdAmt Ccy="JPY">` node outputs `1000.00`, while JPY has no decimals. The file is rejected by banks. The fix: -------- Backport of 8da91d94ed1e8fad0e827f96172e3785e9f0e28d: > Generating the xml file for iso20022 always generates the amount with two decimals which is hard coded and can cause error for currencies without decimals for example JPY. > The fix is to have the currency decimal number dynamically set through the currency decimal places field. opw-6103849 Forward-Port-Of: odoo/enterprise#113296

Issue ----- Scanning a GS1 barcode containing: - packaging - lot - due date disregards the due date when creating the new lot. Steps to reproduce ----- - Enable GS1 nomenclature & packagings - Create a product - barcode 23456789012344 - packaging with barcode 01234567890128 - some on hand quantity - Create a delivery for a full packaging of the product - Open the delivery in barcode - Scan 02 01234567890128 15 270101 10 LOT1 - Validate - Open the lot > Expiration date is set to today Cause ----- The code expects the product be scanned, there is no logic to retrieve it from the packaging when missing. ----- Ticket: opw-6073489 Forward-Port-Of: odoo/enterprise#112490