_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 we change the sequence order of the Vendor Pricelist for a product, we firstly fetch the vendors and then we change the sequence. Then, when changing a sequence we try to get the first supplier but we do not get the desired result.
Reordering the suppliers allows to always get the first supplier in the list.
For each MRP Parameter, we will calculate its supply method based on the procurement rules path. We will go back in the rules until we find that the action is "buy" or "manufacture", or until the action is "Pull From" or "Pull & Push" and the supply method is "Take from Stock".
This means we will show what the latest rule is if we were to do a procurement. Although it would be possible that the final action does not end up being executed if stock already exists in one of the intermediate locations.
For each MRP Parameter or for each Product in a MRP Area, we will be able to add a MRP Planner. Once this planner is set, he can filter himself in the MRP Parameters view, MRP Inventory view or MRP Planned Orders view.
* Planned Order release and due date become required.
* Add button to Product MRP Area to update MOQ from Supplier Info.
* Link Manufacturing Orders with Planned Orders.
* Allow Mrp Inventory Procure Wizard to be used from other models.
* Make MRP Inventory creation more extensible.
* Main Supplier computation (v13 requires explicit False definitions).
* You can know integrate with different forecasting mechanisms.
As a consequence integration with stock_demand_estimate is moved
to a new module (mrp_multi_level_estimate).
* As agreed by the authors, the module is re-licensed to LGPL-3.
* fix api.depends fields fro main supplier.
* fix ordering and missing demo file in manifest.
* Update README.
* fix action_view* methods.
* readd hook to exclude in mrp initialization
* fix computation of qty available (it was considering several times sub-locations).
* Remove contraint for outoing and incoming moves to be moved in/outside the company, they can be internal transfers.
* mrp.moves visible with technical settings.
* Show product and allow to search by it in mrp.inventory.
