[16.0][ADD] stock_move_not_merge_by_dest_moves

[Shide]

This module was developed because sometimes we don't want our stock movements to be merged if goes to different moves because:

• Sale free products that must be invoiced separatelly (for example, get 2 + 1 free)
• Use warehouse with 2 or 3 steps in Outgoing Shipments
• Use products with Invoicing Policy: Delivered Quantities

All of these conditions must be met for this module to be really useful.

Use case example:

We have an order with two lines of the same product that need to be weighed (kg) and the offer is "get 2 + 1 free".

Each piece of Fish measures aproximately 1kg and we assume you know how many Fishes you need to take.

The lines of the sale would be like this:

• 2 pieces of Fish for aproximately 2kg in total.
• 1 piece of Fish for aproximately 1kg in total with 100% discount.

Odoo Core VS. Module: Workflow comparison

Odoo Core	With this module
The OUT step will not be grouped, so we will have 2 moves.	The OUT step will not be grouped, so we will have 2 moves.
The PICK step will be grouped into one line, telling you that 3 kgs must be demanded	Since we have 2 separate moves on the OUT step, we don't want to merge moves in the PICK step. PICK step will tell you that 3kgs must be demanded into 2 separate moves.
When you measure the 3 fishes in the PICK step, we get 1.9kg for the 2 Fishes and 0.7kg for the free Fish. 2.6kg in total.	When you measure the 3 fishes in the PICK step, we get 1.9kg for the 2 Fishes and 0.7kg for the free Fish. 2.6kg in total.
Confirm the PICK step. When you reserve quantities on OUTGOING step, 2kg will go to the 2 Fishes and 0.6kg to the free Fish.	Confirm the PICK step. When you reserve quantities on OUTGOING step, 1.9kg will go to the 2 Fishes and 0.7kg to the free Fish.
Your invoice to the customer will be 2kg for the 2 pieces and 0.6kg for the free fish.	Your invoice to the customer will be 1.9kg for the 2 pieces and 0.7kg for the free fish.
This is not correct: The 2 pices of Fish should be invoiced for 1.9kg and the free fish should be invoiced for 0.7kg at 100% discount.	This is correct

MT-10683 @moduon @rafaelbn @yajo @chienandalu @Gelojr please review if you want 😄

[Gelojr]

Initial order setup (identical in all tests and configurated Deliver in 2 steps (pick + ship)):

• Line 1: priced product, ordered quantity = 2 units (Estimated weight per unit 50kg).
• Line 2: free product, ordered quantity = 1 unit (Estimated weight per unit 50kg).

Test scenarios:

• Test 1: both lines are delivered with quantities greater than ordered.

• Test 2: both lines are delivered with quantities less than ordered.

• Test 3: line 1 (priced) is delivered with more than ordered, and line 2 (free) with less than ordered.

• Test 4: line 1 (priced) is delivered with less than ordered, and line 2 (free) with more than ordered.

Result:
All scenarios were executed successfully, with the system behaving as expected in terms of delivery validation, quantity management, and proper handling of free lines.
The test is considered OK. Nice job @Shide

[rafaelbn]

Design, implementation and functional review 👍🏼

Love 💙

[yajo]

Code review 👍🏼

[chienandalu]

I'm wondering if this is something we'd like to be optionable in the operation type

[Shide]

Since the "problem" (selling 2 lines of the same product) starts on the sale order, depending of the product that you sell you will need to activate every middle step.
I think it's simple to enable this module for all of middle steps if your company matches the conditions of the readme.

[chienandalu]

Well, I'm thinking in the rest of picking workflows where maybe this isn't necessary (e.g.: receptions)

[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). 🤖

[Shide]

This module has problems when changing quantity in sale order lines once the sale order it's confirmed. (creates a return)
I've tryied to add a context when the quantity of the sale line changes in order to add the distinct field only when the context is not present, but doesn't work.

Instead, I've adopted another way to manage this use case (selling a free product on another sale line) creating another procurement for the free products: OCA/sale-workflow#3818

I'll close this PR soon.

[EmilioPascual]

This module has problems when changing quantity in sale order lines once the sale order it's confirmed. (creates a return) I've tryied to add a context when the quantity of the sale line changes in order to add the distinct field only when the context is not present, but doesn't work.

Instead, I've adopted another way to manage this use case (selling a free product on another sale line) creating another procurement for the free products: OCA/sale-workflow#3818

I'll close this PR soon.

I've tried a new approach merging negative moves that goes to same destinantion moves. WDYT? Check it out please and let me know. Thanks.

[Gelojr]

I have tested on receipts and in the second step the quantities are not OK.
https://www.loom.com/share/416b1efb65d04c5d80acd9fac2bf4e0f?sid=8219c7d5-c47d-4521-92b3-37fbc19e539d

[Gelojr]

I have tested on sales and the changes of the SO line are not updated on the picking order.
https://www.loom.com/share/8dfe51327d6d435f8dbdcef4af9ce77b?sid=9faa87e0-8b71-47d8-bf0a-b97bbcf4bca8

[rafaelbn]

OK, thank you!

[rafaelbn]

/ocabot merge patch

[OCA-git-bot]

What a great day to merge this nice PR. Let's do it!
Prepared branch 16.0-ocabot-merge-pr-2014-by-rafaelbn-bump-patch, awaiting test results.

[OCA-git-bot]

Congratulations, your PR was merged at 49006dd. Thanks a lot for contributing to OCA. ❤️