Odoo Changelog — 2026-04-28

Tuesday, April 28, 2026

9 changes · saas-18.4

Bug Fixes(9)

Resolved issues and error corrections

[FIX] html_builder, *: add missing conversions for em, px, % units

Coresaas-18.4html_builderhtml_editorMedium

This fix prevents errors when editing size-related options in the website builder that use em, px, or percentage units. It improves reliability for users customizing page layouts and styling, especially when values are converted between different measurement units.

Original PR description

[*] = html_editor

### Issue 1: Traceback "cannot convert m to em"

Steps to reproduce:

1. Create an option with "BuilderNumberInput" and set the unit to "em".
2. Open the builder and try changing the option value.

Reason for traceback:
The regex used to separate the value and unit incorrectly allows "e" in the numeric part. As a result, a value like "12em" is parsed as "value = 12e" and "unit = m". The "e" in regex was meant to allow scientific notation (e.g. "1e3"), but it also matches the "e" in unit.

---

### Issue 2: Traceback "Error: Cannot convert 'px' units into 'em' units !"

Steps to reproduce:

1. Create an option with a "BuilderNumberInput" with unit "px" and saveUnit set to "em".
2. Open the builder and try changing the option value.

Reason for traceback:
No conversion was defined for "px <-> em" in the "CSS_UNITS_CONVERSION" object, which is responsible for converting values when unit and saveUnit differ. The same issue exists for "% <-> em".

---

task-6048918

#website builder#styling#unit conversion

[FIX] hr: clear bank account on employee duplication

PR #261484

Coresaas-18.4hrMedium

Duplicating an employee now leaves the bank account field empty instead of reusing the original employee’s account. This prevents payroll mistakes where two employee records could point to the same bank account and salary payments could be sent incorrectly.

Original PR description

Steps:
- Duplicate an employee.
- Check that the bank account is copied.
- Modify the bank account on the duplicated employee.
- Verify the original employee’s bank account.

Issue:
- When duplicating an employee, the bank account was copied as well, causing both employees to use the same account. Updating it for one also changed it for the other, leading to both salaries being paid to the same account.

Fix:
- Set the 'bank_account_id' field to not be copied during duplication, ensuring the field is cleared for the duplicated employee.

task-6093406

Forward-Port-Of: odoo/odoo#259405

#employees#payroll#bank-account#duplication

[FIX] sale_timesheet: don't invoice non-validated timesheets

PR #261593

Coresaas-18.4sale_timesheetMedium

Invoices for timesheet-based services now correctly exclude timesheets that have not been validated when the setting requires validation. This prevents customers from being billed for unapproved work and keeps invoice quantities aligned with business policy.

Original PR description

**Steps to reproduce**
- Settings: Timesheets > Invoicing policy = only validated TS.
- Have a service product with an invoicing policy based on timesheets.
- Create a sales order using this product.
- From the SO, click on the "Recorded" smart button and create 2 timesheets. Validate only one of them.
- Invoice the SO, using a timesheets period that includes both TS.
- Notice that the quantity of the invoice line includes the non-validated timesheet.

**Cause**
The domain excluding non-validated timesheets provided by `_timesheet_compute_delivered_quantity_domain` is not considered since c3b6053b09222d4bd2237e7de589a63fbef118f1

**Change**
Since the purpose of the previous fix was to exclude timesheets linked to an invoice with a date before the "Invoicing Switch Threshold", this can be achieved by tweaking the `timesheet_domain` slightly, similar to the `_timesheet_domain_get_invoiced_lines` domain.

opw-6116670

Forward-Port-Of: odoo/odoo#261077
Forward-Port-Of: odoo/odoo#259224

[FIX] account: fixes discount allocations with foreign currencies

PR #261462

Coresaas-18.4accountMedium

Invoices created from sales orders with line discounts in a foreign currency now balance correctly. This prevents invoice creation from failing when discounts are allocated across products using different income accounts.

Original PR description

**STEP TO REPRODUCE**
1. Install the sale and accounting module.
2. Create 2 products, and setup each one with a different income account.
3. From the accounting settings, setup an account for Invoice Line discount -> Customer Invoice account.
4. Enable a currency, and create a pricelist for this currency.
5. Create the following SO: pricelist -> the pricelist you created previously. currency rate : 0.000717398539
line a: product_a, price 10, discount 57.85%
line b: product_b, price 70, discount 57.85%
From this SO, try to create an invoice.
It will fail, saying the invoice it tried to create is unbalanced.

opw-5974048

Forward-Port-Of: odoo/odoo#257897

#invoicing#discounts#foreign-currency

[FIX] l10n_pl_edi_ksef: fix empty Email and Telefon tags in KSeF invoice XML

PR #260218

Coresaas-18.4l10n_pl_ediMedium

Polish electronic invoices sent to KSeF will now omit buyer email or phone fields when those details are not available. This prevents invoices from being rejected because of empty contact tags, reducing failed submissions for Polish companies.

Original PR description

Before this commit:
Steps
1. Create a Polish company
2. Create and send an invoice to KSeF where the buyer has no email or no phone number
3. KSeF rejects the invoice with error code 450 (semantic verification error) This happens because `Email` and `Telefon` elements are always rendered inside `DaneKontaktowe`, even when their values are empty, producing invalid empty tags.

After this commit:
Add `t-if="buyer.email"` and `t-if="buyer.phone"` guards on each field so that `Email` and `Telefon` are only rendered when a value is present.

opw-6124187

Forward-Port-Of: odoo/odoo#259646

#Poland#KSeF#electronic invoicing#invoice validation

[FIX] point_of_sale: use payment amounts for sale details total

PR #261671

Coresaas-18.4point_of_saleMedium

Point of Sale sales detail reports now use the actual payment amounts when calculating totals, so cash rounding is reflected correctly. This removes discrepancies between the displayed total and payment lines and adds a separate cash rounding line when rounding was applied.

Original PR description

The sale details report total_paid was computed from sum(order.amount_total), which does not include the cash rounding adjustment. This caused a discrepancy between the displayed total and the sum of individual payment lines when cash rounding is enabled.

Use the sum of actual payment amounts instead, which naturally includes cash rounding since payments are recorded with their rounded values.

opw-5253018

Forward-Port-Of: odoo/odoo#261315
Forward-Port-Of: odoo/odoo#254401

#point of sale#sales report#cash rounding#payments

[FIX] l10n_mx_edi: allow copy of invoice_origin in cancelled invoice

PR #115352

Enterprisesaas-18.4l10n_mx_ediMedium

This update ensures that the 'Source' (origin) field is correctly populated on replacement invoices generated through the cancel process in Mexico. Previously, this information was missing, hindering traceability. The fix explicitly copies the original invoice's information, maintaining accurate links and ensuring compliance.

Original PR description

### Issue before this commit:
The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field.

### Steps to reproduce the issue:
1. Download Sales and l10n_mx
2. Set a UNSPSC Category for one product
3. Go to Sales, create a new Quotation and confirm it
4. Create invoice, confirm and send & print
5. Request cancel button -> create replacement invoice
6. In the new invoice there is no source origin invoice

### Cause of the issue:
The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice.

### Reason to introduce the fix:
To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF.

opw-6070016

Forward-Port-Of: odoo/enterprise#114099

[FIX] l10n_in_reports_gstr: fix vendor invoice fetch cron for multi-company

PR #115312

Enterprisesaas-18.4accountMedium

This update resolves an issue where the automated reporting cron job for vendor invoices didn't correctly identify the target company in multi-company setups. The fix ensures invoices are fetched from the correct company, preventing errors and improving the reliability of the reporting process. This ensures accurate reporting across all company structures.

Original PR description

In a multi-company context, the cron might be run with a user having a default company that is not the same as the target moves companies, maybe raising a `RedirectionWarning` (if the current company is not fully set-up).

This commit ensure to fetch the invoice in move's target company.

opw-5225553

Forward-Port-Of: odoo/enterprise#115192
Forward-Port-Of: odoo/enterprise#113254

#reporting#multi-company#invoice

[FIX] stock_barcode_mrp: preserve qty, lock UoM

PR #115059

Enterprisesaas-18.4stockMedium

This update resolves two bugs impacting the Barcode app's handling of Manufacturing Orders. Previously, changing the UoM after confirmation or saving changes to the 'Produce Quantity' would be lost. This fix ensures that UoM changes are correctly applied and that entered production quantities are preserved, improving data consistency and workflow accuracy.

Original PR description

### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not…

### Issue
Two bugs reported in the Barcode app / Manufacturing Order flow:

**1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not.

**2. `qty_producing` reset on wizard open/close**
Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits.

### Fix
- `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend.
- `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload.

### Steps to reproduce
**UoM bug**
1. Create an MO, confirm it.
2. Open it in the Barcode app.
3. Try to change the UoM → it was editable (bug).

**Qty reset bug**
1. Open a confirmed MO in the Barcode app, go to the header product page.
2. Type a value in `qty_producing` (e.g. `3`).
3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity".
4. `qty_producing` reverts to its previous value (bug).

### After the fix
- UoM field is greyed out once the MO is confirmed.
- Typed value in `qty_producing` is preserved after opening and closing the wizard.

opw-5809178

Forward-Port-Of: odoo/enterprise#114452
Forward-Port-Of: odoo/enterprise#114075

[*] = html_editor ### Issue 1: Traceback "cannot convert m to em" Steps to reproduce: 1. Create an option with "BuilderNumberInput" and set the unit to "em". 2. Open the builder and try changing the option value. Reason for traceback: The regex used to separate the value and unit incorrectly allows "e" in the numeric part. As a result, a value like "12em" is parsed as "value = 12e" and "unit = m". The "e" in regex was meant to allow scientific notation (e.g. "1e3"), but it also matches the "e" in unit. --- ### Issue 2: Traceback "Error: Cannot convert 'px' units into 'em' units !" Steps to reproduce: 1. Create an option with a "BuilderNumberInput" with unit "px" and saveUnit set to "em". 2. Open the builder and try changing the option value. Reason for traceback: No conversion was defined for "px <-> em" in the "CSS_UNITS_CONVERSION" object, which is responsible for converting values when unit and saveUnit differ. The same issue exists for "% <-> em". --- task-6048918

Steps: - Duplicate an employee. - Check that the bank account is copied. - Modify the bank account on the duplicated employee. - Verify the original employee’s bank account. Issue: - When duplicating an employee, the bank account was copied as well, causing both employees to use the same account. Updating it for one also changed it for the other, leading to both salaries being paid to the same account. Fix: - Set the 'bank_account_id' field to not be copied during duplication, ensuring the field is cleared for the duplicated employee. task-6093406 Forward-Port-Of: odoo/odoo#259405

**Steps to reproduce** - Settings: Timesheets > Invoicing policy = only validated TS. - Have a service product with an invoicing policy based on timesheets. - Create a sales order using this product. - From the SO, click on the "Recorded" smart button and create 2 timesheets. Validate only one of them. - Invoice the SO, using a timesheets period that includes both TS. - Notice that the quantity of the invoice line includes the non-validated timesheet. **Cause** The domain excluding non-validated timesheets provided by `_timesheet_compute_delivered_quantity_domain` is not considered since c3b6053b09222d4bd2237e7de589a63fbef118f1 **Change** Since the purpose of the previous fix was to exclude timesheets linked to an invoice with a date before the "Invoicing Switch Threshold", this can be achieved by tweaking the `timesheet_domain` slightly, similar to the `_timesheet_domain_get_invoiced_lines` domain. opw-6116670 Forward-Port-Of: odoo/odoo#261077 Forward-Port-Of: odoo/odoo#259224

**STEP TO REPRODUCE** 1. Install the sale and accounting module. 2. Create 2 products, and setup each one with a different income account. 3. From the accounting settings, setup an account for Invoice Line discount -> Customer Invoice account. 4. Enable a currency, and create a pricelist for this currency. 5. Create the following SO: pricelist -> the pricelist you created previously. currency rate : 0.000717398539 line a: product_a, price 10, discount 57.85% line b: product_b, price 70, discount 57.85% From this SO, try to create an invoice. It will fail, saying the invoice it tried to create is unbalanced. opw-5974048 Forward-Port-Of: odoo/odoo#257897

Before this commit: Steps 1. Create a Polish company 2. Create and send an invoice to KSeF where the buyer has no email or no phone number 3. KSeF rejects the invoice with error code 450 (semantic verification error) This happens because `Email` and `Telefon` elements are always rendered inside `DaneKontaktowe`, even when their values are empty, producing invalid empty tags. After this commit: Add `t-if="buyer.email"` and `t-if="buyer.phone"` guards on each field so that `Email` and `Telefon` are only rendered when a value is present. opw-6124187 Forward-Port-Of: odoo/odoo#259646

The sale details report total_paid was computed from sum(order.amount_total), which does not include the cash rounding adjustment. This caused a discrepancy between the displayed total and the sum of individual payment lines when cash rounding is enabled. Use the sum of actual payment amounts instead, which naturally includes cash rounding since payments are recorded with their rounded values. opw-5253018 Forward-Port-Of: odoo/odoo#261315 Forward-Port-Of: odoo/odoo#254401

### Issue before this commit: The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field. ### Steps to reproduce the issue: 1. Download Sales and l10n_mx 2. Set a UNSPSC Category for one product 3. Go to Sales, create a new Quotation and confirm it 4. Create invoice, confirm and send & print 5. Request cancel button -> create replacement invoice 6. In the new invoice there is no source origin invoice ### Cause of the issue: The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice. ### Reason to introduce the fix: To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF. opw-6070016 Forward-Port-Of: odoo/enterprise#114099

In a multi-company context, the cron might be run with a user having a default company that is not the same as the target moves companies, maybe raising a `RedirectionWarning` (if the current company is not fully set-up). This commit ensure to fetch the invoice in move's target company. opw-5225553 Forward-Port-Of: odoo/enterprise#115192 Forward-Port-Of: odoo/enterprise#113254

### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not. **2. `qty_producing` reset on wizard open/close** Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits. ### Fix - `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend. - `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload. ### Steps to reproduce **UoM bug** 1. Create an MO, confirm it. 2. Open it in the Barcode app. 3. Try to change the UoM → it was editable (bug). **Qty reset bug** 1. Open a confirmed MO in the Barcode app, go to the header product page. 2. Type a value in `qty_producing` (e.g. `3`). 3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity". 4. `qty_producing` reverts to its previous value (bug). ### After the fix - UoM field is greyed out once the MO is confirmed. - Typed value in `qty_producing` is preserved after opening and closing the wizard. opw-5809178 Forward-Port-Of: odoo/enterprise#114452 Forward-Port-Of: odoo/enterprise#114075