Saturday, April 18, 2026
11 changes · saas-19.2
Enhancements to existing features
This update simplifies the creation of Spanish tax reports (303 and 347) for users. Specifically, the 'exonerated from 390' field is now automatically displayed on the print wizard for recent periods, eliminating a manual step. Additionally, the annual report 347 now groups data by move type and date for enhanced audit capabilities.
Original PR description
In this PR: - In tax report 303, the 'exonerated from 390' boolean field is now visible on the print BOE wizard , when period is either last month or last quarter so that user does not have to enable it manually on the AEAT page. - In the annual tax report 347, when a user clicks to audit the operations of the entity, a new group by is added in context to group the reports by move type and date(quarter). task-5863744 Forward-Port-Of: odoo/enterprise#113948 Forward-Port-Of: odoo/enterprise#108057
Resolved issues and error corrections
This update corrects a discrepancy in the Belgian payroll templates by adding a 'Dimona' category. This ensures accurate reporting and compliance with local tax regulations for employees categorized as 'Dimona' within the Odoo Enterprise system. The change improves the accuracy of payroll calculations and reporting for this specific employee group.
This update resolves a crash that occurred when confirming rental orders with kit products containing multiple components in different pack locations. The fix uses a safer method to handle multiple pick transfers, preventing the system from attempting to assign a single return ID to conflicting picks. This ensures rental orders with kits can be processed correctly.
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-6026918
Forward-Port-Of: odoo/enterprise#114020
Forward-Port-Of: odoo/enterprise#112543This update fixes a reporting issue on the Swiss Balance Sheet by changing the date range used for calculating 'Current Year Retained Earnings'. Previously, the report used a broad date range, which resulted in inaccurate figures. This change ensures the report reflects the correct retained earnings for the current fiscal year, aligning with Swiss accounting standards.
Original PR description
The "Current Year Retained Earnings" (CH_299_A) line on the Swiss Balance Sheet was using the default `strict_range` date scope. This commit forces the `date_scope` to `from_fiscalyear`. task-6119493 Forward-Port-Of: odoo/enterprise#113920
This update corrects a problem where electronic invoices generated with units of measure containing special characters (like m² or m³) failed validation. The fix ensures that these units are properly formatted before being included in the XML, guaranteeing compliance with Italian tax regulations and preventing invoice rejection.
Original PR description
### Issue before this commit: When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails…
### Issue before this commit: When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails validation, as these characters are not accepted by the SdI format. ### Steps to reproduce the issue: 1. Download Italian loc + electronic invoicing 2. Activate UoM option in settings 3. Set a product UoM in any unit that has an apex/power of (ex. m2, m3) 4. Invoice this product 5. Create the XML for SdI 6. Check format with Fex > apex is not recognised as a valid character ### Cause of the issue: The UoM name is exported as-is into the XML. Non-standard Unicode characters are preserved during formatting and are not compatible with the allowed character set defined by the FatturaPA specifications. ### Reason to introduce the fix: Ensure that units of measure are normalized into a compatible representation before being included in the XML, so that the generated file complies with SdI validation rules. opw-6075119 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259076 Forward-Port-Of: odoo/odoo#257012
This update fixes an issue where stock quantities were incorrectly visible for one company in a multi-company environment. Previously, a purchase order would create a stock.quant record searchable for the wrong company, causing access errors. Now, stock quantities are correctly restricted by the product's assigned company, ensuring accurate reporting and data access.
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#259733 Forward-Port-Of: odoo/odoo#257211
This update fixes an issue where the delivered quantity for kit products with dropshipped components was incorrectly calculated. The fix ensures accurate delivery tracking by addressing a flaw in how the system determines delivered quantities based on dropshipping routes. This improves the accuracy of order fulfillment and reporting for kit products.
Original PR description
### Steps to reproduce: - In the settings Dropshipping - Put you warehouse in 2 steps delivery - Create a kit product with 2 components: COMP1, COMP2 - Set a vendor on COMP2 and the dropship route -…
### Steps to reproduce: - In the settings Dropshipping - Put you warehouse in 2 steps delivery - Create a kit product with 2 components: COMP1, COMP2 - Set a vendor on COMP2 and the dropship route - Create and confirm an SO for 1 unit of your kit - Validate the ship and pick for COMP1 - Confirm the PO for COMP2 and validate the associated dropship #### > The qty_delivered on the sol is still at 0 ### Cause of the issue: The `delivered_qty` is computed via the `_prepare_qty_delivered`: https://github.com/odoo/odoo/blob/9b9ff3ddcba6f0c9d37d08fb4fb900bed3b396a4/addons/sale/models/sale_order_line.py#L887-L902 However, since at least on of the component is dropshipped, the qty_delivered is computed by this condition: https://github.com/odoo/odoo/blob/9b9ff3ddcba6f0c9d37d08fb4fb900bed3b396a4/addons/sale_mrp/models/sale_order_line.py#L54-L63 Which is 0 since the pick `location_dest_id.usage` is not `customer`. ### Additional issue: The delivered quantity of a Kit with at least one dropshipped component can only be 0 or the full demand. - In the settings enable Dropshipping - Create a kit product with 2 components: COMP1, COMP2 - Set a vendor on COMP2 and the dropship route - Create and confirm an SO for 3 unit of your kit - Validate the delivery for COMP1 for 2 units and backorder - Confirm the PO for COMP2 and validate the associated dropship for 1 unit and do not backorder #### > The qty_delivered on the sol is 0 instead of 1 - Cancel the backorder for COMP1 ### > The qty_delivered on the sol is 3 instead of 1 ### Cause of the issue: This is caused by the exact same dropship computation: https://github.com/odoo/odoo/blob/9b9ff3ddcba6f0c9d37d08fb4fb900bed3b396a4/addons/sale_mrp/models/sale_order_line.py#L63-L66 ### Note: The behavior should be consistent if the components are fully dropshipped or MTO buy and as such they should not be considered to be in all or nothing shipping policy. opw-6040640 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258739 Forward-Port-Of: odoo/odoo#257617
This update addresses a potential issue where Odoo could create related fields that rely on non-searchable data, leading to errors in searching, reporting, and overall system stability. By adding validation, this fix ensures related fields always use stored data, improving data consistency and preventing unexpected behavior.
Original PR description
**Steps to Reproduce:** - Create a new database. - Install any module (for example, Sale). - Go to Settings → Technical → Database Structure → Fields. - Create a new field using Studio or manually. -…
**Steps to Reproduce:**
- Create a new database.
- Install any module (for example, Sale).
- Go to Settings → Technical → Database Structure → Fields.
- Create a new field using Studio or manually.
- Set the field as a related field using a path that includes a non-stored field (e.g., product_variant_id.active where product_variant_id is non-stored). Save the field.
**Issue:**
- Odoo allows defining related fields that depend on non-stored (non-searchable) fields in the dependency chain.
- This leads to runtime issues such as:
- Cannot convert field to SQL because it is not stored
- Failures in search, domains, and reporting
- Inconsistent behavior depending on usage context
- Currently, no validation prevents users from configuring such invalid related fields.
**Solution:**
- Add validation in the related field resolution logic to ensure that all fields In the related path are stored.
- Raise a ValidationError when a non-stored field is encountered in the related path, clearly indicating the offending field and model.
This prevents invalid related field configurations at creation time and ensures data consistency and predictable behavior across ORM operations.
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#259309This update fixes an issue where the Invoice Journal field wouldn't display when a user changed the invoice's company and only one suitable journal was available. Now, users can correctly update the journal selection, preventing the 'Invoice belongs to company...' error and ensuring accurate financial record updates.
Original PR description
…e_journal_ids and it differs from the current journal_id This resolves an issue that occurs when a user changes the invoice’s company and only one suitable_journal_ids is available. In such cases,…
…e_journal_ids and it differs from the current journal_id This resolves an issue that occurs when a user changes the invoice’s company and only one suitable_journal_ids is available. In such cases, the journal_id is not displayed, preventing the user from updating it. As a result, the following error appears: "Invoice belongs to company 'A' while 'Journal' (journal_id: 'Journal of Another Company') belongs to another company." Description of the issue/feature this PR addresses: The Invoice Journal is not displayed when the Invoice’s Company is changed, preventing the user from updating it. This leads to the error: "Invoice belongs to company 'A' while 'Journal' (journal_id: 'Journal of Another Company') belongs to another company." Current behavior before PR: When there is only one suitable Journal for the Invoice after changing the Company, the Journal field is hidden, even if the current Journal value does not match the suitable one. This prevents the user from updating the Journal. Desired behavior after PR is merged: When there is only one suitable Journal for the Invoice after changing the Company, the Journal field should be displayed if it differs from the only suitable Journal, allowing the user to update it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259573
This update ensures that portal users with edit access to projects receive task notifications that redirect them directly to the editable project sharing view, rather than the standard read-only portal page. This improves the user experience and allows editors to quickly access and modify project settings when notified via email.
Original PR description
Before this commit, the action link sent in task email notifications to portal users always redirected to the standard, read-only portal view, even if the user had edit rights to the project via Project Sharing. This commit ensures that: - If a portal user has access to the task and the project has Project Sharing enabled for them, the action URL redirects directly to the editable project sharing view instead of the static portal page. task-5221400 Forward-Port-Of: odoo/odoo#251439
This update fixes a bug where users could create serial numbers for components on the shopfloor, even when serial number creation was disabled in manufacturing settings. This prevented incorrect tracking of materials and ensured data integrity within the MRP system. The change ensures that the system correctly enforces the defined rules for serial number creation.
Original PR description
**Issue**: Even when creation of new Serial Numbers for components is disabled on the Manufacturing Operation Type, it is still possible to create them from the shopfloor application. **Steps to…
**Issue**: Even when creation of new Serial Numbers for components is disabled on the Manufacturing Operation Type, it is still possible to create them from the shopfloor application. **Steps to reproduce**: - Enable "Lots & Serial Numbers", on the global settings - Create two products, one tracked by unique serial number - Go to Inventory > Configuration > Warehouse Management > Operations Types - Select Manufacturing and disable "Create New Lots/Serial Numbers for Components" - Create and confirm a MO using the tracked product as component - Go to shopfloor - Click the "+" button next to the component, then "New" -> No error is raised when creating a serial number **Cause**: The `_check_create` constraint relies on `active_mo_id`: https://github.com/odoo/odoo/blob/494cdcfdf4ec166e0a643ee70a53c12c810d02b4/addons/mrp/models/stock_lot.py#L11-L19 However, the shopfloor does not pass this, in context: https://github.com/odoo/enterprise/blob/54c6252a0e13b11fc297b6828883923c0f89881a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L193-L199 As a result, the check is bypassed. opw-6041241 Forward-Port-Of: odoo/enterprise#111408