Previous fix: odoo/odoo#139013 added in the ability to handle a use case
specific avoided due to its complexity and it being an edge case. I.e.
the ability to do a Put in Pack in a batch picking where there is a
shipping connector involved (i.e. when the `choose_delivery_package`
wizard is opened).
Because the ability to handle this situation is now added to stable, we
have to sort of support it now and handle it not breaking other flows.
Here are the flows that need to be handled (and were broken by the
previous PR): [In all cases, "Packages" setting needs to be activated
and each picking needs at least 1 move of a consumable/storable product]
Flow 1: batch picking + put in pack for single picking
- Create 2 pickings of any operation type
- Create a new batch picking with these 2 pickings
- Open 1 of those pickings directly (i.e. not in the batch)
- Click on "Put in Pack"
Expected result:
Only the move from the open picking is put into a package
Result before this commit:
Both pickings have their moves put into the same package
Additional notes: Because this is not an obvious bug, users may already
had this bug occur in their DBs without realizing it
===
Flow 2: batch picking (or multi-record calling of `action_put_in_pack`)
[different in v17 onwards due to removal of immediate_transfer boolean]
- Create 2 pickings (of different picking types)
- Select both pickings (through direct call in shell or rpc) and call
`action_put_in_pack`
Expected result:
Moves are blocked from being put into same package since this situation
doesn't make sense (i.e. the products are moved to different locations
but the package can only be in 1 location)
Result before this commit:
The moves will all be put into the same package
Additional notes:
In theory batch picking creation has checks to avoid batches where
there are pickings with more than 1 picking type or have different
`show_reserved` values, but because `_package_move_lines` is a method
that can be called in different use cases (including multi-record
pickings) via customizations/future code changes, we add in checks to
prevent put in pack from finishing in those cases to avoid unexpected
behavior/stack traces. I.e. remember to respect existing
`self.ensure_one` checks since they're probably there for a reason.
===
Flow 3: batch picking w/pickings w/more than 1 delivery carriers (where
none = a different carrier than having 1)
- Create 2 delivery pickings with different `carrier_id` values (i.e.
different shipping methods assigned to them)
- Add both pickings to a batch
- Click "Put in Pack" in the batch picking
Expected result:
None, we should not handle this case because if the products are in the
same package then the same package info will be sent to both carriers
and the user will be double charged for every move (or
charged(/potentially create the wrong shipping documents) when it
shouldn't be in case of no carrier for one of the pickings)
Result before this commit:
All moves are put in the same package and the double
charging/potentially incorrect shipping documents will occur
Additional notes:
This is the use case that was intended to be avoided when flow was
originally decided to not be handled
closesodoo/odoo#157224
X-original-commit: b3498facab77e1eed8969c018e3f966a80e62654
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Tiffany Chang (tic)
cff93694a7