Odoo Changelog — 2026-04-08

Wednesday, April 8, 2026

6 changes · 17.0

Improvements(1)

Enhancements to existing features

[IMP] account_edi_ubl_cii: Add tax exemption reason and code to co-co…

Core17.0account_edi_ubl_ciiMEDIUM

This update ensures Odoo complies with Belgian regulations requiring specific invoice details when using the 'Co-Contractant' tax scheme. It adds a mandatory field for tax exemption reasons and codes, improving invoice accuracy and reducing potential compliance issues. This change supports proper tax reporting for businesses operating in Belgium.

Original PR description

It is mandatory in BE to add a legal note on the invoice when using a "Co-Contractant" tax
task-5905176

#tax#Belgium#UBL#Co-Contractant

Bug Fixes(5)

Resolved issues and error corrections

[FIX] account_{sepa,batch_paymet}: fix bill reference for SEPA export

PR #110809

Enterprise17.0account_batch_paymentaccount_sepaMEDIUM

This update corrects a problem where '&' characters in vendor bill references were causing errors during SEPA payment file generation. The fix replaces '&' with '+' to ensure compliance with SEPA/SIX specifications, preventing payment rejection by banks. This ensures accurate and compliant SEPA payment processing.

Original PR description

Steps to reproduce:
1. Install modules `account_batch_payment` and `l10n_ch`.
2. Configure SEPA Credit Transfer for a CH company.
3. Create a vendor bill with a reference containing `&` (e.g. "Net & Cost"), confirm it and register a payment using SEPA Credit Transfer.
4. Create a batch payment with the SEPA payment and validate it.

Issue:
The `&` character is exported as `&amp` in the generated PAIN XML,
while according to the SIX specification it should be replaced with `+`

Cause:
The payment reference is inserted into the PAIN XML file without replacing the '&' character. During XML generation this produces an invalid entity (`&`) which results in an `XMLSyntaxError` and prevents the payment file from being processed.

Solution:
Replace the `&` character with `+` when sanitizing the payment communication so that the generated value complies with the SEPA/SIX character set and produces valid XML.

Reference[Pg: 9]: https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf

opw-5941724

Co-authored by @bhra-odoo

#SEPA#payments#SIX#compliance

[FIX] l10n_tr_nilvera_einvoice: fix method rename to match parent class

PR #258096

Core17.0l10n_tr_nilvera_einvoiceMEDIUM

This update corrects a bug preventing the correct setting of a unique identifier (UUID) for Nilvera electronic invoices during import. The method name in the Nilvera module was out of sync with a recent update to the core Odoo system. Merging this change ensures that Nilvera invoices are imported correctly and reliably.

Original PR description

# Description of the issue/feature this PR addresses
The parent class `account.edi.xml.ubl_20` renamed `_import_fill_invoice_form`
to `_import_fill_invoice`. The override in `l10n_tr_nilvera_einvoice` was not
updated to match, causing the override to be silently ignored.

# Current behavior before PR
The `_import_fill_invoice_form` override in `l10n_tr_nilvera_einvoice` is never
called because the parent method no longer exists under that name, so the Nilvera
UUID is not set on imported invoices.

# Desired behavior after PR is merged
The override is renamed to `_import_fill_invoice` to match the parent class,
restoring correct behaviour for Nilvera invoice imports.

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

#einvoice#tr#nilvera#uuid

[FIX] stock: auto-reserve outbound moves when stock arrives at child location

PR #258026

Core17.0stockMEDIUM

This update fixes a bug preventing automatic stock reservations when products arrive at child locations within the warehouse. The change ensures that outbound moves from any parent location are considered, allowing for correct inventory tracking after receiving stock. This improves order fulfillment accuracy and prevents stock discrepancies.

Original PR description

Steps to reproduce 1. Create a product with no stock 2. Confirm a delivery order sourced from WH/Stock 3. Receive the product via a purchase order into WH/Stock/Shelf 1 (a child of WH/Stock) 4.…

Steps to reproduce
1. Create a product with no stock
2. Confirm a delivery order sourced from WH/Stock
3. Receive the product via a purchase order into WH/Stock/Shelf 1 (a child of WH/Stock)
4. Observe that the delivery is not automatically reserved

Issue
_trigger_assign builds a domain to find outbound moves to re-attempt reservation after a receipt is validated. The domain used an exact match ('location_id', '=', move.location_dest_id.id), so only moves whose source location was identical to the receipt's destination were considered. A move sourced from WH/Stock was never found when stock arrived at a child like WH/Stock/Shelf 1, even though _action_assign already uses child_of internally to gather available quants from sub-locations.

Solution
Replace '=' with 'parent_of' so that when stock arrives at a child location, _trigger_assign also wakes up moves sourced from any ancestor of that location. The reservation attempt itself is already correct — _action_assign with strict=False searches child locations — so only the trigger was missing.

opw-6052753

#inventory#warehouse#stock management

[FIX] spreadsheet_dashboard_sale_timesheet: fix filter for KPI cards

PR #224810

Core17.0spreadsheet_dashboard_sale_timesheetMEDIUM

This update corrects a bug that prevented KPI cards (Billable Hours, etc.) from accurately reflecting data when global filters were applied. The issue stemmed from a hardcoded filter limiting data to a single user, causing incorrect results with other filters. This fix ensures KPI cards display correct data based on applied filters.

Original PR description

Steps to reproduce:
-
  1. Go to the dashboard app > Timesheets.
  2. Apply any global filter.

Issue:
-
The main KPI cards (Billable Hours, Non-billable Hours, Billable Rate) do not update correctly when any global filter is applied. Filtering by 'Employee' causes the cards to show zero. Other filters like 'Project' or 'Department' show incomplete and incorrect data, reflecting only the timesheets of a single hardcoded user.

Cause:
-
The pivot tables (`pivot 5` and `pivot 6`) that source the data for the KPI cards contained a hardcoded domain `['user_id', '=', 2]`. This condition changes any selection made in the global filter and shows incorrect data.

Fix:
-
The hardcoded `['user_id', '=', 2]` condition has been removed.

task-4782213

#dashboard#timesheet#KPI#reporting

[FIX] sale_timesheet, _*: fix duplicate Sale Order creation on the fly

PR #203230

Core17.0sale_projectsale_timesheetMEDIUM

This update fixes a bug where creating a new sale order line would inadvertently generate a duplicate Sale Order. The fix ensures existing Sale Orders are reused when new lines are added, streamlining the order creation process and preventing unnecessary order duplication. This improves data accuracy and efficiency.

Original PR description

_*= sale_project
**Issue:**
When a new sale order line is created on the fly, a new Sale Order is being created instead of reusing an existing one.

**Root Cause:** 
This happens when the project_sale_order is not being passed correctly in the context, causing a new Sale Order to be created.

**Fix:**
Explicitly pass the default_order_id in the context. If an existing Sale Order is found, it will be reused instead of creating a new one.

**Technical Details:**
Updated the `default_order_id` to use sale_order_id instead of `project_sale_order_id` in `sale_project`. This ensures that the field functions correctly even when `project_sale_order_id` is empty.

**task-4276677**


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

#sale#order#timesheet#duplicate

Steps to reproduce: 1. Install modules `account_batch_payment` and `l10n_ch`. 2. Configure SEPA Credit Transfer for a CH company. 3. Create a vendor bill with a reference containing `&` (e.g. "Net & Cost"), confirm it and register a payment using SEPA Credit Transfer. 4. Create a batch payment with the SEPA payment and validate it. Issue: The `&` character is exported as `&amp` in the generated PAIN XML, while according to the SIX specification it should be replaced with `+` Cause: The payment reference is inserted into the PAIN XML file without replacing the '&' character. During XML generation this produces an invalid entity (`&`) which results in an `XMLSyntaxError` and prevents the payment file from being processed. Solution: Replace the `&` character with `+` when sanitizing the payment communication so that the generated value complies with the SEPA/SIX character set and produces valid XML. Reference[Pg: 9]: https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf opw-5941724 Co-authored by @bhra-odoo

# Description of the issue/feature this PR addresses The parent class `account.edi.xml.ubl_20` renamed `_import_fill_invoice_form` to `_import_fill_invoice`. The override in `l10n_tr_nilvera_einvoice` was not updated to match, causing the override to be silently ignored. # Current behavior before PR The `_import_fill_invoice_form` override in `l10n_tr_nilvera_einvoice` is never called because the parent method no longer exists under that name, so the Nilvera UUID is not set on imported invoices. # Desired behavior after PR is merged The override is renamed to `_import_fill_invoice` to match the parent class, restoring correct behaviour for Nilvera invoice imports. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Steps to reproduce 1. Create a product with no stock 2. Confirm a delivery order sourced from WH/Stock 3. Receive the product via a purchase order into WH/Stock/Shelf 1 (a child of WH/Stock) 4. Observe that the delivery is not automatically reserved Issue _trigger_assign builds a domain to find outbound moves to re-attempt reservation after a receipt is validated. The domain used an exact match ('location_id', '=', move.location_dest_id.id), so only moves whose source location was identical to the receipt's destination were considered. A move sourced from WH/Stock was never found when stock arrived at a child like WH/Stock/Shelf 1, even though _action_assign already uses child_of internally to gather available quants from sub-locations. Solution Replace '=' with 'parent_of' so that when stock arrives at a child location, _trigger_assign also wakes up moves sourced from any ancestor of that location. The reservation attempt itself is already correct — _action_assign with strict=False searches child locations — so only the trigger was missing. opw-6052753

Steps to reproduce: - 1. Go to the dashboard app > Timesheets. 2. Apply any global filter. Issue: - The main KPI cards (Billable Hours, Non-billable Hours, Billable Rate) do not update correctly when any global filter is applied. Filtering by 'Employee' causes the cards to show zero. Other filters like 'Project' or 'Department' show incomplete and incorrect data, reflecting only the timesheets of a single hardcoded user. Cause: - The pivot tables (`pivot 5` and `pivot 6`) that source the data for the KPI cards contained a hardcoded domain `['user_id', '=', 2]`. This condition changes any selection made in the global filter and shows incorrect data. Fix: - The hardcoded `['user_id', '=', 2]` condition has been removed. task-4782213

_*= sale_project **Issue:** When a new sale order line is created on the fly, a new Sale Order is being created instead of reusing an existing one. **Root Cause:** This happens when the project_sale_order is not being passed correctly in the context, causing a new Sale Order to be created. **Fix:** Explicitly pass the default_order_id in the context. If an existing Sale Order is found, it will be reused instead of creating a new one. **Technical Details:** Updated the `default_order_id` to use sale_order_id instead of `project_sale_order_id` in `sale_project`. This ensures that the field functions correctly even when `project_sale_order_id` is empty. **task-4276677** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr