Daily updates from Odoo
Monday, April 27, 2026
15 changes · saas-18.3
Resolved issues and error corrections
This update corrects a previous error in Odoo's French reporting module. Accounts 657 and 757, introduced by a recent French accounting reform (PCG 2025), are now correctly classified as current operations, ensuring accurate profit and loss statements. This resolves a mismatch previously impacting financial reporting.
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 corrects a technical issue preventing invoices sent to Chorus Pro via Peppol in France from being processed correctly. The fix removes spaces from SIRET numbers, ensuring they meet the required 14-character length and resolving a rejection error. This ensures seamless invoice delivery to the Peppol network.
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
This update fixes an issue where staff marked as unavailable in Google Calendar were incorrectly showing as available when checking appointment slots. The team also removed unnecessary code related to minimum scheduling hours, streamlining the process for Google Reserve appointments. This ensures accurate availability information for customers.
Original PR description
Resources on leave were still showing as available in BatchAvailabilityLookup responses because unavailabilities were not checked. Also remove the min_schedule_hours offset copied from the frontend logic. It is not relevant for Google Reserve as slots are pre-built in the feeds. Task-6150788 Forward-Port-Of: odoo/enterprise#114793
This update ensures that TicketBai QR codes are correctly generated when reprinting paid orders in the POS system. Previously, the QR code wasn't being set during the initial loading of historical orders, causing it to be missing. This fix guarantees accurate QR codes for seamless order processing.
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
This update resolves an error that occurred when importing CODA bank statement files from Belgian banks. Some banks provide files with an incremented detail sequence (3.2), which previously caused an import failure. The fix adjusts the import process to handle this incremented sequence without triggering an error, ensuring smoother bank statement integration.
Original PR description
### Issue: Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2…
### Issue: Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2 https://febelfin.be/media/pages/publicaties/2023/febelfin-standaarden-voor-online-bankieren/5607daeda5-1754302976/standard-coda-2.7-en.pdf Importing such files raises an error: `Error R3004: CODA parsing error on information data record 3.2, seq 00020002! Please report this issue via your Odoo support channel.` ### Cause: The parser compared the full `infoLine['ref']`, while only `infoLine['ref_move']` needs to remain consistent https://github.com/odoo/enterprise/blob/a6efef92b86d95e05245c4ccf26324d37cc153e6/l10n_be_coda/models/account_journal.py#L683-L698 The `infoLine['ref_move_detail']` (3.2 sequence) change should not block import when incremented and should not trigger an error ### Steps to reproduce: - Install `l10n_be_coda` and switch to the `BE company` - Import a CODA file with incremented 3.2 detail sequence (e.g., files available in related tickets or test data) Before the fix, the error is trigger opw-6071761 Forward-Port-Of: odoo/enterprise#113904
This update fixes a potential issue where users could incorrectly validate signatures in draw mode using Firefox and similar browsers. Now, the system requires a visible signature drawing before validation, ensuring signatures are only confirmed when a genuine signature is present. This improves the accuracy and reliability of our document signing process.
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
This update fixes a minor display issue in the Helpdesk dashboard. Previously, the 7-day average rating was shown as a percentage, which was confusing for users. Now, it's displayed as a score out of 5, providing a clearer and more intuitive representation of performance.
Original PR description
Steps to reproduce: - Open the Helpdesk app with demo data. - Check the "My Performance" section of the dashboard. Current behavior: - "Avg Last 7 days" is shown as "3.50 %". Expected behavior: - "Avg Last 7 days" is shown as "3.5 / 5". Issue: The backend already computes `7days.rating` as a 0-to-5 average, but the frontend dashboard template appends a "%" suffix. Solution: Update the Helpdesk dashboard template to display the 7-day average as a score out of 5 instead of as a percentage. task-5998903 Forward-Port-Of: odoo/enterprise#109804
This update addresses a potential error in the account reporting module that could occur when clients use custom modules with similar field names. The fix ensures the system correctly identifies column references, preventing errors and ensuring accurate reporting. This improves stability and reliability for all users.
Original PR description
Issue: ------- There are cases where clients might have the same named 'state' field/column for custom modules in the models 'res.partner' or 'account.fiscal.position' and therefore they might get conflicted with the standard one's when the below query executes, https://github.com/odoo/enterprise/pull/84391/changes#diff-2f90e40d6e7b35681a4af03037e8e5ee0fddab2ba0876d9f148bf79786a91c29R1359 and can cause ``` File "/home/odoo/src/enterprise/account_reports/models/account_return.py", line 2204, in _check_suite_common_vat_report self.env.cr.execute(SQL( File "/home/odoo/src/odoo/odoo/sql_db.py", line 433, in execute self._obj.execute(query, params) psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous LINE 9: state = 'posted' ``` Solution: ------------ Use the corresponding alias while mentioning the column i.e; `move.state = 'posted'` OPW - 6044665
This update resolves an issue where the automated invoice retrieval process (cron job) in Odoo Enterprise wasn't correctly identifying the target company when multiple companies were involved. The fix ensures invoices are fetched from the correct company, preventing errors and improving the reliability of reporting. This improves data accuracy for multi-company users.
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#114937 Forward-Port-Of: odoo/enterprise#113254
This update ensures the Odoo spreadsheet component is running the most recent version, providing the latest features and improvements. It addresses a bug related to preserving spaces in data validation, ensuring data integrity within spreadsheets. This update is a routine maintenance task.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/8cc55b27d1 [REL] 18.3.44 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5e016dd663 [FIX] data_validation: preserve spaces in dv values [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>
This update corrects a warning message appearing when using the UK Construction Industry Scheme (CIS) reporting. The fix prevents the system from incorrectly flagging vendor bills with CIS tax as inactive, ensuring accurate reporting and reducing unnecessary alerts. This change improves the reliability of UK tax reporting within the Odoo Enterprise system.
Original PR description
Currently, journal entries may be flagged for the CIS inactive partner check, causing unnecessary warning. Steps to reproduce: - Install l10n_uk_reports_cis. - Accounting > Configuration > Settings, enable "Cash Basis" - Open "20% CIS" Purchase tax - Set "Tax Exigibility" to "Based on Payment" and add a Cash Basis Transition Account - Set Outstanding account on the Bank journal - Create a partner and enable (Accounting tab) Construction Industry Scheme" - Create a vendor bill for this partner with a the 20% CIS tax - Register payment to the Bank journal - Open the created CABA entry Issue: Warning will be shown "Construction Industry Scheme hasn't been enabled for this vendor." Analysis: The warning flag is incorrectly triggered because the CABA entry has `invoice_line_ids` field set. However entries should be excluded by this check as it should only apply to purchase-related documents. opw-5942603 Forward-Port-Of: odoo/enterprise#113003
This update resolves an issue where the custom declaration field wasn't automatically filled for international World Express Pro shipments within the BPost module. Now, the system correctly populates this essential field, ensuring accurate customs documentation and smoother international deliveries. This improves compliance and reduces potential delays.
Original PR description
Before this commit, the bpost module was not filling the custom declaration in case of international shipping (World Express Pro) After this commit, the section is filled opw-4932970 Forward-Port-Of: odoo/enterprise#101476
This update prevents portal users from seeing the 'View Timesheets' button on invoices when they lack the necessary permissions. Previously, the button appeared based on the presence of timesheets linked to the sale order, even if the user didn't have access. This change ensures users only see timesheets they are authorized to view, improving data security and user experience.
Original PR description
sale: add sale order specific hook to extend page values ------ Allows adding custom data (e.g., timesheets) without overriding generic _get_page_view_values sale_timesheet: hide 'View Timesheets'…
sale: add sale order specific hook to extend page values
------
Allows adding custom data (e.g., timesheets) without overriding generic _get_page_view_values
sale_timesheet: hide 'View Timesheets' button for users without access
-------
Steps to Reproduce:
-----------------
- Create a product with the invoice policy set to Based on Timesheets
- Enable Project and Tasks on the order.
- Create and confirm a sale order using a portal user.
- Log timesheets on the related task.
- Create an invoice from the sale order.
- Log in as the portal user and open the invoice.
- Click the 'View Timesheets' button.
Issue:
-------------
The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets.
Root Cause:
------------
The timesheets are linked to the sale order, so the button appears based on the timesheet_count, but the portal user does not actually have permission to access those timesheets.
Fix:
-----------
We replaced the timesheet_count check with a check that verifies whether the user actually has access to any of the related timesheets.
task-4745519
Forward-Port-Of: odoo/odoo#261079
Forward-Port-Of: odoo/odoo#209552This update resolves a bug where portal users were incorrectly seeing the 'View Timesheets' button, even without the necessary permissions. The fix utilizes a new helper method to accurately control button visibility based on user access, ensuring a better user experience.
Original PR description
**Issue:** The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets. Currently, we have added _sale_order_get_page_view_values in the sale module, which is overridden in sale_timesheet. We are using it here. task-4745519 Forward-Port-Of: odoo/enterprise#114915 Forward-Port-Of: odoo/enterprise#113481
This update corrects a typographical error within the marketing automation test suite. The fix ensures the tests run smoothly and reliably, maintaining the quality of the Odoo Enterprise platform. This is a routine maintenance task to improve the stability of our software.
Original PR description
Forward-Port-Of: odoo/enterprise#115315