- Create a MO for Product A with quantity to produce of 2
- Produce 1
- Open the associated BOM, and add a line to the bom
- Go back to the MO and try to update the qty to produce to 1
Traceback: division by 0
opw-1838006
When producing a byproduct in a BoM, the quantity for the byproduct was
increased by twice its produced quantity.
This is essentially a revert of commit d7fdb636b8
which was erroneously forward-ported to 11.0,
where byproducts were already correctly counted.
opw:1834226
Use case to reproduce:
- Create a picking containing 2 moves that have a quantity_done greater than reserved quantity
- Validate the picking with or without backorder
Traceback due to a record that do not exist anymore.
It happens due to 2 functionality that have a wrong behavior when used together:
- merge_move function that will try to merge moves with same characteristics inside a same picking.
- action_done functionality that will create an extra move if the quantity done for a move is greater
than reserved quantity. (the extra move is used in order to propagate changes)
With our usecase:
- MOVE A, reserved_qty: 10, qty_done: 20
- MOVE B, reserved_qty: 10, qty_done: 15
action_done on move A will create a new move thus we will have
- MOVE A, reserved_qty: 10, qty_done: 20
- A bis, reserved_qty: 10, qty_done: 0
- MOVE B, reserved_qty: 10, qty_done: 15
then merge move will not only merge move A and A bis but will also merge B
which result with inconsenstencies and traceback since system will try to
process move B after A
- MOVE A,A',B reserved_qty:30, qty_done:35 (the 5 extra qty is not propagated)
This commit adds a kwarg in action_confirm that is propagated to merge_move
this kwargs is a record set taht will limit the moves that can be used for the merge
in order to merge extra move in original move
opw-1825264
- Create a Product A with attribute color and attribute values white and
black.
- Create 3 products (Components 1, 2 and 3)
- Create a BOM for A like:
Component 1, Variant column is empty
Component 2, Variant white
Component 3, Variant black
- Go to Inventory > Master Data > Product Variants, and open one of the
2 variants of Product A
The BOM count is zero, while it should be 1.
The current implementation of `bom_count` doesn't take into account
attributes that can be set on the BOM line.
opw-1814973
When changing the routing on a bom, "Consumed in Operation" indicated
in some lines of the BoM did not correspond to the routing used.
So the system did not link it to a workorder and it was never consumed when
a MO was processed.
Now the "Consumed in operation" are reset when the routing is changed.
opw:807560
Christophe Simonis