When you procure a kit, it doesn't matter what the route configuration
is on the product itself but on its children, so it is not needed to
check anything else but the BoM to assign the 'phantom' supply
method.
Also do not assign a BoM when the supply method is not phantom or manufacture.
_should_create_planned_order hook was unnoticely removed in
33cf4af1ac as it was not needed
anymore in the base module. However it is still an extension point
that can be used.
fixes#1362
Ignoring qty_available for phantom products prevents double counting the
qty_available of components.
Creating planned orders for phantom products is simpler than recursively
exploding phantom BOMs. This also makes it easier to analyze the planning data
generated by the MRP calculation.
When a product has a safety stock in an area, and the current stock is
below safety, but there are moves in the future, mrp_multi_level does
not compute an immediate action to get back to the safety stock.
This PR changes this behavior: when the mrp_moves are considered, before
processing the first move in the future, we insert a resupply action to
rebuild the safety stock.
We also add some refactoring in the process:
* add extension point on the wizard to compute the quantity to reorder
(so we can choose in a separate module whether to rebuild safety stock
or not)
* add extension point on the wizard to get the date at which the safety
stock must be rebuilt (defaults to today)
* make the code of the wizard symetric between the groupes and non
grouped configuration
Small refactoring adding a _get_locations method on product.mrp.area
which by defaults delegates the computation to the related mrp.area.
This enables extending a few things related to locations at the
product.mrp.area level.
Change the way `_get_locations()` work: don't return the list of child
locations, only the top-most locations, and then use the `child_of`
operator in the code that looks for locations.
When running the multi level planner, the wizard will delete the records
from the previous run (mrp.inventory, mrp.move, mrp.planned.order).
There can be hundreds of such records, and the call to unlink() will
create a log entry which is not really informative. We disable this log
during the call to the wizard (but keep if for manual unlinking of the
records which we want to trace).
