mirror of
https://github.com/OCA/stock-logistics-warehouse.git
synced 2025-01-21 14:27:28 +02:00
bed8fdbfcd
The update of the source location of a move is not a good idea, as shown in the test case that is modified by this commit and explained below. In general, a stock.move will be linked to a stock.picking whose location_id and location_dest_id are defined by the picking type. As such, the stock.move will inherit these locations and it is the assignation of the stock.move that will create a stock.move.line where the location (in case of outgoing picking) or the destination location (in case of incoming picking through putaway) will be a sub location of the respective location defined on the move. So, if we want to empty a stock.location and move all its content to another stock.location, we do not want to update the location of the reserved moves, since it can break the reservation mechanism of Odoo, as the assignation of a move will always look into the children locations of the move, and it is not supposed to be updated by any internal transfer, to what could be a children location. Then, if internal transfers were planned from the location that is being emptied, but are supposed to be executed after the location has been emptied, there is probably an issue with the planning and the sequence in which both transfers are being executed. Since the internal transfer being updated in the test case was also moving from a shelf location to its parent (where technically the goods are already, since they are in a child location), we should prefer not breaking the standard workflow of Odoo instead of supporting a corner case with an internal transfer. I guess we can revisit my assumption if we have a good reason to update the stock location, but the one that was tested doesn't seem to be good enough to justify breaking a standard mechanism.
stock-logistics-warehouse
TODO: add repo description.
Available addons
| addon | version | maintainers | summary |
|---|---|---|---|
| account_move_line_product | 15.0.1.0.1 | Displays the product in the journal entries and items | |
| account_move_line_stock_info | 15.0.1.0.0 | Account Move Line Stock Info | |
| procurement_auto_create_group | 15.0.1.0.0 | Allows to configure the system to propose automatically new procurement groups during the procurement run. | |
| stock_available | 15.0.1.0.0 | Stock available to promise | |
| stock_available_mrp | 15.0.1.0.1 | Consider the production potential is available to promise | |
| stock_available_unreserved | 15.0.1.0.0 |  |
Quantity of stock available for immediate use |
| stock_demand_estimate | 15.0.1.0.0 | Allows to create demand estimates. | |
| stock_demand_estimate_matrix | 15.0.1.1.0 | Allows to create demand estimates. | |
| stock_helper | 15.0.1.0.0 | Add methods shared between various stock modules | |
| stock_location_lockdown | 15.0.1.0.1 | Prevent to add stock on locked locations | |
| stock_location_route_description | 15.0.1.0.0 | Add description field on stock routes. | |
| stock_move_location | 15.0.1.0.0 | This module allows to move all stock in a stock location to an other one. | |
| stock_mts_mto_rule | 15.0.1.0.1 | Add a MTS+MTO route | |
| stock_orderpoint_move_link | 15.0.1.0.0 | Link Reordering rules to stock moves | |
| stock_orderpoint_purchase_link | 15.0.1.0.0 | Link Reordering rules to purchase orders | |
| stock_orderpoint_uom | 15.0.1.0.0 | Allows to create procurement orders in the UoM indicated in the orderpoint | |
| stock_packaging_calculator | 15.0.1.0.0 | Compute product quantity to pick by packaging | |
| stock_quant_manual_assign | 15.0.1.2.0 | Stock - Manual Quant Assignment | |
| stock_request | 15.0.1.0.0 | Internal request for stock | |
| stock_request_purchase | 15.0.1.0.1 | Internal request for stock | |
| stock_secondary_unit | 15.0.1.0.0 | Get product quantities in a secondary unit | |
| stock_warehouse_calendar | 15.0.1.0.0 |  |
Adds a calendar to the Warehouse |
Licenses
This repository is licensed under AGPL-3.0.
However, each module can have a totally different license, as long as they adhere to Odoo Community Association (OCA)
policy. Consult each module's __manifest__.py file, which contains a license key
that explains its license.
OCA, or the Odoo Community Association, is a nonprofit organization whose mission is to support the collaborative development of Odoo features and promote its widespread use.