Odoo Changelog — 2025-05-17

Saturday, May 17, 2025

2 changes · master

Improvements(1)

Enhancements to existing features

[IMP] account_budget: analytic hierarchy widget

Enterprisemasteraccount_budgetMEDIUM

Budget users can now view budgets in a grouped hierarchy with totals and subtotals while editing directly from the main list. This makes budget review and adjustments easier by keeping the financial rollups visible during updates.

Original PR description

Enable the new groupby hierarchy on the budgets:
* new widget in search view
* allow editing the budgets from the main list view to allow having the totals/subtotals in the hierarchy while editing.

#budgets#hierarchy#analytics#editing

Bug Fixes(1)

Resolved issues and error corrections

[FIX] stock: bypass procurement on backorder of mto moves

PR #84616

Enterprisemasterquality_controlquality_mrpMEDIUM

Backorders for make-to-order deliveries no longer trigger an extra procurement that incorrectly increases the related purchase order quantity. This prevents over-ordering when customers receive a partial delivery and the remaining quantity is backordered.

Original PR description

### Steps to reproduce:

- In the settings enable Multi-Step routes
- Unarchive the MTO route
- Create a storable product using the MTO and buy route
- Create and confirm a sale order for 100 units of that product
- Validate the delivery for only 30 units and backorder the rest
#### > The purchase order demand was updated to 170 units

### Cause of the issue:

Since the refactoring a72382063ee662010729d983fbf6fb6305b8adf2 the rule of the MTO route is purely MTO. Furthermore, the moves creating and running a procurement are added depending solely on their procure_method during the `_action_confirm`:
https://github.com/odoo/odoo/blob/1dd360658222c0afeb268a5c8cf435defddf55d1/addons/stock/models/stock_move.py#L1485-L1496 https://github.com/odoo/odoo/blob/1dd360658222c0afeb268a5c8cf435defddf55d1/addons/stock/models/stock_move.py#L1503-L1513
In our use case, the delivery move is therefore created as `mto` and then creates and run a procurments creating the PO during its confirmation. However, when it is backordered, the backorder move is also created and confirmed as `mto` by the `_create_backorder` call:
https://github.com/odoo/odoo/blob/02a370a7a34a42f2bc9f668eee756fb466db8722/addons/stock/models/stock_move.py#L2071-L2075
It will therefore also automatically create and run a procurment that will in turn modify the current PO.

opw-4633920

#stock#backorder#procurement#purchase orders

### Steps to reproduce: - In the settings enable Multi-Step routes - Unarchive the MTO route - Create a storable product using the MTO and buy route - Create and confirm a sale order for 100 units of that product - Validate the delivery for only 30 units and backorder the rest #### > The purchase order demand was updated to 170 units ### Cause of the issue: Since the refactoring a72382063ee662010729d983fbf6fb6305b8adf2 the rule of the MTO route is purely MTO. Furthermore, the moves creating and running a procurement are added depending solely on their procure_method during the `_action_confirm`: https://github.com/odoo/odoo/blob/1dd360658222c0afeb268a5c8cf435defddf55d1/addons/stock/models/stock_move.py#L1485-L1496 https://github.com/odoo/odoo/blob/1dd360658222c0afeb268a5c8cf435defddf55d1/addons/stock/models/stock_move.py#L1503-L1513 In our use case, the delivery move is therefore created as `mto` and then creates and run a procurments creating the PO during its confirmation. However, when it is backordered, the backorder move is also created and confirmed as `mto` by the `_create_backorder` call: https://github.com/odoo/odoo/blob/02a370a7a34a42f2bc9f668eee756fb466db8722/addons/stock/models/stock_move.py#L2071-L2075 It will therefore also automatically create and run a procurment that will in turn modify the current PO. opw-4633920