Procurement - stock move relationships need to be improved to better handle e.g. split moves

Hello Patrick,

I have checked your scenario at my end.

You have described the two problem over here.

First is related to progress bar of 100% which is already is mention on bug # 794412 and it's confirmed So only your second issue is remaining which is "- The remaining stock.move in the Delivery Order is not set to Available".

It is possible only when you click on the "Check Availability" button and then the related stock.move become "available".

When you create a pack for 70 pcs then you see that two stock.move which are in "Confirmed " state and when you press "check availability " button the first stock move (70 pcs) is become available and second one becomes "Not available".

So when you done your picking for incoming shipment then the related delivery order doesn't become "available" automatically you have to press "Check Availability" button then it will become "available".

That's why current behavior is fine.

I have attached a video for your more reference so would you please check it and notify us where you faced the problem.

Thanks for you proper bug specification!

Hey Amit,

The Incoming Shipment should be related to the entire Delivery Order. Here, the Incoming Shipment is only related to the first stock.move.

I demonstrate here the inconsistency of the present implementation:

In stock: 100 CPU1
Sale Order: 200 CPU1 on order

Create and validate the sale.order. Process procurement.order, validate purchase.order. Go to the Delivery Order. From there two different scenarios which should give the same result, but do not:

1)

- put the stock.move in a new pack, leave 70 CPU1
- click check availability, first line is available.
- go to incoming shipment, process.

-> the second line of the delivery order is NOT available

2)

- put the stock.move in a new pack, leave 130 CPU1
- click check availability, second line is available
- go to incoming shipment, process.

-> the first line of the delivery order is available (both lines are available actually)

Both procedures are functionally the same, please Amit, explain me why we do not get the same behavior. Thanks.

Hello Patrick,

Thanks for your good explanation.

You are right according to comment #3 and I have faced the same problem related to comment #3.

You have described one same scenario with two different way as per my opinion both have the same behavior but in current system both way have not same behavior which is described in comment #3.

But this issue is total functional expect related to stock(picking) So currently I am not set this as a "Confirmed " because we need to more discussion on this means which behavior should be better on this.

I'm setting the status to "Triaged" to indicate that it is being escalated and discussed.

@experts : Would you please share your views on this.

Thanks for understanding!

Hello,

I have again checked this issue and it is clearly shows a different behavior for same thing according comment#3.

I am confirming this issue for the different functional behavior So the R&D team will check both the scenario and take the appropriate action.

For more reference I have attached two videos So would you please check it which makes more clear.

Thanks.

Hello Patrick,

Thanks for your good explanation.
You are right according to comment #3 both have the same behavior but in current system both way have not same behavior becasue we need to set the stock move of procurement order field as a "one2many" instead of "many2one".Because procurement order should check all the stock moves according to split.Right now it is not possbile because stock move field is "many2one".

According your scenario after spliting 2 move generated.
-> First Case
    [1] for qty = 70/done
    [2] for qty= 130/available

-> Second Case
    [1] for qty = 70/available
    [2] for qty= 130/done

so in the stock move of procurement order always set the move for qty=70 becasue it is the first move.According to Second case it's work perfect becasue move is "available" state for qty=70.In the First case move is "done" for qty=70 so procurement come in "done" state.

Currently its not feasible because Its many affects.So currently setting this bug as wishlist.

Thanks.

Hi Patrick,

I understand your concern and I kind of agree that we could improve the model a bit to support cases with split deliveries in a more reliable way. However as Kirti tried to explain, this represents a non-trivial change in the model, for a limited immediate benefit.

Usually when a split move line fails to be considered correctly by the system, the workaround is to resort to handling it manually. This is in fact consistent with the philosophy of OpenERP flows: the regular flows are handled automatically by the system, without going to far in specific cases as to make the system overly complex. And for the rest, give enough control to users so they can manually handle any special case without the system coming in the way.
This is illustrated by your example in comment #3, where the workaround is trivial: when the system did not do the work for you, you can just "Check availability" manually and fix it.

Nevertheless we can think about improving the model in the long run, for instance by having a more explicit way to link "split" moves together so they can be considered all together when that matters. For this reason I suggest we keep this bug open as "Wishlist", and foresee a deeper analysis to improve this in the future (i.e. after 6.1 release).

On the other hand, you related bug 794412 does highlight a case where this could lead the user to wrongly believe that an order has been completely delivered. This is different and we should indeed implement a workaround right now, without waiting for a future new model.

Thanks for your well documented bug reports!

Dear Olivier,
Please let me disagree with your statement that this is an issue that can be worked around.
Procurements are actually central to all the ERP, so the current conception has consequences in every module, and users have no clear way to understand why OpenERP does this or that.
For example :
* make as sale+delivery, split a move, cancel the first line => exception raised on sale
* make as sale+delivery, split a move, cancel the second line => exception not raised on sale
On the other hand the behaviour of purchases is better (mrp seems fine too, not a specialist) :
* make a purchase+reception, split a move, any 1 move => no exception raised
* make a purchase+reception, split a move, cancel all moves => exception raised
Lionel

For the records, this bug makes it unclean to create several stock moves per procurement whe confirming sale orders, av was emphasized in this merge proposal:
https://code.launchpad.net/~numerigraphe/openobject-addons/trunk-sale-line-multiple-moves/+merge/84733
Lionel.

Quoting Joël Grand-Guillaume: "in fact the whole procurement / stock move have been reviewed and you now have a "procurement group" that is used to say what to treat together.
Also, it's now the procurement that trigger the stock move creation and the the contrary like it used to be the case."
So I guess this means "Fix committed".