Partial packing : new move should contain the backorder

I tried to fix this myself but the code has become a mess during in v6 and I can't make it for now.
Lionel.

Hello,

It has been Fixed in http://bazaar.launchpad.net/~openerp-dev/openobject-addons/trunk-bug-891664-ksa
revision-id: <email address hidden>
revno: 5754
It will be available in trunk soon.

Thanks.

Dear Kirti Savalia,
I just tested your patch and it seems to fix the bug indeed.
Many thanks.
Lionel.

As a translator, I suggest you do NOT change the *.po files because the meaning has changed to the opposite meaning.
Translators will have to re-translate the string to get it right.
Lionel.

Dear subscribers,
I'm pushing a branch with a backport of the main part of Kirti Savalia's fix for v6.0 (changes to the translations not included).
Lionel.

The fix proposed by Kirti Savalia(OpenERP) was rejected "because there will be plenty of problems raising from here to there".
If I get it right, the whole backorder system needs a re-engineering.
So how do we start? Should we plan a workshop during the community days, or does someone have a clear idea that can be implemented now ?
Lionel.

Here is another approach: the thing that bothers users the most is that the partial picking that was actually done has a new reference, instead of keeping the reference of the initial delivery order.
So, can't we simply "swap" the references of the backorder and the delivery done ?
That is, we keep the logic as it is, but :
- the existing picking (= the backorder) gets a NEW reference
- the new picking (= the delivery done) gets the OLD reference

Lionel.

I'm pushing a backport of my proposed fix to v6.0 to lp:~numerigraphe/openobject-addons/6.0-stock-partial-picking-same-name : followers please feel free to test and give feedback here.
Lionel.

merged in trunk, thanks for the contribution.

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

Le 06/12/2012 17:22, Kyle Waid a écrit :
> Hello, Can we confirm this is fixed?
This was fixed only in the trunk (future v7.0 and later). It won't be
fixed in earlier releases because that's "misfeature" that users may
relying upon.

However, the trunk branch I pushed actually merges cleanly into 6.1 too,
so please test it and see if it fits your needs.
> 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.
Sorry, bad idea: sending more than ordered is normal in contexts where
the quantity cannot be precisely controlled during a make-to-order
production. That happens in our factory - we make chocolate treats.

Lionel Sausin.

Hello Lionel,

Thank you for the information regarding more moves than ordered. Perhaps this should be an admin configuration. I can see there are some companies that would not like to allow this behavior.

In regards to the feature being fixed, I am very aware that OpenERP often does not accept merge proposals or fix faulty code in their system, especially if its not trunk. I have already written my own version of this feature and it works quite well.

Kyle

Hello
IMO allow to ship more than order must be a product or product category property

apart from "unpacked" products we often see bonus or promotion quantities

Le 11/12/2012 16:50, Kyle Waid a écrit :
> In regards to the feature being fixed, I am very aware that OpenERP often does not accept merge proposals or fix faulty code in their system, especially if its not trunk.
Let's all hope this will improve over time...
> I have already written my own version of this feature and it works quite well
If you care to share it, that would be interesting - we met several
subtle issues when improving this, and it took quite a long time to find
a simple enough solution.
Lionel.