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
closesodoo/odoo#89350
X-original-commit: 98169b391f4610545b7f4745b729ad95eac3696a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When performing a picking with a package, the source location of the
package level may become incorrect
To reproduce the issue:
(Use demo data)
1. In Settings, enable:
- Packages
- Storage Locations
2. In Operations Types, edit "Internal Transfers":
- Enable "Move Entire Packages"
3. Create a storable product P
4. Create a receipt R with for P
5. Put 10 P in pack and validate R
- Let be PK the package generated/used
6. Process an internal transfer with PK
- The destination location of the package level is WH/Stock/Shelf 1
Error: Once the picking is validated, the source location of the package
level is "WH/Stock/Shelf 1". This is not true, it should still be
"WH/Stock"
The compute method is incorrect. It uses the package location to define
the source location of the package level. However, once the picking is
processed, this package has moved so using its location to define the
source location doesn't make sense anymore.
OPW-2754179
closesodoo/odoo#84709
X-original-commit: 239898ed699d98ff185f6a18fc5a8529e126cecb
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: odoo/odoo#80434
The packages reservations are not correctly done in case of a backorder
To reproduce the issue:
(Use demo data)
1. In Settings, enable:
- Delivery Packages
- Multi-Step Routes
2. Edit the warehouse:
- Outgoing Shipments: 2 steps
3. In Operations Types > Delivery Order, enable:
- Show Detailed Operations
- Move Entire Packages
4. Create a Pick P:
- 1 x [DESK0004] Desk
- 1 x Large Cabinet
5. Put each product in a separate pack
6. Validate P
7. Create a Delivery Order (Planned Transfer):
- 1 x [DESK0004] Desk
- 1 x Large Cabinet
8. Mark as TODO, Check Availability
9. In Detailed Operations, mark one of the packs as Done
10. Validate the DO, Create a backorder
Error: The not-yet-done pack is still on the delivery order and its
status is "Reserved". This line shouldn't be present anymore. Moreover,
the backorder has a line for this pack, its state is "Draft" (instead of
"Reserved") and the state of the BO is Ready.
When creating the backorder, the packages levels of the not-yet-done
moves are transferred to the new picking (i.e., the backorder) However,
these moves does not have a package level defined (due to
9d758fa2e1). Therefore, when checking the
packs:
https://github.com/odoo/odoo/blob/e7450bee8f018a5334d9628235824f2fc6f32cec/addons/stock/models/stock_picking.py#L822-L832
`package_level_ids` is empty, so a new `stock.package_level` is created
(instead of using the one of the initial delivery order). And
`move_lines_to_pack` is empty too, so the new `stock.package_level`
won't have any move lines and its state will be "Draft"
We should rather transfer the package levels of the moves' lines.
OPW-2659176
closes#77509closesodoo/odoo#80072
X-original-commit: 4fd5cd6f940575090021dedd2159d050b594dd69
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Co-authored-by: Adrien Widart <awt@odoo.com>
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>
Since return moves are linked to their original move, it's easy to
manage reservation in those case. We just don't bypass the reservation
when it comes from a reservation outside our stock in order to manage
the computation on linked moves and reserve pieces that were not yet
return.
Also add a return picking type for 2 reasons:
- Allow to select existing lot.
- Display reserved move line for an incoming picking.
Note that this picking type is just a default configuration and could be
modify by the user without any issue.
closesodoo/odoo#64384
Related: odoo/enterprise#20605
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
A stock move with 0 qty in initial demand is considered as 'ready'. But
those stock moves should be excluded of the picking state computation to
not false the readiness of the picking, especially if the delivery
policy is set to 'direct'.
opw-2611018
closesodoo/odoo#75589
X-original-commit: bc7198961583562243b393bd8cd009c5e7220ad0
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Currently stock moves are auto-assigned (i.e. reserve free stock) both
when the scheduler is run and when a corresponding stock move that can
assign a move is completed. This strictness was causing issues for
prioritization of moves to assign, for example a picking with a
scheduled_date far in the future could automatically reserve all stock
if it was created before another picking that an immediate
scheduled_date. To ease this, an extra setting has been added to
stock.picking.type to let users choose how reservations should occur for
moves assigned to that picking_type (or picking with that picking_type):
1. 'at_confirm' = automatically when:
- stock is available when the move's associated picking/MO is
confirmed,
- when new stock becomes available,
- when the scheduler is triggered (+ stock available).
2. 'manual' = user must always manually click "Check Availability"
button (scheduler will no longer reserve).
3. 'by_date' = automatically when within the move's reservation_date
and:
- stock is available when the move's associated picking/MO is
confirmed,
- new stock becomes available when move is already confirmed, or
- the scheduler is run (+ stock is available).
'by_date' has an extra option of # days before the move's scheduled
date that affects the move.reservation_date.
Task: 2359317
Upgrade PR: odoo/upgrade#1868
ENT PR: odoo/enterprise#15050
Behavior prior to this commit:
In the following scenario:
- order of 10 widgets
- delivery using an entire package of 15 widgets (by adding the package
under the "Packages" list and checking the "Done" checkbox)
The delivery, when validated, does not update the delivered quantity on
the sales order, and generates a warning about not shipping enough
product. We expect instead the sales order to be updated with the
actual quantity that was shipped (i.e., 15), and a warning about
shipping too many products.
Additionally, when adding the package, the picking reverts to a "Draft"
state and we have to click "Mark as Todo" again.
Behavior after the commit:
When adding one (or more) entire package in the packages list, and
marking them as Done, their entire quantity will be marked as Delivered
on the Sales Order, and no warning about not shipping enough product
will be shown. Of note, if the package also contains products that are
not on the SO, they will be marked as shipped as well (in that case the
picking will indeed revert to draft since we will have added a new
product). However they will not be automatically added to the SO.
Technical details:
When adding a package under the picking it needs to, eventually, reflect
on a stock move. Prior to the commit, the system would add a new stock
move. This had 2 problems:
- the generated move did not carry back to the SO,
- it would flip the picking back to draft (under certain circumstances
it was possible to circumvent that and have a package level, and a move
line, that was not tied to a stock move and thus would automatically
reattach itself when the picking was validated, and sort of work, but
it was more of a happy accident and relying on the steps being followed
in a very precise order).
With this commit, we do not generate the stock move as soon as the
package is added. Instead, that is done when the picking is marked as
done, either by relating it to an existing stock move, or by generating
a new one at this time.
opw-2367893
closesodoo/odoo#62112
X-original-commit: 173bfe6764a554d601d2c7edac2a4c79e2faaa83
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
Steps to reproduce:
* In Inventory, activate multiple warehouses and storage locations, multi-step routes, Delivery packages
* On the main warehouse, activate 3 steps delivery
* Create a stockable product A
* Update quantity on hand: 100 units in a package PACK1 in Stock/Shelf 1
* Create a new Pick transfer with one move: 120 product A
* Set the transfer as todo and check availability: a move line for the 100 units from PACK1 is created
* Edit the move line: set a destination location, **change the result package to PACK2** and set a qty_done
* On product A, update the quantity on hand: add a *new* package PACK3 of 20 in Stock/Shelf 1
* On the transfer, click on check availability
Current behavior:
* A new move line is created for the 20 units from PACK3 to PACK3: ok
* The move line edited before for the 100 units has its result package **reset to PACK1**
Expected behavior:
* A new move line is created for the 20 units from PACK3 to PACK3: ok
* The move line edited before for the 100 units has its result package kept to **PACK2 as edited by the user** who decided to open the package already
Short analysis:
At the end of `StockMove._action_assign()`, the method `StockPicking._check_entire_pack()` is called. For each package moved by a move line, this method checks if the package is entirely moved (sum of quants == sum of move lines). The check is done by `StockPicking._check_move_lines_map_quant_package`. When the sums match, the package level of the move lines is created or updated. When it happens, it writes the package in the `result_package_id` of the related lines.
It should not change the result_package_id if it was already set.
Thinking further, maybe it should not consider lines with a `qty_done` in `_check_move_lines_map_quant_package`: users already picked these lines, if they decided to empty or change the `result_package_id`, a new check of availability for the remaining quantities should not change these lines.
opw-2346608
Fixes#58491closesodoo/odoo#60025
X-original-commit: db262912eb716aed1c42be8a9d59c25bdfa400e0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Change the default rouning digits of all UoMs to be two, also change the
decimal.precision of UoM to be two. Adapt all the tests.
Also to avoid hardcoded digits in `should_consume_qty` widget.
PR #56000
X-original-commit: 460ec0402a2352a5b179d81935f7230f6bc97cb7
This commit sets up the logic and adds the button for "Put in Pack"
action that already exists in stock.picking. Reuse/extension of logic
from stock.picking reused where possible, including extension of pack
wizard to handle products with different destination.
Note that logic to handle "Delivery Packaging" wizard when "Delivery
Methods" is active was purposely not extended to work correctly in batch
pickings due to complexity of adding in a new module just to handle
conflicting carrier_ids across pickings in the same batch. It is
expected that this use case will not occur except in case of user error.
Additionally, stock.picking implementation of 'put_in_pack' method has
been renamed to 'action_put_in_pack' to have consistent naming (and
support enterprise level code).
Part of "1. Improve Batch Pickings" specification of overall barcode
improvements task.
Task: 1884520
Enterprise PR: odoo/enterprise#12086Closes: odoo/odoo#55096
Write is overridden on reserved move lines to make sure the quants are
correctly updated. It is divided in two parts: if you update the reserved
quantity and if you update a characteristic. If somehow both are updated
in the same call (which doesn't happen in the standard interface), then
the quants are unreserved two times, which is wrong.
This issue showcased by [0] and on databases where the reserved
quantities are made editable by customization.
We grouped the two update in one, such as the TODO indicated us since a
long, long time.
We removed `result_packaged_id` from the trigger because it should not
impact the reservation whatsoever.
We needed to remove a tricky logic in the stock move's backordering part
but it was fishy anyway.
[0] eac8c06e2233
closesodoo/odoo#53928
X-original-commit: 507101434f9221f2cfa6de66e1952676fff322fd
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
0. Create 2 Products A & B
1. Open Inventory > Configuration > Settings and flag the following
checkboxes:
Delivery Packages
Product Packagings
Storage Locations
Multi-Step Routes
2. Go to Inventory > Configuration > Warehouses and open YourCompany WH
3. Set 'Incoming shipments' to 'Receive goods in input and then stock
(2 steps)'
4. Go to Inventory > Configuration > Operations types.
5. For 'YourCompany: Delivery Orders' and 'YourCompany: Internal
Transfers”, flag the following checkboxes:
Show Detailed Operations
Move Entire Packages
6. Go to Inventory > Configuration > Locations and open 'WH/Stock'
7. Edit and create a new 'Put Away Strategy' called 'Stock'
8. Add a new rule:
Product A, with Location 'WH/Stock/Shelf 1'
Product B, with Location 'WH/Stock/Shelf 2'
9. Go to Inventory > Operations > Transfers to create a new picking.
10. Select 'YourCompany: Receipts' as 'Operation Type'
11. Under Operations, add a new line with product A and an 'Initial
demand' of 20
12. Save and 'Mark as to do'
13. Enter in edit mode and under 'Detailed Operations', set a quantity
of 11.0 on 'Done' and click on 'Put in Pack'
=> A new pack is created
14. Repeat 13 with a quantity of 9 to create a new pack
15. Save and click on 'Validate'
16. An existing 'Internal Transfers' with the two created Packages
having following properties:
From: 'WH/Input
To: 'WH/Stock/Shelf 1'
At this point, the behavior is expected.
17. Cancel the picking created
18. Create a new picking:
Operation type: 'YourCompany: Internal Transfers'
Source Location: 'WH/Input'
Destination location: 'WH/Stock'
19. Under Operations, add two new lines using the packages os step 16.
20. Save and 'Mark As To Do'. The two packages have the following
properties:
From: 'WH/Input
To: 'WH/Stock'
We can see a difference in behavior. The picking created from a 'Pull'
mechanism applies the putaway strategy to the package, while the picking
created from the 'Push' mechanism doesn't apply it.
We make the behavior consistent. Moreover, in case the package contains
products having different destination locations, the destination of the
picking is kept.
opw-2146583
task-2148494
closesodoo/odoo#45549
X-original-commit: 705bdaa4ae5251b05bc2bbba02f2ca561ca00bbc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
- Create a move line from stock to shelf1 with PACK1
- Create a move line from stock to shelf2 with PACK1
- Validate
It should be be blocked. The contents of a package should all
be in the same location since the pack itself is in a location.
It's due to commit 78d6f46 that fix a rounding error.
However it should check for quants that have quantity since they
represents the package content.
closesodoo/odoo#42134
X-original-commit: 78fba949790f2b1ecd3ba1bf60fb34c30d17769e
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
`action_done`on pickings should be a private method,
and called only trough the picking validation process.
task-1938108
closesodoo/odoo#39174
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
rev[0] added the possibility to put in pack without setting any done
quantity on move lines but when the reserved move lines are hidden
(thanks to rev[1]) it got confused on which move lines to work on.
[0] e03c1a836f
[1] ffd5d5a097closesodoo/odoo#36832
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When validating a picking from location A to B, location A's quant.quantity
may be updated to a quantity != 0 with _update_available_quantity.
This is because the quant value is written as quantity - float_round(quantity).
As a result, the consistency check would find two existing quants, and raise.
Therefore the picking cannot be validated.
opw 2040091
closesodoo/odoo#35913
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Ensure proper domains are applied and enforced on relation fields thanks
to the `check_company` attributes.
product.template
- make responsible a property field in order to ensure proper next activities when a product
is used between multiple companies
stock.putaway.rule
- added a company_id field
stock.move.line
- company_id is not related anymore since a move line can exist without a move until its validation
stock.package_level
- added a company_id field
stock.picking.type
- company_id is now required
stock.production.lot
- added a company_id field, adapted the constraint accordingly
stock.quant
- check the consistency only in inventory mode
stock.quant.package
- company_id is now empty if the package is empty
stock.picking
- company_id is now related to the one of its picking type
Added some tests.
Moved stock_traceability in the `report` directory.
Removed useless /tests/tours/route.js.
task-1985992
before on runbot:
odoo.addons.stock.tests.test_move tested in 31.79s, 63166 queries
odoo.addons.stock.tests.test_move2 tested in 33.69s, 68046 queries
odoo.addons.stock.tests.test_quant tested in 8.48s, 15351 queries
odoo.addons.stock.tests.test_stock_flow tested in 16.99s, 31506 queries
amounting to 90 seconds on a build page
after om runbot:
odoo.addons.stock.tests.test_move tested in 12.41s, 24197 queries
odoo.addons.stock.tests.test_move2 tested in 13.55s, 24254 queries
odoo.addons.stock.tests.test_stock_flow tested in 9.74s, 15795 queries
amounting to 37 seconds on a build page
Use savepoint case instead of transaction case.
We took the opportunity to rename the master data more appropriately,
which results now in a bigger diff in TestMove and TestQuant. In
TestQuant, the master data creation had to be moved in the setUpClass
too.
We removed test_shipment as test_backorder_1-4 in tet_move_2 covers the
same parts of the code.
Some tests had to be adapted because they relied on the buggy behavior:
this was particularly the case when they tried to write on readonly
related fields.
closesodoo/odoo#32460
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When the move lines in a move are all linked to a package level,
we don't want to see the move anymore. We cannot keep only a domain on
moves their-selves as it depends on the move lines linked to it.
So we use a compute field to filter the moves to show, and the inverse
function just appends the new/modified moves to the move_lines.
TASK-ID: 1865671
Accessing one2many items by their index seems to produce issue regarding the order. This commit fix the potential issue in the test by summing the two quant quantity instead of comparing them one by one.
closesodoo/odoo#27627
Purpose : during a transfer, if some move lines have different
destination locations and the user click on 'put in pack' button, an
warning is triggered. This message, saying : 'You cannot put in the same
pack move lines having different destination location', is replaced by a
wizard allowing the user to choose a unique destination location. This
location will be set as location_dest_id on all transfer's stock move
lines. After that, the wizard calls again the _put_in_pack() method
where all the logic remains the same.
Task : 1872345
When a package level is confirmed and is set to done, if you try to
reserve it after, it won't have the correct location of the reservation
because there are still move lines (forced) with the wrong location.
We added a model to work easily with packages, using the quant packages
was not a good solution to move entire package and plan package moves,
because we always had to give the picking in context, and create some
move lines, so it was only possible when state was assigned (when move
lines exists)
So we created a model package level, linked to picking, move and move
lines allowing to easily plan package transfer and put in pack.
Moves UoM models, test and data to a new addon in
order to be able to use uom without product.
A simple example is be to be able to use UoM for
timesheets.
This commit only move code, and adapt xml ids
without chaging any feature or functionnal
behavior.
Note: 'product' module now depends on new
'uom' module.
Adrien Widart