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).
Introduce a safe and configurable LLC depth limit to avoid infinite
recursion.
Also, improve extensibility of BoM finding and fix it to not
consider archived BoMs.
* keept description of planned orders verbose.
* make it translatable in most cases.
* while grouping demand include the product in the description.
* add `origin` field not mrp moves and planned orders. Fill it
with top level demand origin.
If the destination moves do not include a MO, the mrp move end
up without a name that raises an error later. This can happen
with 3 setep delivery but also with in more cases in wich there is
a chain of stock moves.
We ensure that the variable `order_number` always have a value.
* 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).
* Planned Orders become fixed on manual creation by default
* Released Quantity become readonly
* Add product reference if Planned Order name is not defined on bom explosion
demand moves have the same date it can happen that the supply is
effectively ignored if considered as staring move of the
grouping and there are more groups to be done after it.
A test case include in this fix depicts in detail the
the problem and ensures no regression.
* 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.
