diff options
| author | Arnold Moyaux <arm@odoo.com> | 2019-03-12 16:11:03 +0000 |
|---|---|---|
| committer | Arnold Moyaux <arm@odoo.com> | 2019-03-14 09:25:28 +0000 |
| commit | ce355c978686753c784c1a985975c9fabc7730bd (patch) | |
| tree | 1884034ba1f5b1543fe13062a2f4f797200021b5 /addons/web/static/src/js/views/basic/basic_controller.js | |
| parent | b0a68530209b9919ac6f08d4c735eb9a16d46edb (diff) | |
[FIX] mrp: wrong reserved quantity in produce wizard
Issue 1:
Usecase to reproduce:
BOM: 1 prod final F -> 2 unit of components C
- Create a MO of 2 units
- Reserve 4 units of C
- Produce 1 unit of F (produce wizard)
- Save
- Produce 1 unit of F
- Update quantity to 2
The reserved quantity in the wizard is 4 although there is 2 units
already done on the first operation. So it should remain 2.
It happens because the produce wizard did not take into account the
2 units already done on the first stock move line.
This commit fix by using ml.product_qty - ml.qty_done each time it's
needed.
Issue 2:
Usecase to reproduce:
SAME BOM
- Create a MO of 2 units
- Reserve
- update quantity to 3
- It creates a new line with to consume 2, reserved 0
- update quantity to 4
- It update the line 2 0 to 4 to consume 4 reserved
So we ended with 8 units of C reserved.
It happens because the system match the workorder line with the stock
move line one by one without a global view on what is reserved or not.
So the second workorder line found a move line with 4 reserved but 0
done and did not check the first workorder line that already use the
4 pieces reserved. So it considers it as available and take the
reservation a second time.
It's fixed by an iteration over workorder line instead of move line
and keep the used reserved quantity in a dict by lot.
Issue 3:
Usecase to reproduce:
SAME BOM
- Create a MO of 2
- Produce 2
- Update quantity to 3
New line with to consume 2 reserved 0
- Update quantity to 4
New line with to consume 2 reserved 0
It's bad since we would like a line 4 0 as in saas-12.1
It happens because _update_workorder_lines will always create a new
line with remaining quantity if it could'nt find one with reservation
to update. However the line could exist without reservation so it
should update it instead of creating a new one.
It's fixed by adding the remaining quantity in the first workorder line
without lot (if the tracking is serial it should continue to create a
new line).
Diffstat (limited to 'addons/web/static/src/js/views/basic/basic_controller.js')
0 files changed, 0 insertions, 0 deletions
