[13.0] Add stock_checkout_sync

[guewen]

Replaces #862

Regroup moves at the same location when they reach an operation type.

Example of use case:

• We use several operation types for Picking Transfers (Pick Shelves, Pick Reserve)
• We use several operation types for Packing (Pack, Pack Post)
• The "Checkout Synchronization" flag is activated on the 2 Packing operation types
• The Packing can occur in several areas (Packing/PACK1, Packing/PACK2, Packing/PACK3)

Based on these assumptions, we have these pickings, all for the same order:

• SHELF001, pick 2 goods in the shelves
• RESER001, pick 2 goods in the reserve
• PACK001, pack 3 of the goods (2 from SHELF001, 1 from RESER001)
• PPOST001, pack the remaining good of the reserve

The operator uses the button "Checkout Sync" on a pick transfer,
for instance SHELF001, and select Packing/PACK2 as destination.
We want all the lines that reach PACK001 to be updated with:

• The move lines (except the one that goes to PPOST001) must now reach
  Packing/PACK2
• The same moves' destination must reach Packing/PACK2 as well:
  we constrain the user to move the goods there as we want to move
  all the goods at the same place for the packing.

Works best when used with stock_available_to_promise_release:

• When using the mentioned module, we assume that we release moves (which
  creates the whole chain of moves) only when we know that we have the
  quantities in stock (otherwise the module splits the delivery). Any exception
  (which is now rare when you release this ways) that would lead to a backorder
  is handled by canceling the remaining line.
• When the module is not used, then the destination of the backorders may be
  changed at the same time

Compatible with stock_dynamic_routing.

[grindtildeath]

Looks good overall, just some functions names to fix and questions.

[simahawk]

@guewen had to solve a conflict to make pending merge aggregation work. Fill free to rebase and trash 314f5fb

[sebalix]

The test which fails in stock_available is not related to this PR, I think the variants created in the failing test ( https://github.com/OCA/stock-logistics-warehouse/blob/13.0/stock_available/tests/test_stock_available.py#L31-L55 ) should have different attributes to not trigger the constraint on flush call.

[simahawk]

@sebalix @guewen anything we can do to unlock this?

[guewen]

I fixed the error with stock_available, but we have another unrelated error:

Traceback (most recent call last):
File "/home/travis/build/OCA/stock-logistics-warehouse/stock_vertical_lift/tests/test_inventory.py", line 38, in test_inventory_count_ops
operation = self._open_screen("inventory")
File "/home/travis/build/OCA/stock-logistics-warehouse/stock_vertical_lift/tests/common.py", line 68, in _open_screen
getattr(shuttle or self.shuttle, "switch_{}".format(mode))()
File "/home/travis/build/OCA/stock-logistics-warehouse/stock_vertical_lift/models/vertical_lift_shuttle.py", line 210, in switch_inventory
return self.action_open_screen()
File "/home/travis/build/OCA/stock-logistics-warehouse/stock_vertical_lift/models/vertical_lift_shuttle.py", line 155, in action_open_screen
operation.on_screen_open()
File "/home/travis/build/OCA/stock-logistics-warehouse/stock_vertical_lift/models/vertical_lift_operation_base.py", line 175, in on_screen_open
self.reset_steps()
File "/home/travis/build/OCA/stock-logistics-warehouse/stock_vertical_lift/models/vertical_lift_operation_inventory.py", line 196, in reset_steps
super().reset_steps()
File "/home/travis/build/OCA/stock-logistics-warehouse/stock_vertical_lift/models/vertical_lift_operation_base.py", line 167, in reset_steps
self.next_step()
File "/home/travis/build/OCA/stock-logistics-warehouse/stock_vertical_lift/models/vertical_lift_operation_base.py", line 147, in next_step
if not transition.action or transition.action(self):
File "/home/travis/build/OCA/stock-logistics-warehouse/stock_vertical_lift/models/vertical_lift_operation_inventory.py", line 36, in <lambda>
lambda self: self.select_next_inventory_line(),
File "/home/travis/build/OCA/stock-logistics-warehouse/stock_vertical_lift/models/vertical_lift_operation_inventory.py", line 242, in select_next_inventory_line
self.fetch_tray()
File "/home/travis/build/OCA/stock-logistics-warehouse/stock_vertical_lift/models/vertical_lift_operation_inventory.py", line 231, in fetch_tray
location.fetch_vertical_lift_tray()
File "/home/travis/build/OCA/stock-logistics-warehouse/stock_vertical_lift/models/stock_location.py", line 140, in fetch_vertical_lift_tray
tray.fetch_vertical_lift_tray(cell_location=self)
File "/home/travis/build/OCA/stock-logistics-warehouse/stock_vertical_lift/models/stock_location.py", line 142, in fetch_vertical_lift_tray
self._hardware_vertical_lift_fetch_tray(cell_location=cell_location)
File "/home/travis/build/OCA/stock-logistics-warehouse/stock_vertical_lift/models/stock_location.py", line 67, in _hardware_vertical_lift_fetch_tray
payload = self._hardware_vertical_lift_fetch_tray_payload(cell_location)
File "/home/travis/build/OCA/stock-logistics-warehouse/stock_vertical_lift/models/stock_location.py", line 118, in _hardware_vertical_lift_fetch_tray_payload
raise NotImplementedError()
NotImplementedError

This one happens because

stock-logistics-warehouse/stock_vertical_lift/models/stock_location.py

Lines 35 to 39 in c5aa718

	vertical_lift_shuttle_id = fields.Many2one(
	comodel_name="vertical.lift.shuttle",
	compute="_compute_vertical_lift_shuttle_id",
	store=True,
	)

is not computed.

It fails after: odoo/odoo@3a6ac95

[guewen]

Tests are now successful after rebase (fixed by #1035).

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[guewen]

Note: do not merge, will be moved to OCA/wms as asked by @jgrandguillaume

[simahawk]

@guewen shall we close this in favor of OCA/wms#115 ?