Simon Lejeune
383947646f
There's a certain configuration of UOM that is not correctly handled in the v11 stock: - create a move with an UOM having an higher factor than the product's UOM - this higher UOM has a rounding of 1.0, meaning it doesn't allow partial reservation - use the product's uom in this move and enter quantities that aren't expressible in the move's uom A practical example is to set the rounding of dozen at 1.0, set the uom of a product to units, create a move for a dozen and create a new move line with 8 units. The first issue is the `quantity_done` field, that uses an half-up rounding on the `qty_done` field of each move line and sum them. When applying this logic to the previous example, `quantity_done` field would be 1.0, meaning we won't make a backorder for the missing 4 units. We fix these issue by summing a non rounded qty_done and afterwards rounding this value to the general products'UOM. This mean `quantity_done` is technically not be expressible in the move's uom, but keeping this value close to the reality will allow to handle the backorders and extra moves correctly. The second issue is that the backorder is always expressed in the move's uom. In the previous example, this would mean creating a backorder of 0 dozen. In v10, an error was throwed, saying this operation is impossible. The `_prepare_move_split_vals` previously always received the quantity of the backordered move in the uom of the original move. This is a remnant of the v10 implementation where, if the quantity to backorder is not expressible in the original move's UOM, an error was throwed. We now pass the used uom via a context key to not update the method signature, as it is probably legitimately overidden by custom modules. This way, in the previous example, a backorder of 4 units is created. The last issue is in `_action_assign`. Let's say you have 8 units in stock and you want to reserve a dozen, the system will reserve 8 units and then convert back 8 units in dozen, meaning a dozen was reserved. This resulted in awkward situation where more items than available were reserved, and the famous "cannot unreserve more than what's available in stock" was throwed at almost each operation. To solve this, we convert the not-yet reserved quantities back and forth in both uom. This prevents partial reservation when not allowed, which is good. We had to adapt some lines of `_action_assgn` that expected `_update_reserved_quantity` always at least partially reserved the move. It is now possible that it doesn't reserve anything. We also normalize the quantity with a greater decimal precision when deciding if we open the immediate transfer wizard or not (in the original exemple, if you enter a single unit the immediate transfer wizard would be openned because 0 was done in the UOM of the dozen). We also prevent to enter `qty_done` on the move line if the value doesn't honour the rounding of the UOM. We introduce two tests, a simple `_action_assign` in MTS and a more complete MTO scenario with backorders, extra moves and invalid qty_done. opw-1835186 opw-1835946
Odoo
Odoo is a suite of web based open source business apps.
The main Odoo Apps include an Open Source CRM, Website Builder, eCommerce, Warehouse Management, Project Management, Billing & Accounting, Point of Sale, Human Resources, Marketing, Manufacturing, Purchase Management, ...
Odoo Apps can be used as stand-alone applications, but they also integrate seamlessly so you get a full-featured Open Source ERP when you install several Apps.
Getting started with Odoo
For a standard installation please follow the Setup instructions from the documentation.
Then follow the developer tutorials