Monday, April 27, 2026
12 changes · saas-18.4
Resolved issues and error corrections
French Peppol invoice exports now remove spaces from company and customer SIRET numbers before sending to Chorus Pro. This prevents valid invoices from being silently rejected because the identifier length appears incorrect.
Original PR description
### Issue: When sending invoices to Chorus Pro via Peppol in France, SIRET numbers may contain spaces, causing the document to be silently rejected ### Cause: SIRET values must be exactly 14…
### Issue: When sending invoices to Chorus Pro via Peppol in France, SIRET numbers may contain spaces, causing the document to be silently rejected ### Cause: SIRET values must be exactly 14 characters long However, spaces were not removed when generating the XML, leading to invalid values in: `<cbc:ID schemeID="0009">` and `<cbc:CompanyID schemeID="0009">` This issue can occur for both the company and the customer SIRET, as both rely on `company_registry` As a result, Chorus Pro rejects the document due to invalid SIRET length ### Steps to reproduce: - Install `l10n_fr_facturx_chorus_pro` and switch to `FR Company` - Enable and Activate Peppol in Settings - Go in Settings > Users & Companies > Companies and open the `FR Company` - Add spaces in the Company ID: 968 515 7590 5808 - Create a Customer (Country: France, VAT: FR23334175221, Company ID/Siret: 123 456 7890 1234) - In the customer's Invoicing Tab (Invoice sending: by Peppol, eInvoice format: EU Standard (Peppol Bis 3.0), France SIRET: 11000201100044) - Create and Send an invoice via Peppol (Your Customer, any line with a tax) - Open the XML - Check the IDs and CompanyIDs in the document Before the fix, there is missing spaces opw-6047840 Forward-Port-Of: odoo/odoo#260578
Paid POS orders reprinted after restarting or reloading the point of sale now include the required TicketBai QR code. This helps Spanish businesses keep receipts compliant and avoids missing tax validation information on historical order reprints.
Original PR description
When printing a paid order after reloading the POS, the TicketBai QR code was missing. The QR source (l10n_es_pos_tbai_qrsrc) was only set during _postPushOrderResolve after payment, but not when loading historical orders from the backend. opw-6068076 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261102 Forward-Port-Of: odoo/odoo#259372
Grouped payments now include only the currently due installment for multi-installment vendor bills, instead of paying the full bill too early. This prevents overpayment in batch payment workflows and keeps vendor payments aligned with agreed payment terms.
Original PR description
Steps to reproduce: 1- Install Accounting and make sure "Batch Payments" is enabled in settings 2- Go to [Accounting -> Vendors -> Bills] 3- Create two bills for the same vendor, ensuring one of them has multiple installments (i.e payment term with 3 installments) 4- Confirm the bills 5- In list view, select both bills and another bill from a different vendor and click on Pay 6- Select "Group Payments" and confirm the payment Description of issue: The batch payment of the first vendor has the full amount for both bills Expected behavior: The payment should consider the full amount of the first bill and the first installment only of the second bill opw-5969972 Forward-Port-Of: odoo/odoo#260933 Forward-Port-Of: odoo/odoo#257871
This fix prevents users on Firefox-like browsers from confirming a signature field when nothing has actually been drawn. It helps ensure signed documents contain a visible, intentional signature before validation.
Original PR description
On Firefox and similar browsers, it was possible in some cases to validate a signature field in draw mode without actually drawing a signature, allowing the document signature to be confirmed with an empty signature. This change ensures that a signature field in draw mode can only be validated when the signer has effectively drawn a visible signature. task-6117312 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259100
The event talk reminder form now opens and submits without accidentally sending visitors to the talk page. It also shows a single clear confirmation message instead of duplicate notifications, making the reminder experience less confusing.
Original PR description
This PR fixes the email reminder form with multiple commits: - Commit 1 fixes the notifications displayed when the email form is submitted as the messages of those notifications are redundant. - Commit 2 inserts the form inside the HTML body instead of the interaction's HTML since the surrounding HTML of this last one may cause display issues as with the <a> tag redirecting the users on the talks page when they click on the form which should not happen. Task-5347538 Forward-Port-Of: odoo/odoo#251468
This update brings the spreadsheet component to its latest version and fixes issues with data filters and side panel data validation lists. Users should see more reliable filter selection controls, preserved spacing in validation values, and more consistent color behavior.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6098eb6a38 [REL] 18.4.36 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6098eb6a38 [REL] 18.4.36 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/9bfdda39e5 [FIX] Data filter : clear/select all button [Task: 6075166](https://www.odoo.com/odoo/2328/tasks/6075166) https://github.com/odoo/o-spreadsheet/commit/2a7546420d [FIX] side_panel: preserve spaces in DV values and fix color mapping [Task: 5418098](https://www.odoo.com/odoo/2328/tasks/5418098) https://github.com/odoo/o-spreadsheet/commit/ce11a7a953 [FIX] side_panel: stabilize list criterion color sync [Task: 5418098](https://www.odoo.com/odoo/2328/tasks/5418098) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
Fixes an issue where creating a sales order line from a project task could accidentally create a new sales order instead of using the existing one. This helps keep sales and project records accurate and avoids duplicate orders that could confuse billing or reporting.
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 Forward-Port-Of: odoo/odoo#258201 Forward-Port-Of: odoo/odoo#203230
Sales orders confirmed from the customer portal now use the correct company when selecting project templates for service products. This prevents errors and ensures projects are created for the customer's company instead of the default bot company.
Original PR description
project_template_id is a company dependent field. When creating a project, it is called without the proper company context set up. When confirming an SO through the portal, the order's env is setup…
project_template_id is a company dependent field. When creating a project, it is called without the proper company context set up. When confirming an SO through the portal, the order's env is setup without a company and `.with_user(SUPERUSER_ID)`, making future company_dependent variables use OdooBot's company. Following examples earlier in the function, call `.with_company` while accessing project_template_id. Steps to reproduce: 1. Install Sales and Project 2. Create second company 3. Create Customer with portal access, under created company 4. Create service product with different projects for each company 5. Create sales order with customer and service product, send to customer 6. Login as customer on portal, accept and sign SO a. Should stall, RPC Error in console Ticket: opw-6082772 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261065 Forward-Port-Of: odoo/odoo#260387
Invoice imports that group lines now adjust tax amounts when grouping changes the calculated total. This helps keep electronic invoice amounts accurate and aligned with Belgian tax scenarios.
Original PR description
[FIX] account_edi_ubl_cii: correct tax amount when grouping lines When the user group lines of a move, the tax amount is now corrected if there's a difference in the tax amount before and after grouping This commit also removes the `ungroup_lines` context key, as the flow was changed in odoo/odoo#252458 Reword the `test_import_and_group_lines_by_tax` test: use belgian company and belgian taxes task-5993555 Forward-Port-Of: odoo/odoo#257581 Forward-Port-Of: odoo/odoo#252719
This update addresses a discrepancy in Odoo's French reporting (l10n_fr_reports) related to recent French accounting reforms (PCG 2025). Specifically, accounts 657 and 757, used for current operational capital gains and losses, are now correctly classified, ensuring accurate financial reporting and compliance.
Original PR description
…tions As part of the PCG 2025 reform in France, accounts 657 and 757 were introduced to handle capital gains and losses on the disposal of tangible and intangible assets related to normal, current activities. Previously, Odoo incorrectly categorized these under exceptional items which led to mismatches in the P&L. Source: https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Plans%20comptables/PCG--1er-janvier-2025.pdf Relevant excerpts: <img width="630" height="372" alt="image" src="https://github.com/user-attachments/assets/88a66dac-1cc0-4a33-a902-edb6b626f18f" /> <img width="631" height="318" alt="image" src="https://github.com/user-attachments/assets/403b65dc-20ba-447e-937d-20575f1f45ab" /> opw-6105764 Forward-Port-Of: odoo/enterprise#115054 Forward-Port-Of: odoo/enterprise#114837
This update allows administrators to override the automatic resetting of subscription user accounts. Previously, this process was difficult to control, but now it's easily configurable, providing greater flexibility in managing user access within the subscription model. This change ensures better control over user lifecycle management.
Original PR description
After this commit, the auto resetting of subscription user is overridable. Doing business logic in CRUD methods makes them impossible to bypass, by encapsulating the logic in another method, it would be easily overridable. Forward-Port-Of: odoo/enterprise#114459 Forward-Port-Of: odoo/enterprise#114055
This update resolves an issue where changing the account on bank reconciliation lines with analytic distributions would cause errors and data inconsistencies. The fix ensures accurate account updates by properly managing analytic line links during editing, preventing orphaned analytic lines and improving the bank reconciliation process.
Original PR description
Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account. When an analytic distribution was present, editing the line created analytic…
Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account. When an analytic distribution was present, editing the line created analytic lines linked to the move line. However, changing the account from the form view in the bank reconciliation widget triggered _inverse_account_id, which in turn called _inverse_analytic_distribution. This resulted in unlinking the analytic_line_ids from the move line, preventing the account change from being applied. On a second attempt, the account could be modified because there were no longer any analytic lines to unlink. This led to orphaned analytic lines not linked to any journal item. To fix this, the inverse method is now disabled while editing the line in the form view. Upon saving, the analytic_line_ids are explicitly unlinked, and _create_analytic_lines is triggered during the update to correctly recreate the analytic lines. opw-6107329 Forward-Port-Of: odoo/enterprise#114863