Steps to reproduce the bug:
- In the Manufacturing App , enable Work Orders and Quality
- Configure your products,BOM and Routing
- Create steps in routing with type='Register Consumed Materials'
Bug:
When you finished your Work Order operations it displayed "False" value in
the "Finished Steps" tab instead of the uom of the finished product.
Technically:
The function "record_production" unlinks the temporary stock.move.line that can
be linked to a quality.check. So the component_uom_id of the quality.check could not
be found when computing the field 'result' on model "quality.check' with function "_compute_result".
opw:1909768
closesodoo/odoo#28865
Usecase to reproduce:
- Install a database with demo date and mrp or purchase
The buy/manufacture rules have a wrong company for warehouses
in company 'My company, Chicago'
It happens because the warehouse is not specify in the create
values. In this case it creates the rules and set the user current
company as default.
This commit specify the company during the create call.
closesodoo/odoo#28682
On the BoM structure report the price on line with a
child BoM is inchoerent. Also the sum of all lines in
the report is not always equals to the total of the parent
line.
For the first issue, it happens due to commit 17b6256955
that use the number of operation cycle as quantity.
The second issue happens because sometimes the rounding is not done
at the smallest level and thus the rounding of the sum is different than
the sum of the rouding.
- 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
This reverts commit d78b6f5e25.
This constraint is considered too harsh. It was applied to circumvent
inconsistencies when a bom is modified while being used in a
manufacturing order and the user chose to update the quantity to
produce. The current code will look at the existing move if no
intermaddite post of inventory was done else look at the new bom.
A code to re-construct the original BoM from the stock moves isn't easy
to write to handle all cases, one particularly complicated is the
deletion of bom lines of the same product.
We also considered to block the update qty button if the bom is modified
after the create date of the MO, but if we have to read all the bom
lines of all the sub bom in a computed field it may be slow on large
databases.
We thus chose to remove the constraint and think of a better approach in
a future version.
task 1891407
closesodoo/odoo#28155
Usecase to reproduce
- Enable multi locations, multi routes
- Check mrp 3 steps on warehouse
- Create a MO
Raw moves are duplicated. It happens due to commit aeb038747f
The purpose of the commit was to split the rules from SAM to stock.
The pull rule should be in manufacture route and the push rule on the
warehouse. However the push rule was not correctly copied and created a
push rule from prod to sam instead of sam to stock.
Fixes#27962closesodoo/odoo#27965
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
Usecase to reproduce:
- Create a BoM that create more than 1 finished product
- Use a routing
- Open the BoM structure report
The operations time from the routing are multiplied by the quantity show
on the report.
It should not happen since routing's operations are not by unit.
If a user create a BoM that produce 50 finished products then the
operation time is always the same when the user produce between 1-50
units. It then double from 51-100,... (workorder use the same process
for the expected duration).
This commit fix this behavior by using a rounding up on the
quantity asked on the report / BoM product quantity.
It also take care of the workcenter capacity.
opw-1890005
Christophe Simonis