[trunk/7.0] Incorrect behaviour when producing MO with component split in serial numbers

Bug #1168398 reported by Rucha (Open ERP)
38
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Confirmed
Medium
OpenERP R&D Addons Team 2
OpenERP Community Backports (Addons)
Status tracked in 7.0
7.0
Confirmed
Undecided
Unassigned

Bug Description

trunk branches revisions:
server (4854)
addons (8669)
web (3715)

for the following BoM:
1 unit P1:
    |_ 4 unit C1
    |_ 1 unit C2

1. I create a MO for 1 unit P1 and confirm it,
2. so in Products to Consume I will have one move of 4 unit C1 and one move of 1 unit C1,
3. I split the move of 4 unit C1 into 4 different serial numbers a, b, c, d (1. in image.png)
4. I click on button "Produce" and I confirm with "Consume & Produce" mode for 1 unit.
5. Now(this is the bug), only one move having 1 qty for C1 has been moved to consumed products,
other 3 moves are still in products to (2. in image.png)
6. 1 move P1 has been moved to "Produced Products" and MO has stuck in Production Started status. (3. in image.png)

Related branches

Revision history for this message
Rucha (Open ERP) (rpa-openerp) wrote :
Changed in openobject-addons:
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → OpenERP R&D Addons Team 2 (openerp-dev-addons2)
Revision history for this message
SnippetBucket.com (tta-openerp) wrote :

Hello,

I checked same scenario with stable 7.0 and found same problem.

Here I have attached Image which introduce same problem in 7.0.

Thanks,
Tejas tta

summary: - [trunk] Incorrect behaviour when producing MO with component split in
- serial numbers
+ [trunk/7.0] Incorrect behaviour when producing MO with component split
+ in serial numbers
Revision history for this message
SnippetBucket.com (tta-openerp) wrote :

Hello,

This bug have been Fixed.

 * It has been Fixed in https://code.launchpad.net/~openerp-dev/openobject-addons/7.0-bug-1168398-tta
 * Revision ID: <email address hidden>

  It will be available soon in trunk.

Thanks,
Tejas - tta

tags: added: maintenance
Amit Parik (amit-parik)
tags: added: mrp
Revision history for this message
Vincent Vinet (vince-vinet) wrote :

Bug with proposed fix

The currently proposed fix uses the wrong split count in the following scenario:
1) Split a produce to consume into quantities 50, 70 and 80
2) Produce what would consume 60 (Must be > 50 and < 70)

The resulting consume moves will be
1) Consume 50/50 (as expected)
2) Consume 60/70 (expected 10/70)

This is because the fix doesn't split, when a move to consume has more than the TOTAL amount to consume, then
the total amount to consume is taken instead of what's left to consume. The fixed fix instead compares the remaining
amount to consume and consumes appropriately.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.