Comment 10 for bug 891664

Revision history for this message
Kyle Waid (midwest) wrote :

Hello, Can we confirm this is fixed?

I am still working with 6.1, but ill explain the issue anyway. I am trying to do some things with the new picking data that is created. I discovered, that the new picking is actually the original picking but the done picking.

I create sales order for products A, B, C.

Confirm order, delivery order generated.
Go to delivery order process it. This calls the partial picking wizard.
I change quantity of products A and C to 0. Press confirm. This calls stock_picking.do_partial()
It appends too_few with products A and C.
Instead of making the original picking done with product B, it creates a new picking with product B.
The original picking is altered to have products A and C in state ready to process.

This behavior does not make sense to me. The new picking should clearly be the backorder, NOT the original picking. If some other functionality was tracking pickings from creation this would surely cause a problem. I also believe this is miss-storing information in the database. When the original picking is created there is a reference that is permanently stored. What is happening is this order is transformed into a completely different picking with the same reference. This is false information.

IMO, as Numerigraphe has pointed out, it should create a new picking with the backordered items. Moreover, it should return the original completed picking with a note at the top that the backorder was created. Why would it return the new picking? What if I wasnt finished processing the original picking, such as needing the print a carrier label after the picking is done.

Additionally, I wanted to note one other thing. While this manipulation is being done in do_partial() the results seem to be muddled in the memory. When I tried to print pick.move_lines it was giving me the original picking move lives, not the newly modified data. I had to open a new cursor to see the backordered lines. This is probably due to the strange manipulation in stock picking.

Finally, IMO, we should not allow a user to send more product than the orignal picking is called for. too_many [] should be eliminated and raise exception.

THank you