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

Bug #1168398 reported by Rucha (Open ERP) on 2013-04-12
This bug affects 6 people
Affects Status Importance Assigned to Milestone
OpenERP R&D Addons Team 2
OpenERP Community Backports (Addons)
Status tracked in 7.0

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

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)
SnippetBucket.com (tta-openerp) wrote :


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

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

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
SnippetBucket.com (tta-openerp) wrote :


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.

Tejas - tta

tags: added: maintenance
Amit Parik (amit-parik) on 2013-08-02
tags: added: mrp
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  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers