The packing wizards should show the move name

[Numérigraphe]

In V5.0 and in the trunk, the partial packing wizard and the return packing wizard hide the name of the stock move from the user.
Instead, the former shows the code and name of the product, and the later shows only the name of the product.

[Numérigraphe (numerigraphe)]

Here is a tentative fix for this.

[Numérigraphe (numerigraphe)]

Could you please comment on the patch above?
It could be applied to the trunk.
FYI it applies cleanly to v5.0 too.

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

Hello Lionel,

Yes it seems like a useful one.

Thank you for your contribution.

You can check the revision 2455 <email address hidden> . It has some more modifications too.

[Numérigraphe (numerigraphe)]

I'm re-opening this bug because we need a broader solution, as illustrated bellow.
Lionel

Grzegorz Grzelak (Cirrus.pl) reported in Bug #602629 :
"When you have purchase order created by any procurement (minimal stock or manual on product form) and then you create picking list (approving that purchase order) you cant see product names during validating.

Instead of product names you see name field from stock moves which are like:

"PROC:INT:admin"
"PROC:OP:2"

So you don't know what are you validating.

When purchase order is created manually name field contains correct product name. In sales order site it is correct too.

I think in module stock in file wizard_partial_picking.py in line 70

instead of:

                'string': _to_xml(m.name),

should be:

                'string': _to_xml("["+ m.product_id.code +"] " +m.product_id.name),"

[Vinay Rana (OpenERP) (vra-openerp)]

Hello Grzegorz Grzelak & Lionel,

We have checked the scenario and it came to a conclusion that on the wizards of return/make picking, moves should be differentiated by the name of the Move(which is the current,before the fix of Bug #602629 scenario).

The reason why code and name of the product is not getting displayed on wizard is, the product has a supplier and the supplier info does not contain the Partner Product code. Once you assign a value to code, the happening will look quite familiar to you.

The fix to Bug #602629 has been reverted.

Hope this makes it clear.

Thanks.

[Grzegorz Grzelak (OpenGLOBE.pl) (grzegorz-og.pl)]

Thank you vra.

Yes it is clear. Now I understand how wrong was my fix.

But it is still a problem. (much less now). When OpenERP user doesn't use supplier name and code (because he simply uses supplier names and codes on product form). In other words he uses supplier names and codes as his own. In such case it is not convenient for him to enter them twice. I think that when supplier names and codes fields are empty system should take main product name and code not leaving empty names for moves.

I see now that separate field for move name apart of internal product name is very good solution for partner name or name translation. But it looks that it should be improved as pointed above. And another question is if we have similar functionality on sale side. Some customers require on packing list and/or invoices apart of our names and codes (translated or not) also their names and codes.

All the best.

[invitu (invitu)]

Hello

Moreover, on the sale side, when we work on a customer return (for example, a customer wants to return only one product out of several other products), we need to see which product we return. If we only show move names, it's not possible easily (we have a regression here).

Also, in the same wizard, it is not convenient at all if the customer returns only one product out of 100... we have to manually set 99 products to quantity=0 and let the returned product to the quantity returned (BTW, it is no use to keep the lines where qty=0 in the return packing list --> to be discussed). It might be a source for wrong moves.

The solution would be to use different scenarii with supplier and customer cases and to improve ergonomy for validating packing lists.

Regards

[invitu (invitu)]

In my previous example, the regression is about sales that have been made with POS : all the move lines are named "Stock move (POS XXXX)". One could modify POS module to have product names in move lines. In that case, I would agree to keep the move name in the return wizard.

My second comment is still confirmed when we have a few products returned among a lot of others products in the same move.

[Dhruti Shastri(OpenERP) (dhs-openerp)]

Hello Invitu,

Would you please make your view clear?
What did you mean by 'My second comment is still confirmed when we have a few products returned among a lot of others products in the same move.'?

There is only one product(quantity can be any) in one move. You may return the move by setting any number of quantities.

Thanks.

[invitu (invitu)]

Hello

Sorry, I meant "a lot of products in the same return packing".

My example :
The sale is that way :
product A - qty 5
product B - qty 5
...
product Z - qty 5

If the customer returns only 2 "product H", the wizard is not very ergonomic because we should set all the quantities to 0 on 25 lines except for the product H.
By the way, I also think it is no use to input lines where quantity=0 in the return packing

Do you advise to open a new bug for that ?

Regards

[Dhruti Shastri(OpenERP) (dhs-openerp)]

Hello Invitu,

I agree with your comment.
But, those who are willing to return most of the products would argue that wizard should show all the moves.

There seems an elegant solution from our side,here it goes:
1. On click on Return picking wizard,a Many2Many will ask user to select the moves he wants to return.
2. Clicking 'Next' of that form,will call another part of the wizard which will only show SELECTED moves and their corresponding Quantities.

This will ease the headache of user,who wish you return one move out of many moves.

Just for your information, the upcoming version already has a facility to return the particular move. Each move has a button to perform such an operation which sounds easier.

We are open to accept a better solution if found any.

Thanks for your interest.

[invitu (invitu)]

Hello and thanks for the suggestion

I opened a new bug for that : https://bugs.launchpad.net/openobject-addons/+bug/620573

Regards