Normal BoM products (those which are manufactured) are regular stored
products and their immediately_usable_qty will be summed with potential
stock. This was the expected behavior of the module and it was lost at
some point.
Phantom BoM products (kits) don't have real stock so their available to
promise quantity will be the same as the potential.
As an improvement, we've added the possibility to override the sum of
potential and available to promise. In some cases such addition doesn't
make sense as we don't know how long can take to manufacture those potential
units.
TT35589
If a Bill of Materials contains a non storable component (consumable or
even service) the potential quantity will allways be 0. We should only
consider storable components as others are considered infinite.
TT33175
In Odoo change odoo/odoo@3d34d58 the products with Kit BoMs couldn't
longer be other than `consu`. This was reverted in odoo/odoo@6c4623a
and some products are raising errors when forcing the type
After this change 3d34d58388
it isn't possible to have an storable kit product anymore. The main
issue is that we have to drop some uses cases that this module
considered for this kind of situations.
Record rules used to not be checked on stock quants, but now they are since Odoo's commit 2fd14db57433d08ab368a7e18d18ae8d49dafab1 (https://github.com/odoo/odoo/commit/2fd14db).
In our test we changed the company of the products and BoMs but we neglected that the stock was not attached to the right company, and that made the test fail.
To fix that, make the test inventory for the right company.
Since there is a little inconsistency in the demo data with a negative quantity of an unrelated product, use the `partial` filter for the inventories instead of the `none` filter, so that no wrong inventory lines are added automatically.
sudo is not required since mrp.bom are readable to groups with access to the qty_x fields on a product. Moreover using sudo to retrive the bom will ignore the company_id defined on the bom
Compute potential quantities for both product templates and variants. To keep the code simple, only the biggest potential of any single variant is accounted for in the template's potential.
Take all levels of phantom BoM into account, respects validity dates etc. thanks to the use of the standard method _bom_explode, as suggested by @gdgellatly in https://github.com/OCA/stock-logistics-warehouse/pull/5#issuecomment-66902191
Improve tests, rewritten in python.
Adhere to new file/manifest/README conventions.
Simplify copyright headers
