There are cases where we dot NOT want to simply sum the quantities of all the
variants. For example when dealing with manufacturing capacities, we may have
to chose between variants because we can't make ALL of them with the same
components.
So instead of a simple non-modular implementation, we'll let each module define
his own implementation of how to compute the product template's quantity
available for sale.
Conflicts:
stock_available/__openerp__.py
stock_available_immediately/__openerp__.py
* fix the dependencies for the computed field
* use api.multi instead of api.one to avoid calling
super()._immediately_usable_qty in a loop (this improves perfs on a tree view
display)
Commit 6c16913 changed the way we compute the immediately_usable_qty: instead of using the virtual stock, we used the sum of quants without reservations. But a quant may actually be reserved and still be available (for example it may be reserved for an internal move).
Fixes https://github.com/OCA/stock-logistics-warehouse/issues/79
Remove loop and use correct decorator
Restore the features of stock_available_immediately
The previous fix restored stock_available but then there was no way to exclude the incomming moves from the count. This belongs in stock_available_immediately, restoring it cleanly.
This commit also takes care to respect the distinction between templates and variants, so it should fix https://github.com/OCA/stock-logistics-warehouse/issues/73 too.
Restore the qty avail. to promise on variant treeview
PEP8
product.template, now takes in account variants and correctly displays value.
[FLAKE8]
Removing duplicate modules and moving README.rst into __unported__
[ADD} location calculations
[FIX] typo
Generic module to compute the stock quantity available to promise using several implementations.
stock_available_immediatly is changed to become the first optional implementation.
Cherry pick of commit 0b060f619f from the v7 branch
[IMP] stock_available* uses new API
[ADD] stock_available_mrp
Module to take immediate manufaturing capability into account in the stock quantity available to promise.
Conflicts:
stock_available/res_config.py
[DEL] move stock_available_mrp to __unported__
[ADD] stock_available_sale
Take sale quotations into account in the stock quantity available to promise
Cherry-picked from 497068f5f5
Conflicts:
stock_available/res_config.py
[DEL] move stock_available_sale to __unported__
[IMP] READMEs and TODOs
Cherry-picked from v7 at 8add4bea7e
Conflicts:
__unported__/stock_available_mrp/__openerp__.py
stock_available/__openerp__.py
stock_available_immediately/__openerp__.py
[IMP] respect product decimal precision
https://github.com/odoo/odoo/issues/5512 and b3e5a940e3 makes it clear the standard intends to support decimal precision on the product form.
Using an already created product can lead to incorrect tests on integrated
environments where other modules modify this product. We create a new one for
avoiding this side effect.
This method is called from the write() method the one how support
multiple records an api.multi method.
I was making some test when I tried to activate the mto+mts option for
multiple warehouse and the next error appears: ``ValueError: Expected singleton``
In order to fix this error I only added a loop to manage the multiple
registers.
Conforms to the latest README template: bugtracker, runbot etc.
Fixes bugtracker URL on some modules.
States OCA as maintainer, removes other contributors from the 'Maintainer' section.
