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>
So we have to adapt
- the sanity checks
- the immediate/backorder wizards
- split the call to _action_done with and without backorder
This is a preliminary work to remove all the override in
stock_picking_batch and to allow choosing the pickings to immediate or
backorder directly in the wizards.
Before this commit, both wizards were calling _action_done and one
another. We make them go back through `button_validate` so that it is
more sane to handle and allow future extensions to add pre-action done
wizards.
Also the first part of button_validate is some sanity check. We adapt
them to be multi (inside of a loop over self) without any other
changes.
Now the wizard can work on the records (immediate: write the done
quantities) or work with the context (backorder: picking ids to not
backorder in the context).
Also we adapt the stock sms weird wizard (a confirmation wizard but the
feature is auto installed? wth). Now there it isn't manually called in
the middle of button_validate but it uses the pre_action_done_hook.
task-2069646
`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>
- Sell 4 units of a product in stock
- On the picking, create a scrap for 1 unit
- Validate
- In the immediate transfer wizard, validate
The scrap is reset to zero.
This is because the wizard overwrite the done quantity with the reserved
quantity (0.0).
If the move is already done, there is no reason to overwrite the
quantity.
opw-1958514
closesodoo/odoo#32410
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before the patch, validating a picking where one of its move do not
have any quantity done nor quantity reserved resulted in the complete
validation of the said move. This doesn't make sense and does not do
what the help in the wizard indicate (process only *reserved* quantities).
We also use this patch to clarify what the tests on this workflow is
doing (test_immediate_validate_*). We completely replace the 3 as it was
testing the `force_assign` mechanism, which methods are still present in
v11 but unused. Instead this test is now testing the failing flow this
commit is fixing.
We thus adapt the `process` method of the immediate transfer to only
process the move lines (move line = reservation). We also fix a case
where nothing is reserved and nothing is done. In this case, the
backorder wizard should not opens but instead an UserError telling the
user to either cancel or process something. The testcase for this flow
is test_immediate_validate_7.
With these changes, the test `test_04_create_picking_update_saleorderline`
was failing because one of the items in the so lines was a stockable
product without stock. So before this patch, everything was processed,
now there's a backorder wizard. We complete the patch and duplicate it
with enough products in stock, so that the backorder wizard is not
needed.
opw-815056
opw-808126
The purpose of this commit is to allow future modules that need
immediate transfer and back order function on multiples picking
to do it.
This commit does not modify the behavior of single picking processing
When validating a stock picking there were 2 different cases:
(1) If all qty are equal to 0 it will display a wizard asking
if the user want to set the quantity done to the reserved quantity
for all moves. If the user accept it will automatically perform the
moves after setting the quantity done.
(2) If the user set a quantity on a move, it will check if there is
a need for a back order. If yes it will display a wizard asking if
a back order is needed or not.
However the check if a back order was needed or not was never perform
in case 1. If the quantity reserved was lower than the initial demand
a back order was automatically created.
This commit add the step 2 in the procedure of step 1 (after setting the
quantity done).
The big change is that we have now a many2many between the move and a
one2many between a move and its pack.operation (note: this model is
renamed as stock.move.line in a further commit).
Due to these changes, `action_done` had to be rewritten intierely, as it
depended and stock.pack.operation.lot and stock.move.operation.link,
that are now removed. This method was laregly inspired by the one in the
mrp module, and a further commit will make MRP uses all the core of
stock.
Due to the previous commit that refactored the stock.quant
implementation, the new concept is that the `product_qty` that will
always be in the uom of the quant (`product_qty` is a computed field in
the same style as the one of stock.move).
This commit also implements the logic that a manager is able to edit
done stock.pack.operation.
The stock.move has now a "partially_available" state (it was previously
a flag). The "split_from" field is removed now that we have a many2many
between moves (a sibling move is always a move that was splitted, or
with the backorder_id field).
The done quantity of a stock move is computed across the done quantity
of the move lines. There is an inverse method that allows user to fill
the done quantity directly on a stock move.
The reserve quantity of stock move is computed accross the
`product_qty` of the linked pack operations.
`do_unreserve` will simply unlink the associated pack operation.
Unlinking a pack operation will unreserve.
`force_assign` will mark the move as available, in order to allow the
user to create pack operations (none are created because nothing was
reserved).
`action_assign` is rewritten and splitted in two parts: if the move has
a parent (mto) or not (mts). In the mto, we'll check the available move
lines and only reserve accordingly. In the mts, we'll reserve directly
on the quants.
`action_cancel` has changd a lot: in case of a delivery, the first step
does not anymore propagate cancellation to following moves and SO. As a
result it does not propagate in the other side in case of MTO or production.
It does not delete them if we delete the related sale order for example. In
order to correct this next activities will be added in the future. Technically
action cancel on move is based on procurment rule, this commit will set
the propagate field to false on the rule if the picking_type is 'pick'
or if we are in one step delivery.
We use this commit to reimplement `action_assign` (wiped by the new
quant implentation). A move is reserved if its move lines exist, so we
introduce a one2many between stock.move and stock.pack.operation (note:
a further commit renamed this model into stock.move.line)
We use this commit to implement `action_done` (wiped by the removal of the
models making the link between stock.move and stock.pack.operations). We
can use the one2many to the pack operations.
blabla manymany au lieu de one2many
blabla mto mts
Remove get_ancestors, as orig_ids will be used instead
validation
when we are creating some packe operation with lot name, the
pack_operation are unlink and a new picking is craeted.
This is caused the function _create_lot_for_picking that unlink pack
operation having no quantity reserved instead of ones having no quantity
done.
To fix this we changed product_qty to qty_done and move the code from
action_done of picking to action_done of move
fixup! [IMP] Merge_moves functionality + many2many procurement and original moves instead of one2many
fixup! [REF] stock: basics of new model and stock.move reservation
edit reserved move line
This is the 1st commit message:
[REM] stock: stock.pack.operation.lot, stock.move.operation.link
These models will become useless once a one2many will be made between
stock.move and stock.pack.operation.
The `action_done` method on stock move has been wiped, as it depended
completely on the removed models.
Joint work with Josse Colpaert <jco@odoo.com>, amoyaux <arm@odoo.com>
and Pierre Masereel <pim@odoo.com>
Wizard models are migrated to new API. No change is performed to code
structure or functional structure. Some code cleaning may be performed when
migrating to simplify the code. Other files may be updated due to the move
towards the new API.
General remarks concerning cleaning commits preparing the stock migration
=========================================================================
Small update / cleaning before moving and migrating. This commit contains
the cleaning of stock_picking_type and stock_picking models.
The first cleaning performed is to clean methods having a browse record or
a list of records replacing ids parameter. Those are converted into classic
old API methods using cr, uid, ids. This eases the migration as they are
then migrated into multi methods.
Another cleaning concerns naming things. Some methods are renamed to ease
the code readability. Some parameters are also renamed as well as some
variables. This kind of change is performed only when the readability
is improved. Otherwise the code is kept as it is to avoid rewriting too
much of the code.
Finally unnecessary stuff is also removed. This concerns dead code (methods
not used in community nor in enterprise) and unnecessary code splitting
(tools methods called once without real added value are directly put into
their called method).
- stock.move: no specific changes; note that a method called only in mrp
has been moved to mrp.
- product: no specific changes
- config settings: no specific changes
- wizards: no specific changes
stock.quant main changes
========================
- ``apply_removal_strategy`` method updated to return only the removal
strategy instead of having a mix of several things (overrides updated)
- ``quants_get_**`` methods renamed to ease code understanding
- quants_unreserve from stock.quant to stock.move model because its primary
record is a move, not quants
stock.inventory and stock.inventory.line main changes
=====================================================
- stock.inventory: ``move_ids_exist`` field remove. Unused.
stock.picking and stock.picking.type main changes
=================================================
- stock.picking: ``move_lines_related`` is removed. Indeed it is used only
to display a slightly different view of moves contained inside a picking.
However this field causes a lot of issues when migrated into the new API.
The view is updated to keep the same look and feel while avoiding an
unnecessary field.
- stock.picking.type: complete_name field is removed. Using display_name is
sufficient for the existing use cases.
stock.warehouse and stock.orderpoint main changes
=================================================
- stock.warehouse: removed ``resupply_from_wh``, unused field
stock.pack.operation main changes
=================================
- stock.pack.operation: ``processed_boolean`` fields renamed to ``is_done``
to match its use in the code.
stock.location main changes
===========================
Note that in this commit a strange override in create has been replaced by a
cleaner override in default_get in order to have something more understandable
procurement main changes
========================
- in this commit some code located in procurement has been moved to the
orderpoint model. Indeed those methods take an orderpoint as main
argument, making it more orderpoint methods than procurement methods
- ``_prepare_orderpoint_procurement`` method has been merged with its
strange override in stock_calendar to have something a bit more modular
When the user validates a picking without going through the manual
reservation process, Odoo tries to assign the picking then performs the
transfer. However, if the picking could not be assigned, no pack
operation is created and the picking will simply be set to done.
The fix raises an error if the picking could not be assigned completely.
Another solution is to use a force_assign instead of action_assign, but
that could lead to the creation of negative stock moves without warning
the user. We therefore prefer to stay on the safe side and force the
user to manually handle the reservation.
Note: the original issue was that the Owner of the picking was not
copied on the quant when validating right away. The reason was that no
pack operation was created.
opw-654423
When scanning multiple serial numbers e.g., the list of pack operations
can become quite long. In order to avoid that, we make it possible
for pack operations to contain multiple lots.
The implementation is done in the way that the links between moves
and pack operations remains the way it was. The important difference
is that on action_done, it will check all the reserved quants and their lots at
once first and only afterwards, it will check the lots one by one to check what
it can reserve.
As the details for the lots for the pack operation became a real object, the wizards related
to the pack operation details are not necessary anymore and were replaced
by a form view of the pack operation.
Pack operations will not appear in a transfer wizard or bar code interface anymore, but
in the picking form itself. Some wizards are still needed however to ask whether a
backorder needs to be created and whether we need to do an immediate transfer
The biggest change in the model is in the picking where the locations of the picking
are not a related anymore, but need to be set. That is why the tests need to be changed.
This allows also to have pickings without moves initially and just move one pack e.g.
Locations won't be visible on stock moves in a picking either. (as they should be those of the picking)
In order to avoid confusion, the pack operations are created immediately when stock is reserved and we
are not waiting until the wizard or the bar code interface is launched anymore.
The recompute button previously in the barcode interface will only appear when the reservation changed
and the user indicated in the pack operations that something was moved already. Otherwise it will
recompute the pack operations. That way the reservation on the stock moves, is reflected by the pack operations.
Return pickings are not confirmed automatically when confirming the return wizard.
That should make it possible to choose another location for the return. (Don't return in output e.g.)
Barcode scanning is not in this commit.
Victor Feyens