Partial packing : Wrong Quantity being written on new move

[Numérigraphe]

In v5.0, when you make a partial packing the wizard will create a copy of the packing and stock moves.
That's fine but then it does something I find rather weird:
- it lets the original stock picking and stock move "confirmed" and sets the quantities to the quantities remaining to be sent
- it sets the quantities actually sent to the stock new moves
- and it marks the old picking a backorder of the new one

As a result, the old picking seems to have "changed identity": new id, new reference. Anything you've printed, sent announced to your customer or your carrier is obsolete.
If you happen to have a little complex situation (like several partial pickings in a row), it's incredibly difficult for the user to understand what happened.

The wizard should:
- copy the picking
- use the original picking as the one actually sent
- use the copy as the one remaining to be sent
- mark the copy a backorder of the original.

[Numérigraphe (numerigraphe)]

I'll provide a patch to illustrate the behavior that my users are expecting from this feature.
I can only suppose this is the correct behavior, maybe experts could confirm.
Lionel

[Numérigraphe (numerigraphe)]

Sorry for posting late - my email was sent from the wrong address and
was refused by Launchpad.

Here's a merge directive with my proposal.
- the original picking now changes little - only quantities are changed.
- the backorder is now the new picking, not the original one
- in the original picking, even the records with quantity=0 are kept. I
do find it convenient, but if you object to that, those records could be
collected and removed.
- I cleaned the context usage a bit (I can provide a separate patch for
that if it helps reviewing)

Now, I don't see a case where this new behaviour would be a problem when
shipping or getting goods. The only thing i'm still unsure is whether
procurements are right this way.
Experts, could you please advise?

Lionel

[Jay Vora (Serpent Consulting Services) (jayvora)]

I think, this improvement is needed but better to keep it for trunk.
If Back Order ref. is changed in stable, it may break consistency for stable users.
Thanks.

[Numérigraphe (numerigraphe)]

FYI i'm pushing a better fix to https://code.launchpad.net/~numerigraphe/openobject-addons/partial-picking-5.0
I think we need a way to show the backorder because users may want to act on it when it's created. So I added a button on the end step to open the backorder.
Lionel.

[Fabien (Open ERP) (fp-tinyerp)]

This wizard has been completly rewritten for trunk.
We don't plan to change the stable version on this.

[Numérigraphe (numerigraphe)]

Fabien,
The partial picking has been rewritten, but with the same behavior as in v5.0.
Jay mentioned that should be fixed. Experts are welcome to share their opinion.
Lionel.

[Azazahmed Saiyed (OpenERP) (saz-openerp)]

Thanks for coming back on this Lionel.

As the partial picking wizard has been rewritten, the issue has now moved to IDs of moves,other than Pickings.

Example:
Having a packing of qty 50, I am putting a partial packing of qty 30, the new move should take the qty 20.
Instead, the current behavior put q

[Azazahmed Saiyed (OpenERP) (saz-openerp)]

Oops, my keyboard just cheated me. :)

... to be continued...

Instead, the current behavior put qty of 20 to ID of old move and 30 to new move, Which should never be the case.

Thanks for the report and sorry for my slippery.

[Rucha (Open ERP) (rpa-openerp)]

Hello,Thank you for your suggestion!
However this is unfortunately out of the scope of the current OpenERP release, so we cannot implement it.
Let's close this bug for now, for the sake of clarity in Launchpad, it can always be reopened later when we consider new features for future roadmaps.
Thank you for your understanding!

[Nathan (nathan-bowden-kiwi)]

isnt this crazy folks? Its easy to just change new qty.
this must have to fixed.

[Yan-PCSol (yannick-soldati)]

+1 this is not a wish but a normal behavior

[Carlos Liebana (carlos-liebana)]

+1

We've got a big problem with this bug, that I don't consider wishlist at all. We've syncronized delivery/incoming orders for one customer with his carrier, and when there are partial pickings it doesn't work because there's a new order with the amount confirmed instead of the amount which is not.

[philu (philu)]

This is a very serious bug and happens in 6.0.1 as well.

[Numérigraphe (numerigraphe)]

This bug was marked "wontfix" whe V6.0 was beeing prepared but surely it should be reopened now.
Can someone from the core team mark this as "Confirmed again" please ?
Lionel Sausin.