Thursday, April 30, 2026
7 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue where invoices rejected by the Italian tax system (SdI) remained marked as 'sent' in Odoo, preventing users from resubmitting them. The change automatically clears the 'is_move_sent' flag when an invoice is rejected, allowing for correct resubmission and streamlining the invoicing process. This ensures Italian businesses can quickly correct errors and avoid delays.
Original PR description
When an invoice is rejected by the SdI or by a PA partner, the move remained flagged as sent, preventing the user from resending it after fixing the underlying issue. Override write() on account.move to clear is_move_sent whenever l10n_it_edi_state transitions to 'rejected' or 'rejected_by_pa_partner', so the invoice can be re-submitted. task-4490454 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#260591
This update resolves an issue where Spanish invoices with amounts below a certain threshold were incorrectly appearing in the Mod347 BOE export. The fix eliminates a redundant search process, ensuring that only relevant partners are included based on the primary data requirements. This improves the accuracy of the BOE export for Spanish businesses.
Original PR description
Fix a bug in mod347 BOE export. Steps to reproduce: 1- Create an invoice with a spain Company, with an amount lower than 3 005,06€ 2- Add a Type for mod347 3- Create a cash payment 4- Export the mod347 BOE The partner will appear in the BOE with all line at 0. But this partner shouldn't be in the export. This is due because of a search on account.partial.reconcile, which add partners to the export if a cash payment is found in the period. But this search is not usefully as there is no legal indication that these partners should be in the export in this case, as the partners should only be returned by the main queries. Backport of PR #84317 opw-5960226 Forward-Port-Of: odoo/enterprise#114672 Forward-Port-Of: odoo/enterprise#110947
This update fixes an issue where quantities were incorrectly doubled when settling POS sales orders using the 'Pick then Deliver' warehouse method. The fix ensures accurate lot quantity tracking by filtering move lines correctly, preventing double-counting of inventory. This improves the reliability of sales order fulfillment.
Original PR description
When settling a sale order in POS after validating the delivery, quantities and lots were wrong for lot-tracked products with warehouse "Pick then Deliver (2 steps)": quantity doubled when loading…
When settling a sale order in POS after validating the delivery, quantities and lots were wrong for lot-tracked products with warehouse "Pick then Deliver (2 steps)": quantity doubled when loading SN/Lots. Steps to reproduce: ------------------- * Create a product with Tracking by lots * In Inventory, set warehouse Outgoing Shipments to "Pick then Deliver (2 steps)" * Create a quotation with the product and confirm it * Validate the delivery * In POS, settle the sale order from Quotation/Order * When asked "Do you want to load the SN/Lots linked to the Sales Order?", click Yes > Observation: Quantity doubled. Why the fix: ------------ read_converted() used move_line_ids from all moves linked to the sale line. With 2-step, both pick and delivery moves have move_line_ids with the same lots, so quantities were counted twice. We now use move lines from exactly one picking and filter by sale_line_id. opw-6001585 Forward-Port-Of: odoo/odoo#261729 Forward-Port-Of: odoo/odoo#253539
This update optimizes the process of preparing data for workcenter visualizations, resulting in significantly faster performance. By streamlining the check for workorders and pre-calculating resource calendar durations, the system now responds much quicker, especially with large datasets. This improves overall system responsiveness.
Original PR description
Before this commit, calling the method `_prepare_graph_data` with a recordset of workcenters, would traverse the recordset and then check if all the workcenters has at least one workorder by fetching…
Before this commit, calling the method `_prepare_graph_data` with a recordset of workcenters, would traverse the recordset and then check if all the workcenters has at least one workorder by fetching the field `order_ids` for all the workcenters. This can be too slow in cases where the workcenters have a lot of workorders and in addition to that there is no need to do this repeatedly for every workcenter. In this commit, I have modified the check by invoking a `search_count` on the workorders before iterating over the recordset and in addition to that I have pre-computed the sum of the duration hours of the attendances related to a `resource_calendar` as multiple workcenters might have the same `resource_calendar` The benchmark done below, was on a database that contained 78 workcenters. | Workorders | Before | After | | :--- | :--- | :--- | | 1380828 | 12s | 0.16s | | 138082 | 1.21s | 0.14s | | 13808 | 0.21s | 0.09s | opw-6040077 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256812
This update fixes a slow performance issue that occurred when searching for stock quantities with a large number of items. The change ensures that Odoo respects the specified limit during these searches, dramatically reducing the time it takes to retrieve data. This improves the responsiveness of key features like picking and barcode operations.
Original PR description
## Problem: During an `onchange` call, if a field is defined in the `fields_spec` with a `limit` attribute, the `fetch` method doesn't respect it, and will fetch all records satisfying the domain. In certain circumstances, this leads to slow requests. ## Solution: Enforce the `limit` when fetching if it is present. ## Steps to reproduce: - Have a product with many quant records 1. Open a picking for this product in Barcode 2. Change the lot/serial The frontend will send an `onchange` request that includes `product_stock_quant_ids` in the `fields_spec` (with default `limit` 40). Odoo will fetch all quants for this product regardless of the limit, and the request will take a while to resolve. ## Benchmark: <table> <thead> <tr> <th># of quants</th> <th>Before</th> <th>After</th> </tr> </thead> <tbody> <tr> <td>17193</td> <td>~9s</td> <td>~400ms</td> </tr> </tbody> </table> opw-6041705 Forward-Port-Of: odoo/odoo#259983
This update fixes an issue where invoices in multi-company branches weren't correctly calculating prices with taxes included. Previously, the unit price didn't adjust to exclude the original tax. This change ensures accurate pricing and tax calculations when using fiscal positions across different company branches.
Original PR description
When operating in a multi-company branch environment, the unit price of a product with price-included taxes is not correctly recalculated when applying a fiscal position. Steps to reproduce: - Create a tax that is included in the price (e.g., 10% incl). - Assign this tax to a product (e.g., Product A). - Create a fiscal position that maps this 10% tax to a different tax. - Create a branch (child company) of your main company. - Create an invoice in the new branch using the fiscal position and add an invoice line for Product A. Issue: The unit price of the product on the invoice line remains the full tax-included amount rather than being reduced to exclude the original 10% tax. opw-5931302 Forward-Port-Of: odoo/odoo#260840 Forward-Port-Of: odoo/odoo#256897
This update resolves an issue where the 'PayableRoundingAmount' was incorrectly calculated as a cash rounding. The fix creates the invoice first and then applies post-fix adjustments to the untaxed amount, aligning with standard tax rounding methods. This ensures accurate invoice processing and reporting related to UBL and CII standards.
Original PR description
PayableRoundingAmount is not necessarily a cash rounding. It might also be the difference between the untaxed amount per line regarding the global untaxed amount due to the global tax rounding method. The idea in this commit is to create the invoice first and then, just like the code fixing the taxes, to post fix the untaxed amount after. opw-6151984 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260992