Daily updates from Odoo
Thursday, February 5, 2026
8 changes · 17.0
Enhancements to existing features
This update optimizes how the General Ledger export process is handled, leading to faster report generation. By batching more data, the system reduces the time it takes to create these reports, improving efficiency for users. This change focuses on internal performance improvements.
This update enhances the accuracy of financial reports by addressing discrepancies caused by partial analytic item distributions. It introduces a 'coverage ratio' for each analytic plan, allowing users to easily identify and resolve incomplete distributions during audits, leading to more reliable financial insights.
Original PR description
The objective is to bridge the gap between journal items and analytic items in the reporting. As Odoo allows for partial analytic distribution, this creates discrepancies in the P&L and BS when filtered by an analytic plan. This features aims to provide users with a clear 'coverage ratio' per plan to identify incomplete distributions during audits. task-5887978
Resolved issues and error corrections
This update fixes a bug that caused invoices sent to Peppol to be incorrectly marked as ‘skipped’ upon repeated resends. The change prevents users from resending invoices already in a ‘processing’ or ‘skipped’ state, ensuring accurate Peppol integration and avoiding potential delays in invoice delivery. This improves the reliability of our Peppol transactions.
Original PR description
This fix addresses two issues related to resending invoices via Peppol. It prevents users from accidentally resending an invoice and having its status incorrectly set to “skipped”. It also prevents from resending an invoice via Peppol when it is already in a “processing”, then "skipped" state. Steps to reproduce: - Create and send a customer invoice to Peppol - Try to send it again, Odoo sets the status to “skipped” - Try to send it again, Odoo resends the invoice via Peppol This fix is a light adaptation of the `_is_applicable_to_move` method introduced in version 18. After the fix: Trying to resend to Peppol an invoice already in "processing" or "done" state is prevented. opw-5491341
This update fixes an issue where the Stock Forecasted report incorrectly displayed stock quantities after a repair order was deleted. The fix ensures that related stock moves are properly cancelled when a draft repair order is removed, providing accurate stock reporting for repair operations. This improves the reliability of inventory tracking within the repair process.
Original PR description
**Steps to reproduce:** * Install the *repair* module. * Create a *storable product* and set some **On Hand** quantity. * Go to *Repairs* and create a new **Repair Order**. Keep the repair order in…
**Steps to reproduce:** * Install the *repair* module. * Create a *storable product* and set some **On Hand** quantity. * Go to *Repairs* and create a new **Repair Order**. Keep the repair order in *draft* state (do not confirm). * In the **Parts** tab, add the storable product with the operation type set to *Add*. * Open the **Stock Forecasted** report for the added product. Note the quantity shown under *Outgoing Draft Transfer*. * Delete the **Repair Order**. * Open the **Stock Forecasted** report for the same product again. **Observed behavior:** * The quantity still appears in the **Stock Forecasted** report under *Outgoing Draft Transfer* even after the repair order is deleted. **Cause:** * Deleting a draft repair order triggers `_unlink_except_confirmed`. * This method prevents related stock moves from changing their state to cancel when the repair order is deleted. * The *Outgoing Draft Transfer* value is calculated as the sum of quantities of stock moves in draft state at draft state. https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/addons/stock/report/stock_forecasted.py#L49 https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/addons/stock/report/stock_forecasted.py#L90 * As a result, deleting a draft repair order leaves related stock moves in draft state, causing them to appear under *Outgoing Draft Transfer* https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/repair/models/repair.py#L332-L335 **Fix:** * Ensure that related stock moves are properly cancelled when a draft repair order is deleted. --- opw-5449323
This update replaces a real tax ID placeholder in the Odoo Base VAT module for Turkey. This change prevents users from accidentally using the placeholder for actual transactions, ensuring data integrity and compliance. It’s a minor update focused on security and accuracy.
Original PR description
The previous placeholder used a real tax ID. Replacing it with a dummy prevents users from using it to submit transactions. task-5441218 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242189
This update resolves an issue where customer display URLs weren't consistently being sent to IoT devices when records were updated. The change ensures that the correct URL is transmitted upon record saving, improving data synchronization between the system and the IoT devices. This addresses a technical bug impacting device functionality.
Original PR description
This PR fixes the customer display url not being sent to the iot box when updating the corresponding record in iot device form view. By replacing onWillSaveRecord by onRecordSaved we ensure that our method is always called ticket-5782927
This update corrects a misleading error message displayed when validating Argentine VAT invoices. The message has been changed to accurately reflect the issue: that the invoice date cannot be before the last validated invoice in AFIP. This ensures accurate invoice processing and compliance with Argentine regulations.
Original PR description
WSFE error 10016-1 must be "The invoice date cannot be before the last invoice validated in AFIP." instead of "The invoice date cannot be after the last invoice validated in AFIP". Steps to reproduce: validate argentinean customer electronic invoice with invoice date before than the last invoice date validated in ARCA. Task Adhoc side: 44290 Task latam: 1376
This update resolves an issue where invoice exports were failing when invoices included a section or note line as the first item. The fix filters out these lines during currency rate calculations, preventing a division-by-zero error and ensuring invoices can be correctly sent and downloaded. This improves the reliability of invoice export processes.
Original PR description
Before this commit: Steps 1) Create an invoice with a section or note line as the first line 2) Try to send or download the invoice => A traceback error is raised with the message: File "/home/odoo/src/enterprise/17.0/l10n_cl_edi_exports/models/account_move.py", line 68, in _get_inverse_currency_rate return float_round(abs(self.line_ids[0].balance / self.line_ids[0].amount_currency), 2) ZeroDivisionError: float division by zero This occurs because the `_get_inverse_currency_rate()` method is dividing over self.line_ids[0].amount_currency which is always equal to 0 in case of section or note line is added as a first line in the invoice. After this commit: Filtering out section and note lines in _get_inverse_currency_rate() to correctly calculation the inverse currency rate opw-5488417