On a delivery, when changing the initial demand of a stock move, if its
value was 0 and becomes > 0, its state will be 'Partially Available' but
the reserved quantity will still be 0.
To reproduce the error:
1. Create 2 products P01, P02
- Product Type: Storable
- Qty On Hand: 1
2. Create + Confirm a SO with 1xP01 and 1xP02
3. Open SO's delivery
4. Unlock, set P01's initial demand to 0, Save, Lock
5. Unreserve, Check Availability
6. Unlock, set P01's initial demand to 1, Save
7. Click on PO1 line
Error: The stock move state is "Partially Available", but the initial
demand is 1 and the reserved quantity is 0. It should be "Waiting
Availability"
On step 5, since the wanted quantity of P01 is 0, the state of the stock
move becomes "Available". Then, when increasing the requested quantity,
the state automatically becomes "Partially Available" because the module
does not consider the case where the state is "Available" with a
reserved quantity equal to 0.
OPW-2488580
closes odoo/odoo#71371
X-original-commit: 5773a1e0658d014e6d93a8728f324d76f51fbe25
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
- Install stock
- Go to Inventory > Configuration > Settings and enable "Lots" and "Storage Locations"
- Create a Product tracked By Lots (i.e. Product X)
- Go to Inventory > Operations > Inventory Adjustments
- Create an Inventory Adjustment for Product X:
Product | Location | Lot/SN | Real Quantity
-------------------------------------------------------------
Product X | WH/Stock | LOT 01 | 20
Product X | WH/Stock | | 10
- Validate Inventory
- Go to Inventory > Operations > Transfers and create one:
* Source Location: WH/Stock
* Destination Location: WH/Stock/Shelf1
* Operation Type: Internal Transfers
* Operations:
[Product: Product X, Initial Demand: 25]
- Save Transfer, Mark As Todo and Check availability
- Click on list icon of Operation line for Product X to display Detailed Operations
- 20 units of LOT 01 and 5 units without lot have been reserved
- Set LOT 01 for the 5 reserved units without lot and confirm
- Open Detailed Operations again
- There are now 20 units of LOT 01 and 5 units of LOT 01
- Remove the row with 5 units and confirm
- Check availability and open Detailed Operation
- There is now only a row with 25 reserved units of LOT 01
- Unreserve
The following errror is raised:
"It is not possible to unreserve more products of P than you have in stock."
It happens because the system is not able to manage quants with lots and
wihtout lots at the same time. When modifying the move line to 25
reserved units. It's composed of 20 quants with lot and 5 quants without
lot. And when unreserving it will check if there is a quants with 25
units with the lot and if it's not found 25 units without lot. But never
25 units of quants with lots and without lots.
opw-2419444
Close #64497
closes odoo/odoo#66347
X-original-commit: 3b59d0b12bc9a80e325aa07d004ed9cf9d85f857
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
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#12086 Closes: odoo/odoo#55096
1) Create a stockable product > Add some quantities on hand 2) Edit this product > set it as a consumable or service 3) Create an inventory adjustment on all products Error will raise "Something went wrong! You can only adjust storable products. This occur because when switching product type the available quantity was not cleared, so it will get in the next inventory, but only storable products can have inventory. So the product should to have no quantity left before switching type opw-2300478 closes odoo/odoo#55062 X-original-commit: be17e31307070498ba9ac7dc594443730caa7404 Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com> Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
mismatch on the move lines used by the compute. task-2241471
Let's say we have a chain of move wh1 - intercomp transit -> intercomp transit - wh2 The second move will be reserved according to what the first move brought since they are chained. This behavior resulted in rev[0] which tries to work around the ir.rule limiting the access of stock.move and stock.move.line records in multi-company environment. This patch wasn't perfect since, if the first move brought a lot, the second move will reserve this lot and it will result in another access error since the lot will still have the company of the first move. We fix this by implementing the following logic: receiving from another company should behave the same as receiving from the supplier, no reservation is applied. We fix this by marking the inter company transit as `_should_bypass_reservation` and we break the move chain if the pull/push rule create an intercompany chain. [0] 6ff34073153767d449804669f31e26c04de0a670 closes odoo/odoo#45601 Task: 2160847 X-original-commit: 67b45da9d877a5a1bb9adb3ce14051e01f67045f Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Create an immediate transfer for a receipt, add a move, set a quantity done and due to rev[0], an initial demand is set, then _autoconfirm_picking is called and action_confirm of picking calls _action_assign if the location source bypasses the reservation. Set again an inferior qty_done, the initial demand is also updated due to rev[0] and somehow the system tries to write on a now unlinked move line. fixes - never reserve an immediate transfer - never update the initial demand if the move is reserved to fix the existing databases. - adapt _compute_state so that immediate transfer moves considered reserved so that they're always "ready" - adapt the test that was working on an immediate transfer picking and setting the initial demand while it's not possible through the interface, the user can only set the done quantity. [0] 8303b1a closes odoo/odoo#45317 X-original-commit: 357e0a862744f1bc23a9643a1822d2ee4a2eb7a2 Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this patch, validating an unreserved move of a dozen while 12 units were reserved resulted in a quant with 0 unit as quantity and 11 units as reserved quantity. closes odoo/odoo#45132 X-original-commit: bf7d76a7127521ba17f29bc470c3d551cc9988d5 Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When a user unreserve a picking or a move it will drop all the linked move lines. However it could happens that some move line already have a done quantity and the user won't lose this information. This commit filters move lines in order to only drop the move line without quantity done and remove the reserved quantity on others. Joint work with William Henrotin <whe@odoo.com> task-2069646
Before this commit, a move can be 'assigned' even if it has no reserved
quantity.
How to reproduce:
- For a tracked product, add some quantities for a LN/SN. Create an
another LN/SN with no quantity;
- Create a delivery for this product;
- Confirm it and check availability;
- On the move line, change the SN/LN for the one without quantity.
--> The move has no reserved quantity but is still marked as
`assigned`.
task-2171546
closes odoo/odoo#44145
X-original-commit: d5e70fa9778240b23515cea6ab1a3d0a674ac940
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Co-authored-by: sle-odoo <sle@odoo.com>