Friday, March 27, 2026
9 changes · saas-18.4
Enhancements to existing features
This update enhances the budget report to now automatically include tracking for asset accounts. Previously, budget reports only covered expense accounts. Now, with 'Expenses' or 'Both' budget types, the report will accurately reflect spending and budget performance across all asset types – current, non-current, and fixed assets.
Original PR description
Expand the scope of budget tracking to include asset accounts. Modified the account filtering logic so that when a budget type is set to "Expenses" or "Both", the query includes 'asset_current', 'asset_non_current', and 'asset_fixed' account types. task-5994048 Forward-Port-Of: odoo/enterprise#109496
Resolved issues and error corrections
This update fixes an issue where the delivered quantity on sale orders wasn't accurately reflecting dropship deliveries between companies. The fix ensures that dropship moves are correctly accounted for in the delivery calculations, resolving a discrepancy where the quantity delivered was incorrectly shown as zero.
Original PR description
**Steps to reproduce:** - Make sure you have 3 companies (comp A, B and C) - Navigate to Settings/Users & Companies/ Companies - for each company in the 'Inter Company Transactions' tab: check…
**Steps to reproduce:** - Make sure you have 3 companies (comp A, B and C) - Navigate to Settings/Users & Companies/ Companies - for each company in the 'Inter Company Transactions' tab: check 'generate Sale Orders', 'generate purchase orders' and 'synchronize Deliveries to your receipts' then select a warehouse and a receipt operation type From company A - create a storable product - in the Purchase tab, set the company B as a vendor From company B - in the Purchase tab of the product, set company C as a vendor From company C - set a positive on hand quantity From Company A - create a SO for 1 quantity of your product - on the sale order line, unhide de route_id column and set it to dropship - confirm the SO and the linked PO From company B - on the SO created with company A as customer (you might need to remove the 'my quotations filter to find it), set the dropship route in the route_id column of the sale order line - confirm the SO and the linked PO From company C - confirm SO created with company B as customer - validate the delivery From company B - validate the dropship **Current behavior:** the quantity delivered on the sale order line is 0 **Expected behavior:** it should be 1 **Cause of the issue:** inside _compute_qty_delivered, we fetch the incoming and outgoing moves using _get_outgoing_incoming_moves() https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L200 There, for the move of the dropship picking, inside the if condition, move._is_dropshipped_returned() will be True https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L348-L354 That's because the move is going from transit to transit https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/stock_account/models/stock_move.py#L186-L195 So it will not be added to the outgoing moves and qty_delivered will stay 0. **fix** is_dropshipped_returned should not prevent the move to be added to the outgoing moves if is_dropshipped() is aslo true (i.e. it's a transit to transit move) opw-5023215 Forward-Port-Of: odoo/enterprise#111835 Forward-Port-Of: odoo/enterprise#111108
This update fixes an issue where quality control failures weren't correctly splitting stock moves, leading to inaccurate demand calculations. The fix ensures that failed quantities are properly distributed across new stock moves, maintaining accurate inventory tracking. This prevents overestimation of available stock and improves the reliability of demand forecasting.
Original PR description
**Steps to reproduce:** * Install the `quality_control` module. * Create a storable product. * Configure a Quality Control Point: * Set Control per : Quantity. * Set Operation Type to Receipts. * Set…
**Steps to reproduce:** * Install the `quality_control` module. * Create a storable product. * Configure a Quality Control Point: * Set Control per : Quantity. * Set Operation Type to Receipts. * Set Product to the created product. * Create a Receipt for the product with a demand of 5 units. * Confirm the receipt and mark it as To Do. * Click on the Quality Check button. * Click on Fail and set the failed quantity to 3. * Click on Confirm. **Observed behavior:** * A new stock move is created for the failed quantity. * The original move is split incorrectly: * First move: 2 `product_uom_qty` and 2 `quantity`. * Second move: 2 `product_uom_qty` and 3 `quantity`. * The failed move has a demand of **2** instead of **3**. **Cause:** * Clicking on *Quality Check* triggers `check_quality`, which opens the wizard `action_open_quality_check_wizard`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/stock_picking.py#L79-L82 * Clicking on *Fail* triggers `do_fail`, opening the confirmation wizard: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L85-L88 * Clicking on *Confirm* triggers `confirm_fail`, which calls `_move_line_to_failure_location`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L97 * In `_move_line_to_failure_location`, a new stock move is created for the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L480 * The demand quantity is computed using the minimum of the failed quantity and the move line quantity. * This leads to an incorrect demand of *2* instead of *3*. * However, the move line quantity was already reduced by the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L472 **Fix:** * Ensure that partial failures properly split stock moves with correct `product_uom_qty` and `quantity` values. --- opw-5492095 Forward-Port-Of: odoo/enterprise#112125 Forward-Port-Of: odoo/enterprise#107493
This update corrects an issue preventing SBR tax reports from submitting due to incorrect date formatting and overly long consultant information. The commit restores the original date format, which is now validated, and simplifies the consultant name to only display the abbreviation. This ensures reports pass validation and can be successfully submitted.
Original PR description
Description of the issue this commit addresses: During the tax return flow for the SBR development[^1], we discovered that the date format for the "DateTimeCreation" node had been wrongly readjusted and that the "ProfessionalAssociationForTaxServiceProvidersName" content could be too long due to showing the entire description. Those two issue cause the file to be rejected and make submission impossible. [^1]: https://www.odoo.com/odoo/967/tasks/6034675 --- Desired behavior after this commit is merged: This commit reintroduces the old DateTimeCreation format which is the only one that passes the tests done on the xbrl validation service[^2] and replaces the ProfessionalAssociationForTaxServiceProvidersName's value for the abreviation of the order instead of the entire description. [^2]: https://aansluiten.procesinfrastructuur.nl/site/validaties-digipoort/xbrl-validatie --- task-none Forward-Port-Of: odoo/enterprise#111923 Forward-Port-Of: odoo/enterprise#111817
This update prevents the automatic creation of rental planning shifts before a rental order is fully confirmed. Previously, changes to order quantities could trigger shift creation even without confirmation. This fix ensures shifts are created only when the rental order is finalized, improving planning accuracy and reducing potential errors.
Original PR description
**Steps to reproduce:**
- Install sale_renting_planning
- Create a product of type Goods with rental enabled
- Create a rental order and set quantity
- Update the quantity before confirming the order
- Check the planning shifts
**Issue:**
planning shifts are created even when the rental order is not confirmed and the quantity is updated.
**Cause:**
while creating shifts, the system does not check:
whether the rental order is confirmed whether planning is enabled on the product
**Fix:**
ensure that planning shifts are created only when:
the rental order is confirmed, and planning is enabled on the productThis update resolves an issue where planning slots were unexpectedly created for rental orders, even when 'Plan Services' was disabled. The fix ensures that slots are only generated when 'Plan Services' is enabled, preventing unnecessary planning entries and improving the accuracy of rental order scheduling. This change impacts the rental planning process.
Original PR description
Steps to reproduce: ------------------- 1. Install `sale_renting_planning`. 2. Create a rental service product with: - "Can be Sold" enabled - "Plan Services" disabled - UoM set to "Units" 3. Create and confirm a rental order with this product. 4. Go to Planning and check for slots related to this order. (no slots at this stage) 5. Update the quantity of the rental order. 6. Check Planning again for slots related to this order. Issue: ------ Planning slots are created after updating the quantity of the sale order, even when "Plan Services" is not enabled. Cause: ------ Slot records are created without checking whether "Plan Services" is enabled, which leads to unwanted planning entries. related commit: 74eef70 Solution: --------- Add a condition to ensure planning slots are created only when "Plan Services" is enabled. opw-6051012
This update fixes an issue where the XML generated for Mexican invoices wasn't correctly incorporating the issued address's zip code. Previously, the zip code was not being populated in the 'LugarExpedicion' field, which is a required data element for Mexican tax compliance. This change ensures accurate invoice data for tax reporting.
Original PR description
**STEP TO REPRODUCE** 1. install l10n_mx_edi_extended. 2. Add an issued address on the customer invoice journal, with a zip code. 3. Create invoices, and create a global invoice with them. 4. download the xml, and notice the field LugarExpedicion is not using the zip from the issued address while it should. opw-5956837 Forward-Port-Of: odoo/enterprise#112107 Forward-Port-Of: odoo/enterprise#108732
This update corrects a payroll calculation issue for Swiss businesses using the Odoo Enterprise system. Specifically, it adds a 200% overtime wage type, aligning with Swiss labor regulations and ensuring accurate payroll processing for employees working overtime. This change improves compliance and reporting accuracy for our Swiss clients.
Original PR description
Forward-Port-Of: odoo/enterprise#110796
This update fixes an issue where rental shifts remained in 'draft' status after confirming a rental order. The fix automatically updates the shift status to 'published' upon order creation, ensuring accurate tracking and consistency with other order actions. This improves the reliability of rental planning workflows.
Original PR description
**Issue 1** **Steps to Reproduce:** Create a shift in Planning. Click New Order. Save and confirm the rental order. Check the shift in Planning it is still in draft. **Issue:** The shift stays in draft even after the rental order is confirmed. **Cause** When creating a rental order from a shift, the shift is not marked as planned. It only gets linked to the order after saving, so it never updates its status. **Fix:** Mark the shift as published when confirming a new rental order. This makes the shift show the correct status right away and keeps it consistent with the “Add to Last Order” button. task-5075839