Steps to reproduce the bug:
- Create three stockable products P1, P2, P3
- Create a BOM for P1 with P2 and P3 as components
- Create a MO with 5 P1
- Check the availability and plan it
- Go on the WO and process only 3 P1
- Go to the MO and update the quantity to 3
Bug:
From this point, it was impossible to pass the MO to the state= 'done'
With this fix, you can now, click on "Post inventory" and the button
"Mark as Done" will appear.
opw:1874227
- Create a BOM for Product P with the following component:
Product C, 5.0 units
- Make some stock for C:
2 units in location 1
3 units in location 2
- Create a MO for P, reserve.
When trying to produce an error arise:
> Cannot set the done quantity from this stock move, work directly with
> the move lines.
If the user tries to unlock the MO in order to set the done quantity on
the move lines, the same error will arise when trying to produce.
In the specific scope of the production, we set the quantity done on the
move line instead of directly on the move, to avoid this limitation.
opw-1871241
Co-authored-by: Arnold Moyaux <arm@odoo.com>
New test :
- Create a MO with a finish product tracked by SN with a dozen as
quantity
- Click on produce button in order to open the produce produce wizard
The quantity to do is 1 dozen although the tracking is by serial number
Task #55494.
This commit makes several improvement in the 'Produce' wizard on Manufacturing Orders
such as :
1) In produce wizard, all components will be visible. (Regardless of tracking)
2) Quantity done will be equal to expected consumption.
3) Produce wizard line data filled from an onchange on final product
4) Reserved column is added to 'produce' wizard
5) When production order is done, we hide the column 'reserved'
6) In produce wizard, if consuming products are not available or in too small quantity,
the lines is displayed red
Task #55494.
The precision digit on the produce lines is not set to the product unit
of measure one. That can lead to a lost of precision when a small values
are set in the manufacturing order and not in the produce wizard.
OPW-1838077
When moves of a MO are generated, they are rounded up to the decimal
precision of the rounding, what is not done in the wizard.
So to keep it consistent, we also round up the quantity to consume in
the wizard.
Purpose
=======
Compute cost of product(s) based on it's BoM
Specification
=============
real_time: not with FIFO otherwise open the
wizard with the bom price as default new value
periodic: directly set the cost on the form view
Add a server action in order to directly set the price
on selected product.
When getting price from a bom with a sub-bom it will take the
cost of the sub bom except if the sub-bom is set with the bom
itself in the server action (in this case the sub bom cost will
be used).
Capacity is not used for this functionality
task-39561
Moves UoM models, test and data to a new addon in
order to be able to use uom without product.
A simple example is be to be able to use UoM for
timesheets.
This commit only move code, and adapt xml ids
without chaging any feature or functionnal
behavior.
Note: 'product' module now depends on new
'uom' module.
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 updating the quantity of an MO, the qty we are producing on a work
order should possibly be updated. When the finished product is tracked
by serial number it should be 1.0 when some quantity is still to be
treated. (and not 0 as before)
opw-785190
Usacase to reproduce:
- Plan MO with 2 unit to produce.
- Produce 1 unit
- Update the quantity to 1
-> Traceback
active_move_lot_ids should have been changed to
active_move_line_ids during the forward port to 11.0
from this commit d62b307597
add missing string labels
rephrase the error message
add missing _description
removed forward-ported hr_equipment.pot
was unclear, courtesy of the translators
You start with an MO with a quantity of 2 with routing and we
produce just 1. At least one of the components is tracked by lots.
When we update the MO to a quantity of 1 again, the temporary
stock.move.lots continued to exist which led to processing a the consume
d move of e.g. 1 piece with 2 pieces of the quants processed when
posting inventory.
A test is added in order to avoid this case
opw-767526 and opw-772786
Update MO qty compute the quantity already processed
but it includes the by_product moves.
This commit add a filter in order to only consider the
move with the final product.
When producing a finished product with a lot, also the raw materials
without lot tracking should split the move lines to at least know the
quantities consumed for every lot produced. This way, the traceability
report will not confuse the user.
Use case to reproduce:
- Create a product with a BOM needing one component tracked by SN
- Create a MO for this product with 2 to produce
- Produce 1
- Produce the other -> 2 lines and a wrong lot proposed
This happens when the quantity to consume is equal to 0
or if the qty_done on a move_line is equal to the reserved
quantity.
This commit change the condition after the float_compare in
order to take into account the equal comparison.
Before, in case of non-tracked components, when everything foreseen had
already been consumed, it would not add the theoretical quantity on
producing through the produce wizard. This makes little sense as the
behaviour of the wizard is not the same anymore for all cases and this
can only confuse the user.
Make it possible to add an extra line in the produce wizard. This was
done for when we consume more than foreseen to be able to still add e.g.
the serial number.
When processing moves with 0 initial demand,
it will set the initial demand = qty_done. Also, when updating the quantity of
an MO, don't take into account those with 0 quantity.
This implements a warning when the user tries to do any of the
following operations on a product that is not in stock:
- Scrapping
- Unbuilding
- Repairing
The warning displays the current stock of the product in question per
location which can be helpful in case the user selected the wrong
location.
When you open the produce wizard, see all the move lines for a product
to consume with a serial number, we should only see the ones that have
not been already process.
When you are processing a MO or WO, you can set two times the same serial
number for the same product.
To avoid this behavior, we created a onchange on the stock move line to
warn the user when he enter two times the same SN. We also create a
constraint on stock move line to avoid having two times same SN in a
picking.
The production wizard raised a traceback when you were trying to consume
product tracked by lot without reservation.
To fix this issue and some potential others, we have removed the
move lines from the wizard and create produce lines that are used on
validation to create the move lines.
This also let us show the 'To Consume' quantity of a lot instead of the
reserved quantity which has no sense when there is no reservation.
When updating the quantity to produce on a MO, the quantity done
on finished/consumed moves that were not done was erased.
It happens due to write on stock move that always wanted to
unreserve the move and thus drop the move lines with qty_done.
This issue has been resolve in previous commit
This commit correct some mistakes in wizard methods in order
to correctly update open moves.
Christophe Simonis