Currently on stock moves, product_uom_qty indicates the demand qty
before the move is done and it indicates the acutual done qty when
the move is done.
As a result, when validate a stock move with qty_done !=
product_uom_qty, a new move is always created for the difference.
And the product_uom_qty of the original move will be changed to match
qty_done.
In this commit, we change to that product_uom_qty will always indicate
the demand qty, and qty_done will always indicate actually done
quantity.
To do that, when underconsumption, we won't split the move when no
backorder. and when overconsumption, we will always merge the extra move
back to the original move.
Task-2695732
Part-of: odoo/odoo#130342
When processing a batch without backorder, if a picking is not fully
done, it will be removed from the batch
To reproduce the issue:
1. Create two delivery pickings P1 et P2 with demands = 5
2. Have the quantity in the stock
3. Add both to a batch and confirm it
4. Set the done quantity on P1
5. On P2, set a done quantity to 4
6. Process the batch without backorder
Error: Both pickings are done, and so does the batch, but P2 is not
linked to that batch anymore
When processing the batch, we will call `button_validate` on the
pickings recordset
https://github.com/odoo/odoo/blob/213b74be16cecc50e6e99c00f47786a9cbf327a8/addons/stock_picking_batch/models/stock_picking_batch.py#L252-L258
Later on, there is an override of `StockPicking._action_done` in the
batch module. In this override, once we have called `super`, we then
ensure that all pickings of the batch are done, else we detach some
of them:
https://github.com/odoo/odoo/blob/213b74be16cecc50e6e99c00f47786a9cbf327a8/addons/stock_picking_batch/models/stock_picking_batch.py#L252-L258
But here is the issue: as mentionned above, we first call
`button_validate` on pickings recordset. In this method, we will
call `StockPicking._action_done` two times:
https://github.com/odoo/odoo/blob/ca168f7fbcbb8a300a8fa0b46f79a6c116b5aa93/addons/stock/models/stock_picking.py#L1088-L1089
The first time, for the pickings without the backorder option (P2 in
the above use case), and the second time, for the pickings with the
backorder option (P1 in the above use case). As a result, during the
first call, we reach the override in batch module, and of course, P1 is
not yet processed (it will be done during the second call of
`_action_done`). Therefore, we think there is an inconsistency, and we
detach P2.
OPW-3346255
closesodoo/odoo#132037
X-original-commit: c2817285adf9dd44ad7155963f08d324995ba072
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
This commit changes the process flow of stock pickings. A new picking will
always be created in immediate transfer mode and 'ready' state. From
their, it can be validated directly or 'reset to draft'. This second action
switch the immediate mode to planned mode and reset the state as draft.
From their the classical workflow is processed
confirm -> (assigned ->) validated
Task: 3256447
Part-of: odoo/odoo#117513
By only auto-batching pickings that are ready, it allows, if you reserve
X days in advance, to make batches for those periods, almost like batch
on the scheduled date.
Part of task-3218314
Part-of: odoo/odoo#119381
In `_check_backorder`, changes the condition so it checks if the qty
done is enough compared to the actual reserved quantity (instead of the
demand).
Also, removes an unused bloack of code and makes minor visual changes.
task-3076044
Part-of: odoo/odoo#109511
Steps to reproduce the bug:
- Enable “batch transfers” in the inventory settings
- Create a new warehouse “WH2”:
- Enable “Resupply From” option
- Enable “3steps”
- Go to the operation type “internal transfers” of WH2:
- Enable “Automatic Batches”
- “Destination Location”
- Create two storable product “P1” and “P2”:
- Route: warehouse # 2: Supply Product from YourCompany
- update the Qty to 10 in wh/stock
- Create a replenishment for “P1” and “p2”:
- Location: WH2/stock
- Preferred route: warehouse # 2: Supply Product from YourCompany
- Procurement Group: select two different procurement
- min qty: 1
Problem:
Two internal pickings are created for “P1” and two others for “P2”,
because two different procurement:
- from “input” to “quality control”
- from “quality control” to “wh/stock2”
But as the pickings have the same location destination, two batches
are supposed to be created to group the pickings.
The `_find_auto_batch` function is triggered when the picking is
confirmed:
https://github.com/odoo/odoo/blob/16.0/addons/stock_picking_batch/models/stock_picking.py#L120
but since the pickings are not confirmed, the function is not called:
opw-3076077
closesodoo/odoo#111716
X-original-commit: 324298967cb63d7de1144c8aee2039119443e60c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When a backorder was created and the auto_batch was activated for this
picking_type, no batch was assigned to the created backorder, even if it
matched the auto-batch criterias.
Now when a picking is done, we check if backorders were created. If they
are eligible for auto-batchs (given their picking_type, etc.), they also
get the auto_batch done for them.
We can't simply use the previous picking's batch, because if this batch
is now done, then introducing a non-done picking into the batch would
raise an inconsistency between the pickings' states and raise an error.
Removes the old override of backorder confirmation as now batch
dissociation is done in the picking's 'action_done()' override.
Allows the validation of a batch that has pickings 'waiting for another
operation', as they now will get removed from the batch in the process,
no longer blocking the batch's validation.
Finally, makes that pickings that had no quantities done when validating
a batch aren't cancelled when selecting 'No backorder' in the
confirmation wizard, but are instead removed from the batch.
Task-2971346
X-original-commit: 1720840b7bd9b3e3e90f7cf860f60f1d0746ce63
Part-of: odoo/odoo#102382
Steps to reproduce the bug:
- Create a batch transfer with several pickings
- Confirm it
- Delete all the pickings > save
Problem:
The batch does not cancel as it should’ve been
A batch without transfers cannot be confirmed, so it makes no sense to leave a confirmed batch without transfers
opw-2792471
closesodoo/odoo#90104
X-original-commit: dcbf08edbb3a1ec49e84f0828b8f49ac4f836c25
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
If a picking is in a batch, the point is to process it as a whole. Yet,
it is possible to validate a single picking (putting it in a 'done'
state), inside of an 'in_progress' batch. This raises inconsistencies
between the state of the batch as a whole and the state of some of it
pickings.
Therefore, when a single batched picking is validated in a batch that
still contains other non-done pickings, the picking is removed from the
batch.
closesodoo/odoo#85324
X-original-commit: e9602d6b28331f68a83b5ce8a06a2ffc8ac3453d
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Allow confirmed pickings to be automatically put into batches that match the
group criterias defined in their picking_type.
The pickings can be grouped by :
- Contact
- Destination Country
- Source location
- Destination location
To avoid having batches too big then, some restrictions can be put over
the auto-batcher to restrict the size of a batch :
- Max moves per batch
- Max pickings per batch
Task-2670580
Part-of: odoo/odoo#81533
In a lot of test class, we use `setUp` instead of
`setUpClass`. `setUp` is execute for each test method and `setUpClass`
will be execute only once by Class (and use savepoint + rollback).
Then change setUp into setUpClass reduce the time to make all tests
and avoid to repeat this error for the future.
closesodoo/odoo#78082
Related: odoo/enterprise#21563
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
If a picking is totally empty (no move line with quantity recorded) in a
batch at validation. This one will be ignored by the immediate transfer
mechanism as well as the backorder creation. It is simply remove from
the batch.
closesodoo/odoo#63291
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit loosens 2 things:
1. A batch can now be deleted for all statuses except 'done'
2. Cancelled batches will now remove links to any pickings assigned to
it (so they can be more easily reassigned in barcode app)
closesodoo/odoo#68898
Task: 2486993
Signed-off-by: Arnold Moyaux <amoyaux@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
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
This commit adds a "Scheduled Date" field to the batch pickings. Logic
behind this date is a bit tricky:
1. If "Scheduled Date" is edited directly in batch then this date will
also be applied to all of its picking's "Schedule Date"s.
2. If "Scheduled Date" is not edited directly in the batch, then this
date will be the earliest date of its assigned pickings and pickings
will maintain their original scheduled date' including if picking
scheduled date is changed.
3. If "Scheduled Date" is not edited directly and all pickings are
removed or there are none then date will default to no date.
First cut of test for scheduled_date logic has also been added. Update
will be needed for testing onchange logic since it is currently not
supported by the tests.Form due to M2M widget used with O2M picking_ids
(M2M widget is used for when doing a "Add a Line" transfer to a batch
in backend).
Additionally this commit adds the 'scheduled_date' and 'operation_type' to
the kanban view.
Part of "1. Improve Batch Pickings" specification of overall barcode app
improvements task.
Task: 1884520
Enterprise PR: odoo/enterprise#12086
Upgrade PR: odoo/upgrade#1569Closes: odoo/odoo#55096
followup of rev [0]
If these wizards are called on multiple pickings, display the list of
the pickings that could be impacted and allow to select which one should
be impacted.
We also adapt the sanity checks at the start of `button_validte` in
order to specify the concerned pickings if needed. We do not enable the
multi behavior for batch at the moment, so it's only enabled for the
validate multi in the list view.
[0] 6ab4b0d496
task-2069646
closesodoo/odoo#41497
X-original-commit: ff276c6484b138982f185ec9c832f2dbf25baaef
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This class referenced demo data but even if they weren't installed, the
tests were passing. Remove the definition and usages.
closesodoo/odoo#35343
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
`_action_done` could unlink a quant. This happens when moving a product from a
location to another one and makes null the quantity of this product in one of
theses locations. In this case, we unlink the quant because it is now useless
and could be confusing on reports based on quants.
The unwanted side effect is that unlinking a record will invalidate the cache. In
some pathologic cases, like making an inventory adjustment of 600 products
and reseting their quantity back to 0, the time of the operation is around 15
minutes. With this patch that tries to work carefully with the cache invalidation,
the same operations takes around 15 secondes.
This commit do not unlink quant anymore, instead it use a 'garbage
collector' on quants without quantity. The garbage collector is trigger
on the scheduler and when the user open the inventory view.
Previsously picking batch done button automatically run backorder
for picking that need and set a quantity done for picking without it
This commit changes the function done for picking wave in order to
call the needed wizard(set qty_done automatically or asking for a
backorder). Also it override the immediate transfer wizard in order to
pass the picking to backorder found in done function through the process
action.
pick_to_backorder_ids is needed in immediate transfer since we need to
pass the backorders from the done function in stock_picking_batch
through the immediate transfer wizard.