Daily updates from Odoo
Wednesday, May 6, 2026
13 changes · 18.0
Enhancements to existing features
This update enhances the VAT reporting feature in Odoo Enterprise by accurately reflecting the total turnover for each VAT number, even when individual partner turnovers are below a threshold. Previously, partners with low individual turnover but a high total VAT number were excluded from the report. Now, the report includes all partners associated with a VAT number if the total turnover for that number exceeds the defined threshold, providing a more complete and accurate VAT listing.
Original PR description
When having different partners with the same vat number and their individual turnover values are less than the threshold they were not included in the partner vat listing report even though if the total turnover for their vat number is above the threshold. This commit handles this case by grouping by vat number and if the total turnover for a vat number is above the threshold then it will be shown in the report with another level beneath it to show the partners having this vat number even if their individual turnovers are below the threshold. task-6133010
Resolved issues and error corrections
This update resolves a problem that prevented UBL invoices from importing correctly in Odoo 18. Previously, the system didn't always ensure the unit of measure (UoM) used for an invoice line matched the product's default UoM, leading to import errors. This fix guarantees UoM compatibility, ensuring smooth and accurate UBL invoice imports.
Original PR description
When importing an account.move from an UBL file, we try to match the unitCode with a default UoM from the database: https://github.com/odoo/odoo/blob/c6f0ca15da7ded91062d0c395c9fabfdb1136531/addons/account_edi_ubl_cii/models/account_edi_ubl.py#L2913 In version 18, the UoM selected for a account.move.line needs to be from the same category as the product's default UoM. This is currently not verified to select the line's UoM, it will raise a UserError and interrupt the process. opw-6173558 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where incorrect tax exemption data was being generated for UBL invoices, preventing compliance with Peppol standards. The change ensures accurate tax exemption information is included, resolving a potential validation error and improving the system's ability to process international invoices.
Original PR description
A tax exemption reason code that does not pass the peppol validation was added in the xml generation in this task-id-5905176 task-id-none Forward-Port-Of: odoo/odoo#262810
This update fixes an issue where CodaBox statements were incorrectly routed to the wrong bank journal due to differing currency settings. The system now prioritizes journals with explicit currency IDs, ensuring statements are accurately assigned to the correct currency-specific account. This prevents financial discrepancies and improves the reliability of CodaBox data integration.
Original PR description
When several journals share the same IBAN but use different currencies, a CODA could land on the wrong journal instead of the currency-specific one. Split the lookup in two passes: first a journal with an explicit currency_id matching the CODA, then fall back to the no-currency journal (qualified by the company currency). Steps to reproduce: - Create 2 bank journals sharing the same IBAN; one without currency and one with USD. - Setup CodaBox connection and retrieve USD statements. - Before this fix: may land on the EUR journal. opw-6048931 Forward-Port-Of: odoo/enterprise#114590
This update fixes an issue where the Master Production Schedule (MPS) displayed dates in UTC, potentially showing dates for tomorrow instead of today. The fix ensures MPS dates are displayed correctly based on the user's configured timezone, allowing users to accurately plan and manage production schedules. This improves usability and reduces potential errors.
Original PR description
# How to reproduce - Set your timezone to one that is very behind UTC (e.g. Etc/GMT-14) - Go to the MPS page - Use the day filter # The problem The first date displayed is in UTC, so it may be tomorrow if you go to the MPS page early in the morning, preventing the user to edit the MPS line for today. # Cause `_date_range_to_str` does not account for timezone. opw-6032156
This update corrects a bug preventing invoices from correctly reflecting free FSM services linked to prepaid invoicing. Previously, the system incorrectly set invoice quantities to zero for these services. Now, prepaid FSM services will appear on invoices as expected, ensuring accurate billing for these services.
Original PR description
Changed _compute_qty_to_invoice in industry_fsm_sale, SaleOrderLine to no longer set qty_to_invoice to 0 for free services with prepaid invoicing. Previous changes seem intended for goods. Steps to reproduce: - Create service product with 0 price, prepaid invoice policy, creates FSM task - Create/Confirm sales order with created product - Attempt to create invoice, get 0 quantity to invoice error Current Behavior: Free services linked to FSM tasks do not appear on invoices due to compute 0 qty_to_invoice Expected Behavior: Prepaid Invoice Services linked to FSM tasks appear on invoices. Other invoice policies can be invoiced through the generated sales order lines (timesheets, delivered quantity, etc.) opw-6047992 Forward-Port-Of: odoo/enterprise#113718
This update fixes an issue where product unit prices in sales quotes were not being rounded to two decimal places, leading to inaccurate pricing calculations. The change ensures that unit prices are correctly rounded, aligning with expected business practices and improving quote accuracy. This resolves a reported bug impacting sales quote generation.
Original PR description
### Steps to reproduce: - Download 'Sales' app - Create a product with a sale price of : 208.05 - Create a pricelist with discount rule on the sales price : -35% - Create a new quotation that has the new pricelist and product > The unit price has 4 decimal instead of 2, only the unit price column is affected. ### Cause of Issue: When you add a product to a quotation (or change the price list and click "Update Prices"), `_reset_price_unit()` is called, which calls `_get_tax_included_unit_price_from_price()` https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/sale/models/sale_order_line.py#L592-L606 In `_get_tax_included_unit_price_from_price()`, the first 2 if blocks just return the `product_price_unit` without any rounding https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/account/models/product.py#L275-L280 opw-6185661
This update ensures that failed Stripe terminal payments are properly flagged in the POS system. Previously, a successful authorization could lead to incorrect payment status updates, masking payment issues. Now, the system correctly identifies and displays payment failures, improving accuracy and preventing revenue loss.
Original PR description
Before this commit, a Stripe terminal payment could still be marked as `done` even if the capture step failed.
This happens when the card authorization succeeds, `processPayment` returns a payment intent, but the subsequent `stripe_capture_payment` RPC fails and `capturePaymentStripe()` returns `false`. The capture flow did not guard that return value and still fell through to `line.set_payment_status("done")`.
In practice, this can happen for example if the Odoo server cannot resolve `api.stripe.com` while capturing the payment intent. Stripe then keeps the payment in `requires_capture`, while the POS line is still synced as paid.
Guard the failed capture path and stop the flow before marking the line as done. In that case, the payment line is put back to `retry` so the failure is visible in the POS instead of silently creating a paid, uncaptured payment.
opw-6075384
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where Odoo was generating incorrect CFDI XML files for invoices using the 'add_invoice_line' cash rounding strategy. The fix ensures that pre-rounding amounts are correctly reported according to Mexican tax regulations (SAT), preventing XML rejection errors. This improves compliance and accuracy of financial reporting.
Original PR description
When using the 'add_invoice_line' cash rounding strategy, Odoo adds a journal line with display_type='rounding'. This line has no product and therefore no ClaveProdServ, causing PAC to reject the XML with error 301. Per SAT regulations, cash rounding is not a valid CFDI concept. The CFDI must report the pre-rounding amounts (e.g. 99.80); the rounding difference (e.g. 0.20) belongs only in the journal entry on the accounting side. opw-6024078
This update resolves an issue where commission plans with negative targets caused a system error. The fix ensures the commission calculation logic handles negative values correctly by applying absolute values within the calculation, preventing a 'Maximum call stack size exceeded' error. This improves the stability and usability of commission plan creation.
Original PR description
Steps to reproduce: ------------------- 1. Install sale_commission 2. Create a commission plan based on targets 3. Try to add a new commission level with negative targets Issue: ------ Adding a commission level with a negative target results in a ```python RangeError: Maximum call stack size exceeded. ``` Cause: ------ https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/sale_commission/static/src/js/commission_plan_graph/commission_plan_graph.js#L50-L56 Negative target values caused infinite recursion in the GCD function, leading to this `RangeError`. Solution: ----------- Since the Euclidean algorithm only works correctly with non-negative integers, apply Math.abs() on both inputs before the recursion starts. This ensures negative targets are handled gracefully without causing infinite recursion. **NOTE:** Backport: c0d748f opw-6182644
This update fixes an issue where payment accounts were incorrectly swapped for outbound payments in the Point of Sale system. The fix ensures that journal entries accurately reflect inbound and outbound payments, debiting the correct accounts and preventing financial discrepancies. This improves the accuracy of financial reporting related to sales transactions.
Original PR description
Step to reproduce: - we need a session, where in total, we gave out money (when we refund) - for this, start a pos session, do a order, pay using bank and close session - restart the pos, refund the order, and pay using bank, close it. - go to accounting > customer > payment - open payment for both session Observation: - in journal entries for both payment, amount is credit into `account_receivable` and debit from `outstanding account` Cause: - commit[1] swaps accounts when we have outbound payments, which is functionally incorrect and lead to this issue. [1] https://github.com/odoo/odoo/commit/844d2960af6b2cdd8620eb1681bda03dd48a97e4 Fix: - do not swap accounts between `outstanding` and `destination` accounts. Expected after fix: - Inbound and outbound payments use the same accounts - Journal entries are correct: - Inbound: debit outstanding, credit account_receivable - Outbound: reverse of inbound entries opw-6044883
This update fixes a bug preventing returns for dropshipped orders within the Helpdesk module. Previously, returns were limited to outgoing customer orders. Now, the 'Returns' button is visible for dropshipped transfers, allowing users to manage returns directly from the Helpdesk ticket, streamlining the returns process for dropshipping customers.
Original PR description
### Steps to Reproduce: - Enable dropshipping in Inventory settings - Create a product with inventory tracking enabled - Enable dropship under the Inventory tab for the product - Add a vendor and…
### Steps to Reproduce: - Enable dropshipping in Inventory settings - Create a product with inventory tracking enabled - Enable dropship under the Inventory tab for the product - Add a vendor and quantity under the Purchase tab - Create a sale order for the product - Go to the Purchase stat button and confirm the order - Click on the Dropship stat button and validate the transfer - Open Helpdesk and create a new ticket for the same partner ### Issue: The "Returns" stat button is not visible for dropshipped deliveries. ### Current behaviour: - The helpdesk ticket allows returns of customer orders only if the order is outgoing. However, this does not cover the usecase where the order was dropshipped and still needs to be returned to the vendor. - With the current behavior, the user needs to find the customer's order to return the transfer as it is not possible to do from the ticket. ### Expected behaviour: Helpdesk tickets should also allow returns of dropshipped transfers (done and linked to the SO). ### Fix: The helpdesk return logic was limited to only 'outgoing' pickings. This commit extends the 'return' button should be visible if there is at least one delivery or dropship order linked to the partner of the ticket Issue:https://github.com/odoo/enterprise/pull/81378 task-4881338
This update ensures Odoo's Dutch reporting modules (SBR, ICP, and Status Info) correctly submit data to the new Digipoort infrastructure, which is migrating to digipoort.logius.nl by May 1, 2026. This change is critical to avoid submission failures and maintain compliance with Dutch regulations.
Original PR description
*: l10n_nl_reports_sbr{,_icp,_status_info}
---
Description of the issue this commit addresses:
The Dutch Digipoort endpoint infrastructure is being migrated from procesinfrastructuur.nl to digipoort.logius.nl effective May 1, 2026. Odoo's SBR modules need to use the new endpoints or submissions will fail.
---
Desired behavior after this commit is merged:
This commit updates all Digipoort endpoint URLs (delivery and status services) from the old domain to the new logius.nl domain, and clarifies that valid PKIoverheid certificates are required for both environments. Reports now submit to the new Digipoort infrastructure correctly.
---
task-6171403
Forward-Port-Of: odoo/enterprise#115668