| REPOSITORY | |
|---|---|
| REPOSITORY | odoo/odoo |
| GIT | |
| GIT | https://github.com/odoo/odoo.git |
| GIT FOLDER | |
| GIT FOLDER | https://github.com/odoo/odoo/tree/7.0/stock_location |
| VERSION | |
| VERSION | 1.0 |
| CATEGORY | |
| CATEGORY | Manufacturing |
| LICENSE | |
| LICENSE | LGPL-3 |
| APPLICATION | |
| APPLICATION | No |
| AUTO-INSTALLABLE | |
| AUTO-INSTALLABLE | No |
| AUTHORS | |
| AUTHORS | OpenERP SA |
| MAINTAINERS | |
| MAINTAINERS | OpenERP SA |
| COMMITTERS | |
| COMMITTERS | Raphael Collet, Twinkle Christian (OpenERP), Cecile Tonglet, Rucha (Open ERP), Stephane Wirtel, Odoo Translation Bot, Turkesh Patel (Open ERP), Numerigraphe - Lionel Sausin, Harry (OpenERP), Antonin Bourguignon, Martin Trigaux, Ajay Chauhan (OpenERP), Bhumika (OpenERP), Purnendu Singh (OpenERP), Fabien Pinckaers, Olivier Dony, Rajesh Prajapati (OpenERP), Thibault Delavallée, Vo Minh Thu, Hardik, pso (OpenERP), Sbh (Openerp), Amit Patel (OpenERP), Launchpad Translations on behalf of openerp, Mayur Maheshwari (OpenERP), Alexis de Lattre, help, Denis Ledoux dle@openerp.com, dle@openerp.com |
| WEBSITE | |
| WEBSITE | |
| LAST TRACKING UPDATE | |
| LAST TRACKING UPDATE | 2026-07-05 23:43:11 |
| ODOO DEPENDENCIES | |
| ODOO DEPENDENCIES |
odoo/odoo: - procurement - base - process - web - product - decimal_precision - base_setup - web_kanban - stock - account - analytic - board - edi - email_template - sale - account_voucher |
| PYTHON DEPENDENCIES | |
| PYTHON DEPENDENCIES | Not have |
| SYSTEM DEPENDENCIES | |
| SYSTEM DEPENDENCIES | Not have |
| DESCRIPTION | |
| 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
|
| XML ID | Name | Model | Type | Status |
|---|---|---|---|---|
product_normal_form_inherit_location |
product.product.form | product.product | group | 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 |
No models found for this module.
| REPOSITORY | |
|---|---|
| REPOSITORY | odoo/odoo |
| GIT | |
| GIT | https://github.com/odoo/odoo.git |
| GIT FOLDER | |
| GIT FOLDER | https://github.com/odoo/odoo/tree/6.1/stock_location |
| VERSION | |
| VERSION | 1.0 |
| CATEGORY | |
| CATEGORY | Manufacturing |
| LICENSE | |
| LICENSE | LGPL-3 |
| APPLICATION | |
| APPLICATION | No |
| AUTO-INSTALLABLE | |
| AUTO-INSTALLABLE | No |
| AUTHORS | |
| AUTHORS | OpenERP SA |
| MAINTAINERS | |
| MAINTAINERS | OpenERP SA |
| COMMITTERS | |
| COMMITTERS | Stephane Wirtel, Numerigraphe - Lionel Sausin, Fabien Pinckaers, Olivier Dony, Vo Minh Thu, Launchpad Translations on behalf of openerp, Mayur Maheshwari (OpenERP), vro, niv-openerp, Ujjvala Collins (OpenERP), Xavier Morel, Carlos Vásquez, Els Van Vossel, Israel Fermin Montilla, rch-openerp, ron@tinyerp.com |
| WEBSITE | |
| WEBSITE | |
| LAST TRACKING UPDATE | |
| LAST TRACKING UPDATE | 2026-07-05 23:41:35 |
| ODOO DEPENDENCIES | |
| ODOO DEPENDENCIES |
odoo/odoo: - procurement - base - process - product - decimal_precision - stock - account - base_setup - analytic - board - edi - email_template - base_tools - sale |
| PYTHON DEPENDENCIES | |
| PYTHON DEPENDENCIES | Not have |
| SYSTEM DEPENDENCIES | |
| SYSTEM DEPENDENCIES | Not have |
| DESCRIPTION | |
| 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, etc.) 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 Shop 1 and run the scheduler
- Warehouse: delivery order, Shop 1: 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
|
| XML ID | Name | Model | Type | Status |
|---|---|---|---|---|
product_normal_form_inherit_location |
product.product.form | product.product | notebook | 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 |
No models found for this module.