Before, when we consumed 3 instead of 1 in a production order, it
gave a traceback. It was because it created moves
with negative quantities. So, something was wrong with
the quantity_done/product_uom_qty set when creating the extra moves
When creating an extra move because of the procurement,
but you still need to split afterwards (e.g. procurement 10, production order 12, you do 11),
then you should have a difference between quantity_done and product_uom_qty
in the extra move and not try to change it on the original.
That way, we make sure we pass the correct quantities.
Other modules that was overriding old name method was just ignored.
Drop retro compatibility fixes in next freeze (saas-14) and stop
useless renaming.
This commit closes#13865
In previous versions, the quantity passed to the bom_explode was the number
of times you needed to count the BoM. If the BoM was for 2 dozens and you pass
48 units, 2 was passed to the bom_explode method. We are now doing the same
for the explode method and we check it is called this way everywhere.
When you produce or consume more than foreseen in a production order,
the system creates extra moves. Before, in case of tracking, it did this without
transferring the stock.move.lots resulting in a wrong stock. That is why now,
when we split moves, we also split the stock.move.lots
For the finished move, it is also important to split between the quantities
of the original procurement and what is extra as the extra might use a push rule e.g.
When updating quantity, it should take use a similar
method as for generating the moves, but with
the quantity already produced (and posted) deduced.
The parameters for these method needed to be changed.
When all the moves are posted,
we should create the necessary extra moves.
If the quantity is put back to the quantity posted, it
might also need to delete moves.
In byproduct, it should take into account the subproduct factor.
When the quantity produced on the work orders has reached the quantity to do,
it should not allow anymore to use the "Done" button on work orders, but
rather use the Finish button instead. With the Update button on the manufacturing order
it is possible to do more.
The default of the date_start on the time records was a
result of the function fields.Datetime.now instead of the function itself
resulting in the start of each blocking time as the start of the server
When changing the quantity being produced on a work order and
serial numbers are consumed, we need to delete or add lines
for every serial number in function of the quantity through the onchange.
We changed the quantity_done to be set to quantity by default (automatically)
as otherwise we forgot to set it. But for the onchange, it means
we need to take it into account otherwise the number of records
would not be diminished.
The labels of the fields say that they store hours, but actually they store minutes. Correct the code to store hours.
Add digits to fload field for a better display in the webclient
date_planned_start should also be Start Deadline instead of Expected Start Date.
We don't want the Expected dates to function as a planning tool, but as
a priority for the planning of the workorders.
When consuming products tracked by unique serial number, no check is
done on the quantity consumed for a given serial number. It means that
negative quants might be created without any warning to the user.
We implement a simple warning thanks to a onchange.
opw-687129
As you open the lots in a raw material move in a production order,
you should not see the temporary stock move lots from the work order.
Also the quantity_done should not take into account those. They will
when they press 'Done' on the workorder.
When posting inventory, the temporary stock move lots on the workorder,
should be transferred to the split move.
For splitting and unreserving, some optimizations are done.
When the routing of the phantom bom is the same as the parent BoM,
the phantom BoM should not recreate the work orders, but use the same
work orders as the parent BoM. That way, you can create one master
routing and the "consumed in operation" of the phantom bom can be used
linking to the master routing.
If the phantom bom has no routing or the same, it can also use
the "consumed in operation" of his parent bom line if none is defined.
When (re)generating the stock.move.lots in the workorder,
it should use the unit_factor on the move like everywhere else.
This makes sure we do well with the explosion of phantom boms too.
It is also important that if there is no operation_id given
explicitly in the "consumed in operation" on the bom line,
that it still generates the necessary stock.move.lots in the last work order.
Also, in the work order it is better to set the quantities done already.
That way we don't forget to consume them.
Josse Colpaert