When:
* using a 3 steps delivery
* creating and confirming a sale order
* opening the transfer using the "Deliveries" button on the sale order
* clicking on the "Release" button

The pickings generated by the release are incorrect.
This is because the smart button of the sale order view adds several
"default_" fields that are then interpreted during the creation of the
chained pickings.

Clean these fields from the context.

When stock moves have been released, their 'need_release' flag must be
set to False. Due to a coding mistake, they were not. The most visible
effect was the "Release" button still visible on transfers and moves,
but other vicious effects can't be excluded.

The issue come from an inversion in the order of the list comprehension,
added up to the fact that the 'procurement' variable name was recycled
from the code above: 'procurement' was always equal to the latest
procurement used in the loop before the list comprehension.

To reproduce

* Order 100x [E-COM10]
* Update quantities in stock to have 70 [E-COM10] in Stock/Shelf 1
* Release the moves

Actual result:

2 transfer, the backorder for the waiting 30 [E-COM10] has no backorder
link with the original transfer

Expected result:

2 transfer, the backorder for the waiting 30 [E-COM10] has a backorder
link with the original transfer

Current behavior:

When we release an OUT stock move, the OUT transfer is set to printed.
The origin transfers (e.g. Pick+Pack) are not.

Expected behavior:

When we release an OUT stock move, all the origin transfer (e.g.
Pick+Pack) are set to printed.

Reason:

The original reason for setting "printed" to True, is that when
"_assign_picking()" is called on a stock.move, the stock.move can be
added only in a stock.picking which is not printed yet. In other terms,
"printed" means the transfer has been started and shouldn't be modified.
When we "release" moves, we actually planify the work to be done, and if
we release again new moves, we don't expect transfers of the 2 waves of
releases to be merged together.

If we set the flag "printed" on the Out transfer only, we can end up
with one Packing transfer leading to 2 Out transfers, which generally
doesn't make sense.

Add relocation rules for moves.

Some use cases:

* Handle all the replenishments at the same place
* Trigger minimum stock rules or DDMRP buffers in one location

Behavior:

* When we try to assign a stock move and the move is not available, a
  rule matching the source location (sub-locations included), the picking
  type and an optional domain is searched
* If a relocation is found, the move source location is updated with
  the new one
* If the move was partially available, it is split in 2 parts:

 * one available part which keeps its source location
 * one confirmed part which is updated with the new source location

Currently translated at 100.0% (28 of 28 strings)

Translation: wms-13.0/wms-13.0-stock_move_source_relocate
Translate-URL: https://translation.odoo-community.org/projects/wms-13-0/wms-13-0-stock_move_source_relocate/es_AR/

To remove the duplicate implementation of
StockLocation.is_sublocation_of()

[UPD] Update stock_move_source_relocate.pot

Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.

Translation: wms-13.0/wms-13.0-stock_move_source_relocate
Translate-URL: https://translation.odoo-community.org/projects/wms-13-0/wms-13-0-stock_move_source_relocate/

Update stock_move_source_relocate/models/stock_move.py

Co-authored-by: Sébastien Alix <[email protected]>