[WIP] Make module stock work, for stock_location check removal strategy, journal_id...
[odoo/odoo.git] / addons / stock_location / __openerp__.py
1 # -*- coding: utf-8 -*-
2 ##############################################################################
3 #
4 #    OpenERP, Open Source Management Solution
5 #    Copyright (C) 2004-2010 Tiny SPRL (<http://tiny.be>).
6 #
7 #    This program is free software: you can redistribute it and/or modify
8 #    it under the terms of the GNU Affero General Public License as
9 #    published by the Free Software Foundation, either version 3 of the
10 #    License, or (at your option) any later version.
11 #
12 #    This program is distributed in the hope that it will be useful,
13 #    but WITHOUT ANY WARRANTY; without even the implied warranty of
14 #    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
15 #    GNU Affero General Public License for more details.
16 #
17 #    You should have received a copy of the GNU Affero General Public License
18 #    along with this program.  If not, see <http://www.gnu.org/licenses/>.
19 #
20 ##############################################################################
21
22
23 {
24     'name': 'Advanced Routes',
25     'version': '1.0',
26     'category': 'Manufacturing',
27     'description': """
28 This module supplements the Warehouse application by effectively implementing Push and Pull inventory flows.
29 ============================================================================================================
30
31 Typically this could be used to:
32 --------------------------------
33     * Manage product manufacturing chains
34     * Manage default locations per product
35     * Define routes within your warehouse according to business needs, such as:
36         - Quality Control
37         - After Sales Services
38         - Supplier Returns
39
40     * Help rental management, by generating automated return moves for rented products
41
42 Once this module is installed, an additional tab appear on the product form,
43 where you can add Push and Pull flow specifications. The demo data of CPU1
44 product for that push/pull :
45
46 Push flows:
47 -----------
48 Push flows are useful when the arrival of certain products in a given location
49 should always be followed by a corresponding move to another location, optionally
50 after a certain delay. The original Warehouse application already supports such
51 Push flow specifications on the Locations themselves, but these cannot be
52 refined per-product.
53
54 A push flow specification indicates which location is chained with which location,
55 and with what parameters. As soon as a given quantity of products is moved in the
56 source location, a chained move is automatically foreseen according to the
57 parameters set on the flow specification (destination location, delay, type of
58 move, journal). The new move can be automatically processed, or require a manual
59 confirmation, depending on the parameters.
60
61 Pull flows:
62 -----------
63 Pull flows are a bit different from Push flows, in the sense that they are not
64 related to the processing of product moves, but rather to the processing of
65 procurement orders. What is being pulled is a need, not directly products. A
66 classical example of Pull flow is when you have an Outlet company, with a parent
67 Company that is responsible for the supplies of the Outlet.
68
69   [ Customer ] <- A - [ Outlet ]  <- B -  [ Holding ] <~ C ~ [ Supplier ]
70
71 When a new procurement order (A, coming from the confirmation of a Sale Order
72 for example) arrives in the Outlet, it is converted into another procurement
73 (B, via a Pull flow of type 'move') requested from the Holding. When procurement
74 order B is processed by the Holding company, and if the product is out of stock,
75 it can be converted into a Purchase Order (C) from the Supplier (Pull flow of
76 type Purchase). The result is that the procurement order, the need, is pushed
77 all the way between the Customer and Supplier.
78
79 Technically, Pull flows allow to process procurement orders differently, not
80 only depending on the product being considered, but also depending on which
81 location holds the 'need' for that product (i.e. the destination location of
82 that procurement order).
83
84 Use-Case:
85 ---------
86
87 You can use the demo data as follow:
88 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
89   **CPU1:** Sell some CPU1 from Chicago Shop and run the scheduler
90      - Warehouse: delivery order, Chicago Shop: reception
91   **CPU3:**
92      - When receiving the product, it goes to Quality Control location then
93        stored to shelf 2.
94      - When delivering the customer: Pick List -> Packing -> Delivery Order from Gate A
95     """,
96     'author': 'OpenERP SA',
97     'images': ['images/pulled_flow.jpeg','images/pushed_flow.jpeg'],
98     'depends': ['procurement','stock'],
99     'data': ['stock_location_view.xml', 'security/stock_location_security.xml', 'security/ir.model.access.csv'],
100     'demo': [
101         'stock_location_demo_cpu1.xml',
102         'stock_location_demo_cpu3.yml',
103     ],
104     'installable': True,
105     'test': [
106         'test/stock_location_pull_flow.yml',
107         'test/stock_location_push_flow.yml',
108     ],
109     'auto_install': False,
110 }
111
112 # vim:expandtab:smartindent:tabstop=4:softtabstop=4:shiftwidth=4: