Daily updates from Odoo
Thursday, April 9, 2026
18 changes · 19.0
New functionality added to Odoo
This pull request includes updates to the localization files (i18n) for the 'account_3way_match' module. These changes involve translating the module's text into multiple languages, including Arabic, Azerbaijani, Bulgarian, Catalan, Czech, Danish, German, Greek, Spanish, Estonian, Farsi, Finnish, French, Hebrew, and more. This ensures the module is accessible and usable for a wider range of users and regions.
Enhancements to existing features
This update streamlines payment status updates by hiding the refresh button when payments are finalized. Previously, the button triggered unnecessary calls to OdooFin, impacting performance. Now, the button is only visible for payments that are actively being processed.
Original PR description
… batches The refresh button was always shown, which could cause unnecessary calls to OdooFin if the payment is finalised (accepted, rejected or canceled). With this change, the button is shown only for payments in progress (pending or unsigned). task-6103900
This pull request addresses several localization and technical improvements across Odoo modules. It includes adjustments to AFIP compliance for Argentinian financial reports, fixes a German address issue for Amazon, and resolves a bug related to employee skill copying in appraisals. The changes ensure data accuracy and improve user experience.
This update optimizes the performance of our calendar functionality. A new database index has been added to speed up searches related to calendar resources, specifically when filtering by user. This change will result in faster calendar loading and searching.
Original PR description
This commit adds an index on `planning.calendar.resource.user_id`, as it's the only criteria used in `get_calendar_filters` for the `search_count` and the `search_read` done after.
Resolved issues and error corrections
This update resolves an issue where closing an Odoo session was prevented if the order's user information was incomplete during a specific export process (DSFinV-K). The change ensures that a fallback user ID is used, allowing sessions to be closed correctly and preventing disruptions to business operations. This improves session management reliability.
Original PR description
Before this commit, closing a session was blocked if an order was missing the user_id field during DSFinV-K export generation. opw-6067382 Forward-Port-Of: odoo/enterprise#112119
This update resolves a problem where payments related to EPD (early payment discount) bills weren't correctly updating their status. The fix ensures payments are accurately marked as 'paid' after reconciliation, improving the accuracy of financial reporting. This prevents discrepancies in payment tracking.
Original PR description
Steps to reproduce: - Create an early payment term. - Create a Vendor Bill with EPD and post it. - Register a payment for this bill (no outstanding account set on journal => no move created). - Create a bank transaction fully paying the bill. - Reconcile the transaction with the bill. Issue: Access the payment of the bill. The payment state remains 'in_process' instead of 'paid'. Fix in community: https://github.com/odoo/odoo/pull/256486 opw-5881976 Forward-Port-Of: odoo/enterprise#112398
This update resolves an issue where negative values in the Mod 390 tax report were not being properly marked with the 'N' indicator, as required by Spanish tax regulations. The fix adds a necessary parameter to ensure accurate reporting, aligning with official documentation and improving compliance.
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…
### 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#113200 Forward-Port-Of: odoo/enterprise#111262
This update fixes a problem where unclear error messages were displayed when the SendCloud delivery service encountered issues. The change adds a helpful hint message to guide users in resolving these problems, improving the overall user experience. This ensures smoother delivery processes and reduces potential delays.
Original PR description
Add hint with error message. ----- Ticket: opw-6072855 Forward-Port-Of: odoo/enterprise#112463
This update resolves a bug that caused PDF attachments to be incorrectly re-parented during the Send & Print process, leading to data inconsistencies. The fix prevents the creation of a document when a PDF attachment lacks a defined model, ensuring proper attachment management and preventing data loss.
Original PR description
Steps to reproduce: - Set a journal with documents folder sync (by default with demo data) - Create and post a customer invoice - Add an image or pdf attachment via a log note (it becomes…
Steps to reproduce: - Set a journal with documents folder sync (by default with demo data) - Create and post a customer invoice - Add an image or pdf attachment via a log note (it becomes message_main_attachment_id and creates a documents.document with res_model=False) - Click Send & Print Issue: KeyError: `proforma_pdf_attachment` Cause: During Send & Print, _link_invoice_documents creates the invoice pdf attachment (res_model='account.move', res_field='invoice_pdf_report_file') and sets it as invoice.message_main_attachment_id. During the acoun_move write, in `documents_account`, it searches for an existing document matching the previous `message_main_attachment_id` (`initial_attachment`) and sets `document.attachment_id` to the invoice pdf. https://github.com/odoo/enterprise/blob/6bdcc357b195faa0aad8c05eac23aa0a762dd76b/documents_account/models/account_move.py#L41-L54 This triggers the versioning logic which resets the parent of the attachment when its `res_model` and `res_id` differs from the document. Because the document has res_model=False, the condition always matches and the pdf is re-parented to `documents.document`, deleting res_field's binding to account.move. After invalidate_recordset https://github.com/odoo/odoo/blob/95666545fcd934bf4084f680e692633783ae5603/addons/account/models/account_move_send.py#L477 invoice_pdf_report_id recomputes to an empty recordset. https://github.com/odoo/odoo/blob/7b384a6ec13c372b44e2a58134c61d54de152395/addons/account/models/account_move.py#L2205 _get_invoice_extra_attachments returns empty, Eventually, we try to access move_data['proforma_pdf_attachment'] which was never set (fallback for otehrscenario) https://github.com/odoo/odoo/blob/95666545fcd934bf4084f680e692633783ae5603/addons/account/models/account_move_send.py#L856 -> KeyError. Solution: We prevent the creation of a document if no res_model is set. And extra guard-rail is kept: Skip re-parenting in DocumentsDocument.write() when the incoming attachment has res_field set. Attachments linked via a Binary field are owned by their model and must never be moved to documents.document regardless of the document's own res_model. opw-5930888
This update addresses an issue where delivery confirmations were failing due to missing tracking information from Easypost. The fix ensures that picking validation occurs correctly and prevents shipping creation in Easypost when tracking data is unavailable. Easypost support suggested a slight delay between order placement and tracking retrieval as a potential workaround.
Original PR description
Problem: 'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs…
Problem: 'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs with error: TypeError: 'NoneType' object is not subscriptable. As a result the picking is not validated in odoo but a shipping has succesfully been created in the easypost backend. Solution: Prevent traceback form happening, picking gets correctly validated and carrier_tracking_url field is empty. Transcript from Easypost support: << I'm also seeing the tracker showing as null when reviewing the response. I'll go ahead and create a ticket for the engineering team to investigate. I can see that the tracking code is being returned in the request, but the full tracking object is not. Since this appears to be happening on a case-by-case basis, you may want to allow more time between the BUY and the GET requests, as I noticed they are being triggered very close together. I'm not certain if that's related, but it may be worth trying as a troubleshooting step while we have this under review. >> opw-5402415 Forward-Port-Of: odoo/enterprise#111833
This update corrects a problem where the '&' character in vendor bill references was incorrectly exported as '&' in SEPA payment files. This prevented successful processing of payments by banks, ensuring compliance with SEPA regulations and accurate financial reporting. The fix replaces '&' with '+' to adhere to the required character set.
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 &…
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 `&` 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 Forward-Port-Of: odoo/enterprise#110809
This update fixes an issue where Odoo incorrectly consumed stock from the wrong location when scanning serial numbers on manufacturing orders. The fix ensures the correct warehouse location is used, preventing errors in stock tracking and improving order fulfillment accuracy. This resolves a potential problem with inventory management.
Original PR description
Steps to reproduce: - Create a Manufacturing Order with a serial-tracked component. - Open the Shop Floor. - Scan the serial number barcode to register the component. - Observe which location the component was consumed from. Issue: When a product is received from a vendor, Odoo creates two quants for the same serial number — one at Partners/Vendors location and one at WH/Stock location. Because get_quant_from_barcode searched for a matching serial number with no location filter, it returned whichever quant had the lowest database ID — which was always the Partners/Vendors or Production quant created first — instead of the correct WH/Stock quant. Solution: Prevent selecting a quant from an incorrect location when multiple quants exist for the same serial number, as this can lead to consuming stock from the wrong location. opw-5974474 Forward-Port-Of: odoo/enterprise#112691
This fix resolves an issue where the bank reconciliation process would fail when using the liquidity account as an outstanding payment account. The update prevents automatic reconciliation in this scenario, ensuring data integrity and preventing a persistent error message. This improves the reliability of bank statement matching.
Original PR description
# How to reproduce - Create a new Journal - Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity…
# How to reproduce - Create a new Journal - Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity account - Go to the Transactions of the Journal - Add a new Transaction for partner X and amount Y - Add a second Transaction also for partner X and amount Y # The issue A popup appears that can never be saved # Cause When we click on "Add & New" or "Add & Close", we run the `validate()` function : https://github.com/odoo/enterprise/blob/9abb50b9b29e01897b4fb90ae228beecbdfcd5af/account_accountant/static/src/components/bank_reconciliation/quick_create/quick_create.xml#L14-L16 Which tries to do a model save, but it fails so it show the Form dialog : https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/web/static/src/views/kanban/kanban_record_quick_create.js#L159-L163 The save fails because : This commit (https://github.com/odoo/enterprise/commit/e2b3439dcda26f84b9a290c8d5fb819dd3250825) changed the the logic behind auto-reconcilation with an outstanding account. When there is an outstanding account, we try to auto-reconcile the bank statement with that account and succesfully do so : https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L381-L385 https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L245 But this should not happen when the outstanding account is the liquidity account, because it will end up throwing an error when the amount is matched more than once: https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/account/models/account_bank_statement_line.py#L727-L737 opw-6063654 Forward-Port-Of: odoo/enterprise#112750
This update corrects a previous issue where the Amazon fulfillment channel in the sales module was incorrectly displayed as read-only. The change ensures users can now modify this setting, streamlining the process for managing Amazon sales operations. This improves flexibility and control over fulfillment options.
Original PR description
Commit 67c45d6494f082e2ee83b9a84611e8b8fe8f4fd5 intended to make `amazon_channel` editable by users. However, the field was displayed with the `badge` widget, which is read-only, so it remained uneditable. Use an editable display for `amazon_channel` so the original fix works as intended. Forward-Port-Of: odoo/enterprise#113196 Forward-Port-Of: odoo/enterprise#112866
This update corrects the calculation of the employment bonus in the Odoo Enterprise accounting module for Belgium. The change reflects the latest regulations from Partena Professional, ensuring accurate bonus payments up to April 2026. This update maintains compliance with Belgian tax laws and avoids potential financial discrepancies.
Original PR description
https://www.partena-professional.be/fr/le-bonus-lemploi-au-1er-avril-2026?utm_source=sfmc&utm_medium=email&utm_campaign=InfoFlash+Daily+Mail+-+FR&utm_content=article-read-more-cta&utm_term=All%20Subscribers&utm_id=81873&sfmcContactKey=litom@odoo.com Forward-Port-Of: odoo/enterprise#112970
A bug was preventing users from deleting timesheet records when a confirmation dialog was open. This was due to the timer hotkey incorrectly responding to the Enter key. This update ensures that pressing Enter in the timesheet list view now correctly triggers the deletion process, resolving a key usability issue.
Original PR description
When a delete confirmation dialog is open in the timesheet list view, pressing Enter starts/stops the timer instead of confirming the dialog. This happens because the timer's window keydown handler does not check for active modals before intercepting the Enter key. Add a `.modal` check consistent with the grid renderer's onKeyDown. Steps to reproduce: 1) Open timesheet list view 2) Select a record and delete it 3) When the confirmation dialog opens, hit ENTER key Current behavior: The Timer starts recording timesheet Expected behavior: The record should be deleted For ref: https://youtu.be/tzm_3RNe1ig Forward-Port-Of: odoo/enterprise#112583
This update corrects a discrepancy in the FAIA XML export format for Luxembourg accounting reports. It ensures that invoice transaction and account IDs are consistently linked across the system, resolving potential export errors and improving data accuracy. This change is part of a larger effort to enhance the reliability of financial reporting.
Original PR description
This is one of several commits fixing the FAIA xml export. The `Invoice/TransactionID` element in `SourceDocuments/SalesInvoices` and `SourceDocuments/PurchaseInvoices` must match the corresponding `Transaction/TransactionID` in the `GeneralLedgerEntries` section. As the latter uses the entry `name` since PR #58728, the former should too. The `Invoice/Line/AccountID` element in `SourceDocuments/SalesInvoices` and `SourceDocuments/PurchaseInvoices` must match an account defined in `MasterFiles/GeneralLedgerAccounts/Account/AccountID`. As the latter uses `account_code` since PR #65221, the former should too. opw-5427296
Miscellaneous changes
This update incorporates the latest translations from Weblate, ensuring that Odoo Enterprise supports a wider range of languages for our users. These updates improve the localization of key modules across various business areas, enhancing the user experience for international customers and partners. The changes cover multiple payroll and accounting modules.