Tuesday, April 14, 2026
6 changes · 17.0
Resolved issues and error corrections
This update fixes an error in how Odoo calculates depreciation for assets with shortened fiscal years. Previously, entries were skipped during certain months, leading to inaccurate depreciation reporting. The fix ensures that depreciation calculations align with the correct fiscal year boundaries, improving financial accuracy.
Original PR description
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next…
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely. Step to reproduce: - Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025) - Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method - Compute the board and observe that entries from January to April 2026 are missing Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal. opw-6016834
This update fixes a security issue where unauthorized users could access asset information within invoices. The change restricts access to the `account.asset` model to users within specific accounting groups, preventing accidental or malicious data access. This ensures data integrity and protects financial records.
Original PR description
Only groups `account.group_account_readonly`, `account.group_account_invoice` or higher have access to model `account.asset`, therefore if an user goes to see an invoice with assets and they are not on either group, they will receive an error and won't be able to access said invoice. How to reproduce: - Create a vendor bill - Create an account.asset and link it to said account.move - Go to the form view with an user that it's on group "Purchase: User" for example --> They get a traceback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#112890
This update corrects a visual issue in the product expiry module where all products without removal dates were incorrectly highlighted in red. Now, only products with expired lots/serials or quantities below zero will be flagged as expired, ensuring accurate product tracking and inventory management. This resolves a misleading display that could have impacted decision-making.
Original PR description
**Description of the issue/feature this PR addresses:** Install product_expiry and have products in stock with a quantity greater than 0 and not having any serial or lot configuration. **Current behavior before PR:** All lines which have no valid removal_date set (normally just those which are to be subject to be expired) will be marked red. **Desired behavior after PR is merged:** The tree view is showing as intended only if a product lot/serial is expired or a quantity less than zero will be marked red. Info: @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where tax wasn't correctly applied to sales orders when using fixed amount discounts. Previously, users had to manually set tax on discount products. Now, the system automatically considers tax from the discount product, ensuring accurate tax calculations for all discount scenarios.
Original PR description
Steps to reproduce: - Apply fixed amount discount on sales order. - Go to the discount product which got created and set tax for it. - Again apply fixed amount discount on sales order. Issue: If tax is set for fixed amount discount product, tax is not applied when discount is applied on sales order. Cause: User have to manually set the tax even if he has set tax for fixed amount discount. Fix: Consider the tax from discount product if there is any. opw-3935350 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where German hybrid invoices processed through Peppol were failing to correctly identify invoice customizations. The change clarifies how the 'zugferd' format is handled, ensuring it's treated as a distinct format from Peppol EDI, leading to accurate invoice processing.
Original PR description
The 'zugferd' key was missing from the `_get_customization_ids` mapping, causing potential failures when attempting to identify the correct CustomizationID for German hybrid-style invoices being processed through the Peppol exchange. This is because the 'zugferd' format was wrongly considered as peppol edi format, whereas it should behave like the 'facturx' format and be excluded from the peppol edi formats. opw-6009214
This update fixes an issue where stock quantities were incorrectly displayed for a company when a purchase order was processed through another company in a multi-company environment. The change ensures stock quantities are restricted to the product's assigned company, preventing errors and improving data accuracy. This resolves a reporting discrepancy.
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