Tuesday, April 14, 2026
13 changes · 18.0
Resolved issues and error corrections
This update resolves a bug where EPD (Early Payment Discount) bill payments weren't correctly updating their status. The fix ensures that payments are accurately marked as 'paid' after reconciliation, preventing delays in financial reporting. This improves the reliability of our accounting processes.
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'. opw-5881976 Backport of https://github.com/odoo/enterprise/commit/3dc53e00600c9030fc5e85f2e0ca448fa135e9b1
This update resolves a bug that caused the Odoo Planning app to crash when users were operating with a timezone set to Beirut - Lebanon. The change ensures the column count is always an integer, preventing errors during object initialization and improving overall stability.
Original PR description
**Before this commit** `this.columnCount` could be a floating point number if the user's computer timezone is set to Beirut - Lebanon. This causes issues when we try to use this value as the integer constructor for an Array. **After this commit** We round the column count to the nearest integer to avoid crashes when initializing objects that rely on integer arguments. Ex) If you try to open the Planning app while your computer's timezone is set to Beirut - Lebanon, Odoo will crash on the frontend. opw-6083320
This update resolves a crash issue that occurred when confirming rental orders with kit products using multiple pick locations. The change uses a safer method to handle multiple pick transfers, preventing a 'singleton error' and ensuring rental orders can be processed correctly. This improves the reliability of our rental product functionality.
Original PR description
Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries…
Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries to assign both picks as the `return_id` because they share the same `sale.order.line` here: https://github.com/odoo/enterprise/blob/2212b3f3f3d90894dd6351defe0d3ca090584955/sale_stock_renting/models/sale_order_line.py#L404
Purpose: Use [:1] to safely handle the case where multiple pick transfers are created, avoiding a crash when assigning return_id which expects a single record.
Steps to Reproduce on Runbot:
1. Enable mutli-step routes and rental transfers.
2. Set the warehouse to 3-step delivery.
3. Copy the existing packing location.
4. Copy the existing pick operation type and set the destination location to the new packing location.
5. Create a new route.
6. Create new rules on this new route with the following configurations:
1. Rule 1
1. Action: Pull
2. Source location: WH/Stock
3. Destination location: Partners/Customers
4. Operation type: The new pick operation type
2. Rule 2
1. Action: Push
2. Source location: New pack location
3. Destination location: WH/Output
4. Operation type: Pack
3. Rule 3
1. Action: Push
2. Source location: WH/Output
3. Destination location: Partners/Customers
4. Operation type: Delivery
7. Create 2 component products tracked by inventory, and apply the new route on one of the component products.
8. Create a new rental product with a kit, which has the 2 component products.
9. Create a new rental order for the kit product and confirm it.
opw-6026918This update resolves a display issue where XML documents received via email were incorrectly showing up as a split iframe preview. The fix ensures that the PDF preview is correctly displayed, addressing a problem caused by how the system interpreted the document type. This improvement enhances the user experience when working with documents attached via email.
Original PR description
**Steps to reproduce:** - Install documents_account - Set up alias to catch incoming mails - Receive a mail with xml attachement which can be previewed as pdf - Go to Documents app - Click on the…
**Steps to reproduce:** - Install documents_account - Set up alias to catch incoming mails - Receive a mail with xml attachement which can be previewed as pdf - Go to Documents app - Click on the document preview - Preview is split in two iframes, both with the same content (pdf) **Issue:** Due to the `isPdf` patch the attachment can match multiple types for the preview (pdf and text) as both getter return `true`. ``` <iframe t-if="state.file.isPdf" ... <iframe t-if="state.file.isText" ... ``` It also seems that xml received by mail are imported as text, which is why the issue doesn't happen when manually uploading the same xml file. **Fix:** Ensure that if the document is matching `isPdf`, it doesn't trigger the second iframe with `isText`. Also it seems fixed in 19.0 as the text iframe is replaced by this xpath: `<xpath expr="//iframe[@t-if='state.file.isText']" position="replace">` which was added for https://github.com/odoo/enterprise/commit/de614ee5e9a087d49939c65c0118ae6164c7b31b related patch: https://github.com/odoo/enterprise/commit/ffcdd2275c8bf564e15151ccbcaf3965ed968450 opw-6018536
This update corrects a mismatch in transaction identifiers used when generating financial reports (FAIA export) for Luxembourg. Previously, the system used different methods for identifying invoices, leading to potential reporting errors. This change ensures all invoice data is consistently linked, improving the accuracy of financial reports and compliance.
Original PR description
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 odoo#58728, the former should too. opw-5427296 [link](https://www.odoo.com/odoo/unassigned-tasks/5427296)
This update corrects a flaw in how Odoo calculates available booking slots when integrating with Google Reserve. The previous system incorrectly reserved the full party size for each resource, leading to inaccurate capacity displays. The fix ensures that Odoo accurately determines and reserves the appropriate number of slots for each booking, improving the scheduling process.
Original PR description
The current logic inside the appointment google reserve controller to compute reserved and used capacity per resource was incorrect. It was reserving the full party size for each resource instead of properly computing how much spots we are reserving for each. The code was fixed and a test was adapted for proper coverage. Task-6120016
This update resolves an issue where the checkout process became unresponsive when using the Brazilian Avatax tax calculation. The previous implementation unnecessarily called external tax APIs, leading to errors that prevented users from completing their purchases. This fix removes the unnecessary API call, restoring the checkout functionality.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/enterprise#112515
This update fixes an issue where payments weren't automatically updating to 'paid' status after bills were fully reconciled, particularly when early payment discounts were involved. The change ensures payments accurately reflect the status of associated bills, preventing delays in financial reporting and improving payment tracking accuracy.
Original PR description
Currently, payments may remain in the 'in_process' state even when the associated vendor bills are fully paid. This occurs primarily when using early payment discounts (EPD) and journals without…
Currently, payments may remain in the 'in_process' state even when the associated vendor bills are fully paid. This occurs primarily when using early payment discounts (EPD) and journals without outstanding accounts. 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'. Analysis: The issue occurs because the reconciliation process misses the trigger to set the payment state to 'paid'. Specifically: - The payment amount does not match the bill total due to the EPD. - The payment compute method does not monitor 'reconciled_bill_ids', causing it to ignore the status of linked vendor bills. This change adds 'reconciled_bill_ids' to the compute dependencies and ensures that if a payment is reconciled with any moves (invoices or bills), their payment_state is considered to determine the final state of the payment. opw-5881976 Backport of https://github.com/odoo/odoo/commit/4d84b961cdabd283e1acef6b487b2648bc543a5a
This update fixes a technical issue preventing the correct calculation of the REAGYP deductible amount for Spanish farmers filing their SII tax returns. The update ensures that the compensation amount (ImporteCompensacionREAGYP) is now included in the total deductible quota, ensuring accurate reporting to the Spanish tax authority (AEAT).
Original PR description
Currently, the deducible amount for REAGYP is not passing through to the AEAT. This happens because the REAGYP compensation amount (ImporteCompensacionREAGYP) was missing from the total deductible quota calculation in the SII JSON payload. To fix this, we add 'sujeto_agricultura' to the list that cheks if the tax value for l10n_es is in the list task-6072773 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256586
This update resolves an issue where the checkout process became unresponsive when using the l10n_br_avatax_sale module with the Express Checkout feature. The previous implementation was causing unnecessary external API calls, leading to errors and preventing users from completing their purchases. This fix removes the problematic call and ensures a smoother checkout experience.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/odoo#256692
This update resolves a problem where Odoo invoices sent via Peppol were being rejected due to an incorrect calculation of the taxable amount. The fix ensures that the tax calculation is consistently applied across all tax categories, addressing a specific Peppol compliance requirement. This prevents invoice rejections and ensures smooth international transactions.
Original PR description
Steps to reproduce: 1. Create an invoice with a 0% tax (Exempt from VAT, category E) 2. Add two lines with 20% discount and fractional prices: - qty=4, price_unit=39.615 and qty=4 with…
Steps to reproduce: 1. Create an invoice with a 0% tax (Exempt from VAT, category E) 2. Add two lines with 20% discount and fractional prices: - qty=4, price_unit=39.615 and qty=4 with price_unit=0.84 3. Send via Peppol 4. Peppol rejects with: [BR-E-08] VAT category taxable amount shall equal the sum of Invoice line net amounts The TaxableAmount recalculation in _ubl_get_tax_subtotal_node was only applied for tax category 'S' (Standard Rate). However, Peppol schematron has identical rules for all tax categories: BR-E-08 (Exempt), BR-Z-08 (Zero), BR-AE-08 (Reverse Charge), etc. When lines have discounts and fractional prices, the individually rounded LineExtensionAmount values can sum to a different total than the tax base_amount. This affects both rounding modes. For 'S' taxes this was already handled, but for 'E' (and others) it caused Peppol rejection. Remove the 'S'-only filter and match dynamically against the actual tax category code so the recalculation applies universally. opw-6093243
This update resolves an issue where managers without specific Time Off Officer permissions couldn't approve leave requests displayed in the Gantt view. The fix adjusts permission logic to allow designated leave managers to approve, validate, and refuse requests, streamlining the approval process for managers while maintaining existing security controls.
Original PR description
### Issue before this commit: A manager without the Time Off Officer access rights was unable to approve, validate, or refuse a leave request from the Time Off Gantt. Attempting to perform these…
### Issue before this commit: A manager without the Time Off Officer access rights was unable to approve, validate, or refuse a leave request from the Time Off Gantt. Attempting to perform these actions raised an access error on the leave_id field of the hr.leave.report.calendar model. ### Steps to reproduce the issue: 1. In employee app create a manager, go to settings tab and create also a user for the manager as Related User 2. Create also an employee setting in the Work Information tab the manager as Time Off 3. Go to Users and for the manager deselect rights for Time Off and Payroll 4. Set a contract for the created employee and allocate some Paid days to him 5. Create a Time Off request for the employee. 6. Switch to manager account 7. Go to Time Off -> Overview -> Gantt View and try to approve the request. 8. Error: _You do not have enough rights to access the fields "leave_id" on Time Off Calendar (hr.leave.report.calendar). Please contact your system administrator._ ### Cause of the issue: The action_approve, action_validate, and action_refuse methods on the hr.leave.report.calendar model relied on accessing the leave_id field, which is restricted to users belonging to the hr_holidays.group_hr_holidays_user group. As a result, managers without this group could not read the field, triggering an AccessError even though they were legitimately allowed to approve leaves as managers. Backporting this PR: https://github.com/odoo/odoo/pull/207675 ### Reason to introduce the fix: Allow managers to perform leave approval, validation, and refusal actions without granting them broader Time Off access rights. This fix extends the permission logic to ensure that the employee’s designated leave manager can execute these actions when the validation type allows it, while preserving the standard access restrictions for other users. opw-6023628 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where stock quantities were incorrectly displayed for one company when a purchase order was processed across multiple companies. Now, stock quantities are correctly restricted based on the product's assigned company, preventing errors and ensuring accurate reporting for each company's inventory. This improves data consistency and reliability.
Original PR description
**Purpose:** Since a stock.quant is a combination of the stock move lines of a product and a location, it should be restricted by the product's company. **Before this commit:** In a multi-company…
**Purpose:** Since a stock.quant is a combination of the stock move lines of a product and a location, it should be restricted by the product's company. **Before this commit:** In a multi-company environment. If a purchase order with product from company 1 is being confirmed, received, and validated when company 2 is being selected as the primary active company while company 1 is also checked. It will create a stock.quant that is searchable for company 2. However, it will raise an error when company 2 is trying to access it. **After this commit:** Even if the stock.quant is created when company 2 is the primary active company, it will not be searchable for company 2 since the product's company is company 1. **Steps to Reproduce on Runbot:** - Create a storable product exclusive to Company A - Create & validate a receipt for that product in Company A. - Switch to Company B -> Reporting > Locations > Remove all filters: The negative quant for the product in Partners/Vendors is visible. opw-6082330 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257211