Adrien Widart 18e6be5d08 [FIX] stock: apply putaway strategy on packages
The putaway strategies are not correctly working with packages

To reproduce the issue:
1. In Settings, enable:
    - Multi-Step Routes
    - Storage Categories
    - Packages
2. Create a Storage Category SC:
    - Allow New Product: mixed
    - Max Weight: 100 kg
    - Capacity by Package:
        - 1 x Pallet
3. Create two locations L1, L2:
    - Parent: WH/Stock
    - Type: Internal
    - Storage Category: SC
4. Create a putaway rule:
    - When in: WH/Stock
    - Package type: Pallet
    - Store to: WH/Stock
    - Having Category: SC
5. Edit the warehouse:
    - Incoming Shipments: 2 steps
6. Create a product P:
    - Type: Storable
    - Weight: 1 kg
7. Create a planned receipt R:
    - To: WH/Input
    - Operations:
        - 100 x P
8. Mark R as Todo
9. Create two packages:
    - 50 x P in PK01 (! PK01 must be a Pallet)
    - 50 x P in PK02 (! PK02 must be a Pallet)
10. Validate R
11. Open the related internal transfer T
    - Error [1]: Both packages are redirected to L01, but the capacity
by package is 1 x Pallet. PK01 should be redirected to L01 and PK02 to
L02
12. Set the done quantity of PK01
    - Note: PK01 is now redirected to L02
13. Set the done quantity of PK02
    - Error [2]: PK02 is also redirected to L02. Again, it violates the
package capacity constraint

**Context**

When validating the receipt (step 10), it creates a picking
Input->Stock. The module then tries to assign some quantities, which
leads to `_prepare_move_line_vals` for each package. In this method,
`_get_putaway_strategy` is called to define the best destination of each
stock move line:
https://github.com/odoo/odoo/blob/d55a99ff2d2f7b8d44cde1db3b6d48cdaac1cd3a/addons/stock/models/stock_move.py#L1313
The computation of the best location is in 3 phases:
- Phase 01: `_get_putaway_strategy` finds the relevant putaway rules and
computes the current and forecasted stock related to the current
package/product
- Phase 02: `_get_putaway_location` checks if, considering the putaway
rule and the current package/product, a location can be used
- Phase 03: `_check_can_be_used` checks if a location can receive a
package/product (considering the weight and the capacity constraints)

**Error 01**

During the first phase, in case of a package, the forecasted quantities
are computed by searching all SML that have the same package type:
https://github.com/odoo/odoo/blob/4bae10e0d960e5b80055e0e44056493238e552d3/addons/stock/models/stock_location.py#L258-L263
This can not work. The SML used to move the product in PK01 (from Input
to Stock) is created but its field `result_package_id` is not yet
defined. This operation will be done at the of the assign process,
thanks to:
https://github.com/odoo/odoo/blob/d55a99ff2d2f7b8d44cde1db3b6d48cdaac1cd3a/addons/stock/models/stock_move.py#L1547
So, during the first phase, when searching a location for PK02, the
computations are not aware that PK01 is already sent to L01. This
explains the error [1].

**Error 01 (Other examples)**

Considering how it is currently working, we could imagine another
problematic use case: 2 different products on the same package. Since
there is one SML per product, `_prepare_move_line_vals` will be called
twice (as well as the putaway strategy process). It may lead to two
different locations while the product are on the same package.

**Error 02**

When setting the done quantity, an onchange method is triggered:
https://github.com/odoo/odoo/blob/4202e46a8313fa9f1487d372ef0cb771f769be8d/addons/stock/models/stock_move_line.py#L200-L208
and tries to find the best location, considering the done quantity. As
said before, during the first phase, it looks for the current and
forecasted stock of a location. Since it will find the SML we are
writing on, the parameter `additional_qty` is used to subtract the
quantity of this SML (we need to ignore the current SML's quantity). But
here is a new issue:
https://github.com/odoo/odoo/blob/4202e46a8313fa9f1487d372ef0cb771f769be8d/addons/stock/models/stock_move_line.py#L217-L222
`_get_putaway_additional_qty` returns the quantity of products while the
first phase is looking for the quantity of packages. As a result, we do
some operations between products and packages:
https://github.com/odoo/odoo/blob/4bae10e0d960e5b80055e0e44056493238e552d3/addons/stock/models/stock_location.py#L290-L292
`qty_by_location[location_id]` is 2 (i.e. PK01 and PK02) for L01 while
`qty` is `-50` (i.e. the 50 products of the current SML), so the value
becomes `-48`. This can not work properly because the value doesn't have
sense anymore. Later on, during the third phase:
https://github.com/odoo/odoo/blob/4bae10e0d960e5b80055e0e44056493238e552d3/addons/stock/models/stock_location.py#L340-L346
The forecasted weight is not subtracted by the quantity of the current
SML. So the weight is exceeded, this is the reason why the destination
of PK01 becomes L02 on step 12 (it will be the same on step 13)

**Additional error**

Suppose the user is receiving a tracked product (suppose qty > 1). When
confirming the picking, several SMLs are generated to "reserve" the
quantity from the customer:
https://github.com/odoo/odoo/blob/d55a99ff2d2f7b8d44cde1db3b6d48cdaac1cd3a/addons/stock/models/stock_move.py#L1469-L1471
Later on, thanks to the wizard `stock.assign.serial`, the user generates
all USN. However, because the option `show_reserved` is disabled, the
wizard creates some new SMLs. But here is the issue, the SMLs created
during the assign process are already existing. Therefore, when looking
for the best location (for the new SMLs), the existing SMLs will disturb
the result (`_get_putaway_strategy` will find these SMLs and think that
some products are already incoming in some locations)

**Solutions**

- We should compute the best locations once all SMLs are created (and
linked with their package)
- In case of a package with a type, we should try to find the best
location for the package itself, not for each product of the package
- When calling the putaway strategy process, we should provide the
SML(s) to exclude instead of providing some quantities. This will
prevent subtracting products with packages and allow the correct
calculation of the forecasted weight for each location
- When creating a putaway rule, we ensure that the option
`show_reserved` of the destination location is enabled

OPW-2746169

closes odoo/odoo#89350

X-original-commit: 98169b391f4610545b7f4745b729ad95eac3696a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
2022-04-22 09:58:03 +02:00
2022-04-12 15:48:58 +02:00
2022-04-21 07:59:26 +02:00
…
…
…
2021-10-07 17:59:53 +00:00
2022-01-14 15:44:52 +00:00

Build Status Tech Doc Help Nightly Builds

Odoo

Odoo is a suite of web based open source business apps.

The main Odoo Apps include an Open Source CRM, Website Builder, eCommerce, Warehouse Management, Project Management, Billing & Accounting, Point of Sale, Human Resources, Marketing, Manufacturing, ...

Odoo Apps can be used as stand-alone applications, but they also integrate seamlessly so you get a full-featured Open Source ERP when you install several Apps.

Getting started with Odoo

For a standard installation please follow the Setup instructions from the documentation.

To learn the software, we recommend the Odoo eLearning, or Scale-up, the business game. Developers can start with the developer tutorials

S
Description
No description provided
Readme LGPL-3.0
3.4 GiB
Languages
Python 49.6%
JavaScript 47.8%
SCSS 2%
CSS 0.3%
HTML 0.2%