- 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
- Create 2 companies A & B
- Create a product P with 2 phantom BOMs:
Component C1 for company A, with sequence = 10
Component C2 for company B, with sequence = 0
- Create a SO in company A for P, validate
The picking contains C2, while one would expect C1 since C2 is only for
company B.
opw-807640
We added a constraint in [1] to improve the usability of introducing
tracked move lines in the system. However, this contraint proved to be
too costly (trigger multiple time during the validation process, never
called in batch as it is set on the model at the end of a o2m).
We replaces the constraint by checks on the validating process or by
(non-blocking) onchanges.
With these changes, validating the receipt of 3000 tracked move lines
goes from 17 minutes to around 4.
[1] 482407464a
opw-803887
When the user unbuild a product with a MO specified
the system will generate the inverse moves from the BOM.
However the BOM could have change.
This commit instead use the MO specified in order to
generate the inverse moves.
Add decimal precision to quantitites in stock.production.lots.
Otherwise, if the UoM uses a DP larger than 2, inconsistencies may arise
since the field is automatically rounded to 2 decimals in the interface.
For example, if the DP of the UoM is 4:
- Set Qty Done to 1.234567
- Save => qty recorded in DB is 1.234567
- Edit, change nothing and save => qty recorded in DB is 1.23
This happens since the web client parses the value in the DOM and
detects a value change.
opw-788078
- Define a Component A tracked by lot.
- Define a Final Product B tracked by lot.
- Create a BOM, e.g. 5 units of A to produce B.
- Get some quantity of A in a sub-location, e.g. 'WH/Stock/Shelf 1'.
- Create a MO for 1 unit of B.
- When clicking on 'Produce', record 6 units consumed instead of 5.
- Post the inventory
5 units of A is removed from 'WH/Stock/Shelf 1' and 1 unit of A is
removed from 'WH/Stock'. The latter might create a negative quant if no
stock is available in 'WH/Stock'.
When the extra move line is created, it is created using the data of the
stock move (in `_generate_consumed_move_line`). When posting the
inventory, the quants selection is made strictly in the location set (in
`_update_available_quantity`), which might cause the mentioned negative
quant.
The solution is to select a sub-location where the product can be found.
This gives a higher chance to avoid negative quants afterwards. Note
that if we wanted to avoid negative quants, we could make a reservation
process on the move, and potentially create several stock move lines.
This is beyond the scope of the integration of MRP with sub-locations.
opw-803969
Before this commit, the special mrp validate_move method did a call to
quants_move with an incomplete signature. IN the use case, that we want
to make "own" produced quantities by a third party (maquila), we can do so in
downstream modules by restrict the partner on the move so that any moved (or
created) quants will belong to this partner (owner). This is certainly
important for the case where finished products are not your own
property. Courtesy of blaggacao.
Closes#21072
When copying a done MO that is unlocked, the new MO is also unlocked and
the buttons to produce/check availability aren't displayed and it is
confusing to the user.
Fixes#20119
Optional bom line havea default `product_qty` of 0. As the "check
availability" button is displayed if the MO is not available and
the `_compute_availability` method considers all move of 0 `product_qty`
as unassiged, the "check availability" button was always displayed and
it was confusing.
Do not consider move with a 0 product_qty in the `_compute_availability`
method to fix the display of the button.
Usecase to reproduce:
- Set a product with the same lot in different locations
- Create a MO that will uses theses products and that require more than one location
- Produce it.
-> Traceback Expected singleton: stock.move.line
It happens because product produce only expect one move line
by lot. Howeever it could exist more than one move line if the
product for a specific lot are shared among multiple under location.
This commit try to fill the move line with the correct quantity
one by one and add the extra in a new move line.
Use case to reproduce:
- Create a MO with a product tracked and a qty to produce greater than 1.
- The Bom should also use a routing with at least 2 operations.
- On the first workorder only produce 1 unit and record the production
- Go to the next workorder -> The final lot is not set.
It happens because the lot for the next workorder is only set if the
total quanity for the mo was produced.
This commit fixes the bug by removing the code for the workorder lot
assignation outside the wrong condition. This commit also update the
test test_00b_workorder_process that allows us to find the above bug.
When creating by products during a workorder the move lines
for the final moves are not created and the user has to manually
create them on the manufacturing order view.
This commit adds an automatic action in order to create
the correct move lines with the consumed quantity for the
by products not tracked by lot or SN.
This commit also fixes a bug where the consumed move lines where
not linked to the by products move lines
When the user do a work order with a final product
tracked by lot or serial number. A serial number is
asked at the end of the first workorder. The purpose is
to link consumed products with the SN/lot produced.
However it could happens that no component are consumed
during the first and following work order.
This commit allows to by pass the lot/SN registration if
nothing is consumed.
Use case to reproduce:
- Create a BOM with a component product tracked by SN
- Create a MO for this product and reserve it.
- Plan WO and process it.
- Register the same lot than the reserved one.
-> Error message: you can't use twice the same serial number
It happens because WO use temporary move line that should not
be considered as a real object. However it exists is a constraint
that trigger if two move lines share the same SN for the same product.
It's a wanted behavior that a real move line share the same SN that
temporary move lines.
This commit prevent real and false move lines comparaison.
Rev [1] was intended to be applied when changing the lot of the produced
product on the manufacturing order, somewhere along the line the code
was also called when setting the lot_id on the work order. When used in
this context, it broke the reconciliation between the reserved move
lines and the temporary move lines because a lot_produced_id was wrongly
set.
We fix the issue by only applying the code on prod move. This is done by
checking if the move is a production one through the stock move, because
there we are able to differenciate the raw material and production move,
not on the move line where production_id is always set.
[1] 471115b06aFixes#20964
When confirming a move for a kit, it is basically unlinked and replaced
by moves for its component. The link to the purchase line was kept in
v10, but since rev[1] it is not anymore. Make an helper to get the
values and override it in purchase_mrp to add the purchase line link.
[1] https://github.com/odoo/odoo/commit/8248f0e153ae5fcc1449d0d05149b61df615ad4f
opw 779497
Christophe Simonis