TIP: You can type at any time to perform a new search.
Advanced Routes
stock_location · odoo/odoo
Security findings
Migration considerations
- Imports from the old `openerp.osv` namespace: renamed to `odoo` since Odoo 10.0. migration-openerp-import · source
- Imports from the old `openerp.osv` namespace: renamed to `odoo` since Odoo 10.0. migration-openerp-import · source
- Imports from the old `openerp` namespace: renamed to `odoo` since Odoo 10.0. migration-openerp-import · source
- Imports from the old `openerp.tools.translate` namespace: renamed to `odoo` since Odoo 10.0. migration-openerp-import · source
- Uses the old workflow engine (base.workflow / `trg_validate`): removed in Odoo 11.0, must be rewritten as state-field transitions. migration-workflow · source
- Uses the old workflow engine (base.workflow / `trg_validate`): removed in Odoo 11.0, must be rewritten as state-field transitions. migration-workflow · source
- Uses the old workflow engine (base.workflow / `trg_validate`): removed in Odoo 11.0, must be rewritten as state-field transitions. migration-workflow · source
- For a target of Odoo 10.0+: use the `__manifest__.py` manifest name instead of `__openerp__.py`. The filename alone does not establish module age or compatibility. migration-openerp-manifest · source
procurement_order— Class 'procurement_order' still inherits from the old-style `osv.osv` API: rewrite it against `models.Model`/`models.TransientModel`/`models.AbstractModel` - the old `osv`/`orm` API was removed entirely in modern Odoo. migration-old-api-base · sourceproduct_normal_form_inherit_location— For a target of Odoo 17.0+: view 'product_normal_form_inherit_location' uses `attrs=`/`states=`, which are no longer supported. Convert modifiers to direct Python boolean expressions in `invisible`/`readonly`/`required`; preserve the original AND/OR logic. migration-view-attrs-states · sourceproduct_product— Class 'product_product' still inherits from the old-style `osv.osv` API: rewrite it against `models.Model`/`models.TransientModel`/`models.AbstractModel` - the old `osv`/`orm` API was removed entirely in modern Odoo. migration-old-api-base · sourceproduct_product— Class 'product_product' declares `_columns` as a plain dict: old-style field/default declarations, replace with `fields.X(...)` class attributes and `default=`. migration-old-style-fields · sourceproduct_pulled_flow— Class 'product_pulled_flow' still inherits from the old-style `osv.osv` API: rewrite it against `models.Model`/`models.TransientModel`/`models.AbstractModel` - the old `osv`/`orm` API was removed entirely in modern Odoo. migration-old-api-base · sourceproduct_pulled_flow— Class 'product_pulled_flow' declares `_columns` as a plain dict: old-style field/default declarations, replace with `fields.X(...)` class attributes and `default=`. migration-old-style-fields · sourceproduct_pulled_flow— Class 'product_pulled_flow' declares `_defaults` as a plain dict: old-style field/default declarations, replace with `fields.X(...)` class attributes and `default=`. migration-old-style-fields · sourcestock_location— Class 'stock_location' still inherits from the old-style `osv.osv` API: rewrite it against `models.Model`/`models.TransientModel`/`models.AbstractModel` - the old `osv`/`orm` API was removed entirely in modern Odoo. migration-old-api-base · sourcestock_location_path— Class 'stock_location_path' still inherits from the old-style `osv.osv` API: rewrite it against `models.Model`/`models.TransientModel`/`models.AbstractModel` - the old `osv`/`orm` API was removed entirely in modern Odoo. migration-old-api-base · sourcestock_location_path— Class 'stock_location_path' declares `_columns` as a plain dict: old-style field/default declarations, replace with `fields.X(...)` class attributes and `default=`. migration-old-style-fields · sourcestock_location_path— Class 'stock_location_path' declares `_defaults` as a plain dict: old-style field/default declarations, replace with `fields.X(...)` class attributes and `default=`. migration-old-style-fields · sourcestock_move— Class 'stock_move' still inherits from the old-style `osv.osv` API: rewrite it against `models.Model`/`models.TransientModel`/`models.AbstractModel` - the old `osv`/`orm` API was removed entirely in modern Odoo. migration-old-api-base · sourcestock_move— Class 'stock_move' declares `_columns` as a plain dict: old-style field/default declarations, replace with `fields.X(...)` class attributes and `default=`. migration-old-style-fields · sourcestock_location_path_tree— View 'stock_location_path_tree' is defined with a `<tree>` root tag: renamed to `<list>` in Odoo 18.0. migration-view-tree-tag · source
Migration review checklist, not a compatibility verdict. No target version is selected: apply version-specific advice only when migrating to that version or later.
- Repository
- odoo/odoo · module folder
- Module version
- 1.0
- Category
- Manufacturing
- Folder size
- 0.71 MB
- License
- LGPL-3
- Application
- No
- Auto-installable
- No
- Website
- None
- Last tracking update
- 2026-08-07 04:50:06
- Authors
- OpenERP SA
- Maintainers
- OpenERP SA
- Committers
- Rucha (Open ERP), Numerigraphe - Lionel Sausin, Vo Minh Thu, pso (OpenERP), Olivier Dony, Stephane Wirtel, Mayur Maheshwari (OpenERP), Launchpad Translations on behalf of openerp, Fabien Pinckaers, Raphael Collet, Harry (OpenERP), Thibault Delavallée, Martin Trigaux, Bhumika (OpenERP), Turkesh Patel (Open ERP), Alexis de Lattre, Purnendu Singh (OpenERP), Twinkle Christian (OpenERP), Hardik, Cecile Tonglet, Antonin Bourguignon, Amit Patel (OpenERP), Sbh (Openerp), Odoo Translation Bot, Ajay Chauhan (OpenERP), Rajesh Prajapati (OpenERP), help, Denis Ledoux dle@openerp.com, dle@openerp.com
- Odoo dependencies
- Python dependencies
- None
- System dependencies
- None
- Required by
- None
- Description
This module supplements the Warehouse application by effectively implementing Push and Pull inventory flows. ============================================================================================================ Typically this could be used to: -------------------------------- * Manage product manufacturing chains * Manage default locations per product * Define routes within your warehouse according to business needs, such as: - Quality Control - After Sales Services - Supplier Returns * Help rental management, by generating automated return moves for rented products Once this module is installed, an additional tab appear on the product form, where you can add Push and Pull flow specifications. The demo data of CPU1 product for that push/pull : Push flows: ----------- Push flows are useful when the arrival of certain products in a given location should always be followed by a corresponding move to another location, optionally after a certain delay. The original Warehouse application already supports such Push flow specifications on the Locations themselves, but these cannot be refined per-product. A push flow specification indicates which location is chained with which location, and with what parameters. As soon as a given quantity of products is moved in the source location, a chained move is automatically foreseen according to the parameters set on the flow specification (destination location, delay, type of move, journal). The new move can be automatically processed, or require a manual confirmation, depending on the parameters. Pull flows: ----------- Pull flows are a bit different from Push flows, in the sense that they are not related to the processing of product moves, but rather to the processing of procurement orders. What is being pulled is a need, not directly products. A classical example of Pull flow is when you have an Outlet company, with a parent Company that is responsible for the supplies of the Outlet. [ Customer ] <- A - [ Outlet ] <- B - [ Holding ] <~ C ~ [ Supplier ] When a new procurement order (A, coming from the confirmation of a Sale Order for example) arrives in the Outlet, it is converted into another procurement (B, via a Pull flow of type 'move') requested from the Holding. When procurement order B is processed by the Holding company, and if the product is out of stock, it can be converted into a Purchase Order (C) from the Supplier (Pull flow of type Purchase). The result is that the procurement order, the need, is pushed all the way between the Customer and Supplier. Technically, Pull flows allow to process procurement orders differently, not only depending on the product being considered, but also depending on which location holds the 'need' for that product (i.e. the destination location of that procurement order). Use-Case: --------- You can use the demo data as follow: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **CPU1:** Sell some CPU1 from Chicago Shop and run the scheduler - Warehouse: delivery order, Chicago Shop: reception **CPU3:** - When receiving the product, it goes to Quality Control location then stored to shelf 2. - When delivering the customer: Pick List -> Packing -> Delivery Order from Gate A
Code Analysis
Views touched (3)
| XML ID | Name | Model | Type | Status |
|---|---|---|---|---|
product_normal_form_inherit_location |
product.product.form | product.product | form | Inherits product.product_normal_form_view |
stock_location_path_form |
stock.location.path.form | stock.location.path | form | New |
stock_location_path_tree |
stock.location.path.tree | stock.location.path | tree | New |
HTTP endpoints (0)
No HTTP endpoints found for this module.
Models touched (0)
No models found for this module.
Loading…