The return packing wizard doesn't take into accout the field "Invoice control"
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Odoo Addons (MOVED TO GITHUB) |
Fix Released
|
Low
|
OpenERP Publisher's Warranty Team | ||
OpenERP Community Backports (Addons) |
New
|
Undecided
|
Unassigned |
Bug Description
Here is the scenario of the bug on OpenERP 6.1 (and also OpenERP trunk) :
1. Create a new DB and install the "sale" module (and "stock" module on OpenERP trunk)
2. Create a new sale order for Agrolait with one sale order line with product CPU1. Set "Invoice Policy" to "Invoice based on deliveries" and confirm this sale order.
3. Go to the delivery order that has been generated. Process it and create the customer invoice (you need to create the customer invoice, otherwise the bug doesn't happen).
4. On the picking, click on the button "Return Products". In the wizard, set "Invoicing" to "No invoicing" and click on the "Return" button to generate the Return picking.
5. Open the return picking and look at the field "Invoice control" : the value is "To be invoiced" ! That's the bug : as we set in the return picking wizard the field "Invoicing" to "No invoicing", the value of the field "Invoice control" should be "Not applicable".
Analysis of the code and solution for OpenERP 6.1 :
If you look at addons-
if picking_
default[
So, if when original picking has invoice_state = 'Invoiced", then the return picking always has invoice_state = "To be invoiced", whatever the content of the "default" dict is... so whatever the user sets in the "Return product" wizard !
My patch changes this code : invoice_state is set to "2binvoiced" if the original picking has invoice_state = 'invoiced' AND the "default" dict doesn't have an "invoice_state" key. In fact, there is the same kind of code 5 lines above, in the previous "if", so it seems to be a natural solution for me.
The bug and the solution is the same on addons/trunk.
Related branches
- Naresh(OpenERP): Pending requested
-
Diff: 12 lines (+1/-1)1 file modifiedstock/stock.py (+1/-1)
- OpenERP Core Team: Pending requested
-
Diff: 12 lines (+1/-1)1 file modifiedstock/stock.py (+1/-1)
Changed in openobject-addons: | |
assignee: | nobody → OpenERP Publisher's Warranty Team (openerp-opw) |
tags: | added: maintenance |
Changed in openobject-addons: | |
status: | New → Confirmed |
importance: | Undecided → Low |
Changed in openobject-addons: | |
status: | Confirmed → In Progress |
Changed in openobject-addons: | |
status: | In Progress → Fix Committed |
Changed in openobject-addons: | |
status: | Fix Committed → Fix Released |
Hello Alexis de Lattre,
We really appreciate your efforts for detailed explanation, the analysis you did and also for the patch.
However, in your fix, there is a small mistake,
- if picking_ obj.invoice_ state == 'invoiced': obj.invoice_ state == 'invoiced': 'invoice_ state'] = '2binvoiced'
+ if 'invoice_state' not in default and picking_
default[
With your fix, the code in the `if` block will never execute as the condition you placed will check for the `invoice_state` key in `default` dictionary, but, when the copy() is called from /stock/ wizard/ stock_return_ picking. py line 171, `invoice_state` key set statically, so the condition `if 'invoice_state' not in default` will never be true.
The reason why it works at your end is, the `Return Products` wizard will send the value for it's `invoice_state` field that is, `none` or `2binvoiced` and this value is going to be sent in `default` dictionary in /stock/stock.py line 702, and the returned picking will be created and it's `Invoice Control` field will have the value of `invoice_state` dict.
As per my investigation, this condition is not needed, because, whatever the `invoice_state` selected in `Return Products` wizard, that should be set in the `Invoice Control` in returned picking! or the fix could be modified like,
- if picking_ obj.invoice_ state == 'invoiced': 'invoice_ state'] != 'none' and picking_ obj.invoice_ state == 'invoiced': 'invoice_ state'] = '2binvoiced'
+ if default[
default[
But, as per my opinion, the condition is not needed, hence I will prefer to fix by removing this condition and will create a branch.
@Alexis de Lattre: Thanks for your analysis which traced the root cause of the issue.