Wednesday, April 8, 2026
12 changes · 18.0
Resolved issues and error corrections
This update ensures that negative values in the Mod 390 tax reports for Spain are accurately marked with the 'N' indicator, as required by Spanish tax regulations. The fix addresses a previous issue where these negative values were not being properly formatted for export, ensuring compliance and accurate reporting.
Original PR description
### Issue: Negative values in the Mod 390 report were not properly marked with the N indicator for several fields ### Cause: The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export ### Note: According to the official specification, negative amounts must be explicitly marked with N Latest documentation: https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx ### Steps to reproduce: - Install `l10n_es_reports` with demo data and switch to the ES company - Create a Bill (Price: 100, Taxes: 21% G) - Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year - Open the VAT Deductible tab - The last line (65) should be negative - Export the BOE file using the gear menu - Check the last value of section 4 in the file ### Before the fix: Negative values were not marked with N opw-5482706 Forward-Port-Of: odoo/enterprise#111262
This update resolves a technical issue preventing the correct return of invoice data during import through the Peppol system. The change ensures that the system now accurately reports the newly created invoice move, addressing a previous bug. This improves the reliability of invoice processing within the Peppol integration.
Original PR description
Due to 271d6f2af4eea1ac2a79850069118c00dd97db97, the import invoice method in Peppol should return the created move and not just True. With the documents_account_peppol module, that change was not fully merged. opw-6102218
This update resolves an issue where accounting data wasn't correctly handling multiple company setups within the Danish localization (l10n_dk) module. The change ensures that accounting records are now associated with the correct company, improving data accuracy and compliance. This update was made after addressing a previous bug report.
Original PR description
Fixes https://github.com/odoo/odoo/pull/257623. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the formatting toolbar would unexpectedly open when selecting text within inline code. Now, formatting commands only apply to the main text content, and pasted HTML within inline code is correctly converted to plain text. This ensures a smoother and more reliable experience for users working with code snippets.
Original PR description
### Purpose of this commit: - Prevent the powerbox and toolbar from opening when the selection is fully inside inline code. When the selection spans inline code and regular text, keep the toolbar visible but ensure formatting commands are applied only to the non-inline-code content. - Ensure that pasted external and editor HTML is converted to plain text when inserted inside inline code. task-5502939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where marketing emails in RTL languages (like Arabic) were incorrectly displayed as left-to-right. The fix adds a necessary style rule to ensure proper formatting by the email composer, maintaining the intended RTL layout. This improves the user experience for international customers.
Original PR description
**Steps to reproduce:** - Install Mail Marketing app - Change user language to a RTL language (such as Arabic) - Create a marketing campaign with RTL content - Send it (with the campaign, test mail works properly) - Mail received changes from RTL to LTR **Issue:** Table `direction` style is removed by the `_Cleaner` as it is not in its `_style_whitelist` during the composer creation. **Fix:** Add it to the valid styling to ensure rtl mails are properly formatted by the rtlcss library. related fix: https://github.com/odoo/odoo/commit/4ac3766fa5b458864c1728441cf4a157df943d39 sanitize on `mail.composer.mixin`: https://github.com/odoo/odoo/commit/24731938f75358fd3c72b91465b72ab80d62d208 opw-5982854
This update resolves a problem where custom paper format settings for lot/serial number labels resulted in multiple blank pages in the PDF output. The fix adjusts the underlying report design to correctly handle smaller paper sizes, ensuring labels print accurately and efficiently.
Original PR description
__ ## Short functional explanation of the error When printing labels of lot or serial products with a custom paper format, the obtained pdf contains several empty pages. ## Reproduction Steps 1.…
__ ## Short functional explanation of the error When printing labels of lot or serial products with a custom paper format, the obtained pdf contains several empty pages. ## Reproduction Steps 1. Enable Debug Mode. In Settings, click on the Technical tab. In the reporting section, click on Paper Format. 2. Click on New. Give a name to your paper format. In the Paper Size field, select Custom. For Page Height and Page Width, make sure that they're smaller than A4 measurements. For example, set the Page Height at 57 and Page Width at 35. Set Margins at 0. In the Associated Reports field, select `lot/Serial Number (PDF)`. 3. Go to Inventory. Click on the Products tab > Lots / Serial Numbers. Click on any Serial Number. Click on the Cog on the top left > Print > Lots / Serial Number (PDF). ### Expected behavior We obtain a PDF of only one page containing the barcode of the serial number. ### Unexpected behavior We obtain a PDF of 5 pages, including 4 blank pages and only one page holding the barcode. ## Origin of the issue In the XML of the label reports, we use the css class `o_label_sheet`: https://github.com/odoo/odoo/blob/ec2300456599e2b3bed5ba130badb63bb9bf15b3/addons/stock/report/report_lot_barcode.xml#L9 In this class, the height and width of sheets are hardcoded to A4 dimensions: https://github.com/odoo/odoo/blob/ec2300456599e2b3bed5ba130badb63bb9bf15b3/addons/product/static/src/scss/report_label_sheet.scss#L5-L6 Therefore, if we set the dimensions of the custom paper format to be smaller than an A4 page, we'll obtain several blank pages, until the dimensions of an A4 pages are met. Moreover, the dimensions of the padding are also hardcoded, which can be an issue in the case of very small custom dimensions. Finally, we nest barcodes in an HTML table: https://github.com/odoo/odoo/blob/ec2300456599e2b3bed5ba130badb63bb9bf15b3/addons/stock/report/report_lot_barcode.xml#L10 for which we hardcode the dimensions: https://github.com/odoo/odoo/blob/ec2300456599e2b3bed5ba130badb63bb9bf15b3/addons/stock/report/report_lot_barcode.xml#L6-L7 This will result in always printing the same amount of barcodes per row in the case of batch printing, even if the dimensions are too small to hold them all. This will also result in always nesting 12x4 barcodes, even when only printing one, while hiding the others, which also produces additional unrequired blank pages. Therefore, we need the dimensions indicated in the paper format of the report to dynamically compute the dimensions of the padding and the rows/columns of the HTML table. __ opw-6071885
This update fixes an issue where Backspace within a blockquote would remove the blockquote itself, moving content outside. It also resolves problems with trailing line breaks after tables and prevents lists from being created inside blockquotes. These changes enhance the editor's usability and allow for more flexible content formatting.
Original PR description
Description of the issue this PR addresses: - Pressing Backspace inside a blockquote that has visible content but no text content removes the blockquote instead of the content. The content (image or table) gets moved outside of the blockquote. - Trailing BR was kept after tables because tables are marked as unsplittable blocks. This left unnecessary BR nodes after tables in blockquote. - Lists could not be created inside a `blockquote`. Desired behavior after PR is merged: - Backspace removes the inner content first when blockquote contains nodes. - Trailing BR is removed when placed table inside blockquote. Cursor can still be placed at the edge of the table without requiring a BR anchor. - Lists can be created directly inside a blockquote. task-5864080 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a flaw in how the digest KPI tracks user connections. Previously, it only considered a user's 'Default Company,' leading to inaccurate counts for users working across multiple companies. Now, the KPI correctly accounts for all companies a user belongs to, providing a more reliable measure of user engagement.
Original PR description
**Problem:** Currently, the digest KPI for connected users checks the "company_id" field (as with all other models), but this field corresponds to "Default Company" on res.users, meaning a user can only be considered for one company when computing the digest KPI. This can cause misleading digest KPIs if users work in multiple companies, or mainly in a company that isn't their default company. **Solution:** Instead of always using the "company_id" field, we use the "company_ids" field if present on the model. opw-5404940 Forward-Port-Of: odoo/odoo#247806
This update corrects a previous issue where loyalty point transactions in a single POS order were only recorded as a net difference. The fix now accurately tracks both points earned and spent, ensuring a complete and precise record of loyalty card activity in the system. This improves the reliability of loyalty program reporting.
Original PR description
When a loyalty card both earned and spent points in the same POS order, the history entry only reflected the net difference instead of the gross amounts. The root cause was that the JS payload sent only a single `points` field representing the net change. Fix by tracking `points_earned` and `points_spent` separately in `couponData` and sending them to the server. opw-6041420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where invoices for downpayments weren't consistently using the correct expense account. The change ensures that downpayment invoice lines now automatically use the designated account (ACC1) when creating bills, streamlining the accounting process and improving accuracy. This resolves a previous error related to downpayment accounting.
Original PR description
Steps to reproduce: 1/ install purchase and accountant 2/ create and setup an expense account dedicated to your downpayments (typically code 60-, account type "expense"), ACC1. 3/ setup a service type product named "downpayment" 4/ set the default expense account on that product to be ACC1. 5/ create a PO for any product other than the downpayment (PO1). take note of the partner. 6/ create a bill for the same partner as the one set on PO1. Call it BILL1. 7/ On BILL1, add one invoice line with the "downpayment" product. Set a unit price. 8/ Confirm BILL1 and match it with PO1 via the "bill matching" smart button. Add it as a downpayment. 9/ Back on PO1, receive the products. Create a bill (BILL2). => The account suggested for the downpayment line in BILL2 will use the default expense account instead of ACC1. After this commit, the account suggested will be the one used in BILL1 for the downpayment line. opw-5253877
This update resolves a problem where the POS cashier user couldn't correctly process ZATCA EDI documents due to a lack of necessary permissions. The change ensures the system elevates privileges when writing to these documents, preventing errors and enabling proper transaction processing. This improves the reliability of the POS system for Saudi Arabia.
Original PR description
The POS cashier user does not have the Accounting group, so calling _process_documents_web_services() on account.edi.document without elevated privileges raises an AccessError on the write() in _postprocess_post_edi_results. The original flow avoids this because _generate_and_send_invoices uses move.sudo() as the dict key, propagating the sudo context through action_process_edi_web_services() down to the EDI document write. Our override must do the same by accessing edi_document_ids via account_move.sudo(). opw-6106524 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a silent error in the Nilvera EINvoice module, which prevented proper invoice imports. The method name was incorrectly updated, causing the override to be ignored. By renaming the override to match the parent class, the import process is now functioning as intended.
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. # 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. task-id: None --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr