-
-
Notifications
You must be signed in to change notification settings - Fork 733
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[11.0][MIG] stock_available: Migration to 11.0 #353
Conversation
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 0b060f6 from the v7 branch
Module to take immediate manufaturing capability into account in the stock quantity available to promise. Conflicts: stock_available/res_config.py
Take sale quotations into account in the stock quantity available to promise Cherry-picked from 497068f Conflicts: stock_available/res_config.py
Cherry-picked from v7 at 8add4be Conflicts: __unported__/stock_available_mrp/__openerp__.py stock_available/__openerp__.py stock_available_immediately/__openerp__.py
odoo/odoo#5512 and odoo-dev/odoo@b3e5a94 makes it clear the standard intends to support decimal precision on the product form.
…uct and product.template, now takes in account variants and correctly displays value. [FLAKE8] Removing duplicate modules and moving README.rst into __unported__
not using internal qty_available that seems not to take in consideration reserved quants.
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 OCA#73 too.
* 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)
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
…ch field use to compute potential
hi, is this module need in v11.0? |
@fanha99 no, forecasted quantity is current stock - reserved + incoming. This module provides current stock - reserved (because sometimes incoming will only be available in a long time in the future) |
</div> | ||
</div> | ||
|
||
<!--<div>--> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need to keep the commented out section?
OCA Transbot updated translations from Transifex can be squashed together |
What do the coverage error messages ( |
Don't worry about that message. It's an old one. |
Superseeded by #405 |
No description provided.