Set a BOM to create 10^k units of Product P, using n units of raw material R.
On R, put rounding to 1 unit.
Create a MO to produce 1 unit of P.
Since it needs n/10^k units and rounding is set to 1,
it sets 1 unit of R to consume.
Now "update" (quantity to produce) to 10^k'.
It correctly updates the quantity to consume.
However, since it doesn't update the unit_factor, when you "produce",
it will consume 10^k' units instead of 1.
We copy the way the unit_factor is initially computed when updating the lines.
opw 1903776
closesodoo/odoo#29067
- Create the following BOM structure:
```
Prod 1 (Manufacture)
|
--- Prod 2
Prod 3 (Kit)
|
--- Prod 4
Prod 5
```
- The BOMs for Prod 1 & 3 must have a routing set, to generate
workorders
- Create a MO for 1 unit of Prod 1, process to the end
2 units of Prod 1 are created instead of 1.
This is due to the WO for Prod 3 not having a `next_work_order_id`.
Therefore, `record_production` adds an extra quantity at:
```
production_move.quantity_done += self.qty_producing
```
To prevent this, we set as `next_work_order_id` of the BOM of Prod 3 the
WO of Prod 1.
Closes#19527
opw-1817398
opw-1883693
- Create 2 Products A and B, tracked by serial number
- Create a BOM for A:
1 Unit of B
- Create a MO for 2 Units of A
- Validate:
Product with S/N A1 consumes B1
Product with S/N A2 consumes B2
- Unbuild A2
If A1 was created before A2, B1 will used as a component of A2 at
unbuild.
When going through the stock move lines, we don't verify that the lot
produced matches the lot we unbuild.
opw-1889002
closesodoo/odoo#28154
Producing a manufacturing order on components with more than one unit
could leads to multiple move line reserved on this component. Marking the
workorder as done, in that case, will trigger an error saying "Cannot set
the done quantity from this stock move, work directly with the move
lines". Instead of setting the quantity done directly, this commit
uses the magical function _set_quantity_done() that manage the case
of more than one move lines.
OPW-1888780
closesodoo/odoo#27773
Swiping a credit card through pos_mercury no longer worked on the
payment screen.
3a74afd21e introduced some special code
in BarcodeEvents for mobile Chrome. This code relies on an invisible
input being filled in by barcode device. On the payment screen the POS
uses a keypress event handler on body to manage input. This handler
preventsDefault which stops the input from being filled in.
It's worth noting that this new approach in
3a74afd21e is not fully equivalent to
the original barcode events handler. Events are not redispatched, so
this effectively disables keyboard input on the payment screen (or
anywhere where it is used).
opw-1888466
closesodoo/odoo#27820
Producing a manufacturing order on components with more than one unit
could leads to multiple move line reserved on this component. Marking the
workorder as done, in that case, will trigger an error saying "Cannot set
the done quantity from this stock move, work directly with the move
lines". Instead of setting the quantity done directly, this commit
uses the magical function _set_quantity_done() that manage the case
of more than one move lines.
OPW-1888780
closesodoo/odoo#27773
Steps to reproduce the bug:
- Create 3 stockable products P1, P2, P3
- P1 is tracked by serial numbers
- Create a BOM for P3 with one P1 and one P2 as components
- Set the quantity on hand to 5 for P1 and P2
- Create a MO for P3, produce it and mark the MO as done
- On the MO in the sheet "Consumed product", the quantity_done for
P1 and P2 are equal to 1.0
- Change the tracking of P1 to "No tracking"
Bug:
- Check the sheet "Consumed product" on the MO and the quantity_done
was equal to 0.0 instead of 1.0
opw:1856340
Before this fix, we can create a Bom with both product_id and
product_tmpl_id filled where the product_id is not a variant of the
product_tmpl_id. This is unlogical and will be even trickier when the
user is not able to see the variant field on the BOM.
This fix puts the product_id back to False when the product_tmpl_id
is changed.
Steps to reproduce the bug:
- Create a stockable product P tracked by serial number with route BUY
- Create PO with 5 P and validate the PO
- On the picking, just set one serial number and create a backorder
- Go on the backorder
Bug:
8 lines were created:
- 4 lines with one reserved quantity
- 4 lines with no reserved quantity
Now only 4 lines with one reserved quantity are created.
opw:1847714
Steps to reproduce the bug:
- Create two products P1 and P2 requiring a lot
- Create a BOM B for P1 and requiring 3 P2
- Set on B a routing with a work order
- Create an inventory adjustment with 2 lots for P2:
- Lot1 with 20 P2
- Lot2 with 10 P1
- Create a MO for 10 P1
- Start the production and create a current lot Lot3 in Current Production sheet
- Set as current Qty 5 with Lot3 as current lot and Lot1 as Product Lot
- Click on DONE
- Set as current Qty 2 with Lot3 as current lot and Lot1 as Product Lot
- Click on DONE
- Set as current Qty 3 with Lot3 as current lot and Lot2 as Product Lot
- Click on Done
Bug:
When you checked the produced qty on the MO in the Finished product sheet, it only displayed 5 instead of 10.
opw:1849796
- Create the following BOM structure:
```
Prod 1 (Manufacture)
|
--- Prod 2
Prod 3 (Kit)
|
--- Prod 4
Prod 5
```
- The BOMs for Prod 1 & 3 must have a routing set, to generate
workorders
- Create a MO for 1 unit of Prod 1, process to the end
2 units of Prod 1 are created instead of 1.
This is due to the WO for Prod 3 not having a `next_work_order_id`.
Therefore, `record_production` adds an extra quantity at:
```
production_move.quantity_done += self.qty_producing
```
To prevent this, we set as `next_work_order_id` of the BOM of Prod 3 the
WO of Prod 1.
Closes#19527
opw-1817398
* [FIX] mrp: negative workorder issues
- In the onchange of the qty_producing in the wo,
we need to add the date to the stock.move.line as
it is a required field.
- When starting a workorder, check first if it has
not already been done.
The field quantity_done_store had the same label as the field product_uom_qty
on model "stock.move" and there were confusions in the pivot view of
"stock.move".
opw:1841097
Use case to reproduce:
- Create a BOM with a byproduct tracked and a routing
- Mark the last workorder as done
- by products move line are not created
With the wizard produce (MO without routing) move lines
are created. Thus there is an inconsistency.
It happpens because workorders and produce button do not use
the same function. commit 1a09bcc622
already fix it for production wizard however it forgets workorders
process.
opw-1838707
Do not try to keep the reservation when creating a backorder for two
reasons:
1) it doesn't make sense since the backordered move will only be
confirmed while it got some reserved move lines
2) with badly configured uom's rounding, it is possible that the
initial demand of the backorder is inferior to the now reserved
quantity
We also fix another "cannot unreserve more than available" cause that
could happen in the second case ; let's imagine in the second case that
the backordered quantity is 0.999, `_update_reserved_qty` will reserve
0.999 on the quants but do not create a move line as range (0, 0.999)
will not return anything.
We remove `test_split_1` as it tested a behavior we removed and add a
new test showing a new flow with what we fixed.
Please note that setting the rounding of unit to 1.0 would have
prevented all the issues here.
- 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
len-odoo