[trunk][mrp] bugfix on consuming materials introduced two new bugs

Bug #691012 reported by Tamás Dénes
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Fix Released
Low
OpenERP R&D Addons Team 2

Bug Description

I've committed the bugreport #669210 which was fixed a month ago.

I've just checked this functionality recently since it has been fixed. I found that this patch solved the reported problem but introduced two new ones.

The new problems are as follows (in the Manufacturing Order form):

1. After consuming the raw materials they appear in the right side list doubled. (Every item is displayed twice in Consumed Products). Initially the duplicated lines show only a quantity of 0 but after double clicking on any line the duplicates will be shown.

2. A new LOT is generated for each consumed raw material after invoking consume. So the system wants to consume materials from such LOTs where there is 0 quantity in stock. These new LOTs will have a negative stock quantity and these LOTs are used for nothing. At the same time stock quantities in the work center locations keep increasing because the user sets the right LOTs on the Internal Moves lines but the system doesn't consume raw materials from these LOTs.

The mechanism mentioned in the second problem should be changed so that Production LOT should not be generated for the Consumed Products but should the LOT numbers copied from the Internal Move lines (Picking List) beforehand. This way the system would work as intended.

I've attached a screenshot to illustrate the first problem.

Tags: mrp stock

Related branches

Revision history for this message
Tamás Dénes (tamas-denes) wrote :
Revision history for this message
Jamin Shah(OpenERP) (jamin-openerp) wrote :

Hello Tamás Dénes,

Thanks for reporting.
This is already fixed in trunk.
You can check with latest revision.

Thanks.

Changed in openobject-addons:
status: New → Fix Released
Revision history for this message
Tamás Dénes (tamas-denes) wrote :

Hi Jas,

Thanks for fast response! You are true in that the first problem is fixed now. But the second problem still exists!

Namely that the consume method still generates totally new Lots for the consumed products. So the system does not consumes those materials what are physically consumed.
Don't think of a machine production company, where there are no Lots. It doesn't matter which screw is consumed. But think of a Food manufacturing company, where you don't think of items, but batches (LOTs) of items. In such a company You don't think of products, but batches of products. At least for two reasons:
1. Food has expiration date.
2. You have to ensure traceability

The workflow is as follows:
1. The user creates a new Manufacturing Order
2. The user sets the intended Lots to consume on the Internal Move lines (Picking list) For example Lot 0015 and Lot 0021.
3. The warehouse man bring those materials to the Work Center location (for example 5 pce from Lot 0015 and 3 pce from Lot 0021)
4. physically they are consumed for the production (Lot 0015 and Lot 0021)
5. OpenERP does not consume those materials which was physically consumed (Lot 0015 and 0021), but the Consume method creates totally new Lots to consume. (Lets say Lot 0031 and 0032, but there are no materials with those Lots in stock, and even the physically consumed materials were from other Lots).

This way OpenERP is unusable for those production companies where LOT management is necessary (food, pharmacy, chemical industry).

So please change the behavior to one which has some sense. OpenERP must reflect the real stock movements. The consume method should not generate new LOTs for the Consumed Products but should use the same LOTs as it uses in the internal moves.

I hope I was clear enough!

Changed in openobject-addons:
status: Fix Released → New
Changed in openobject-addons:
assignee: nobody → OpenERP R&D Addons Team 2 (openerp-dev-addons2)
importance: Undecided → Wishlist
status: New → Confirmed
Revision history for this message
Tamás Dénes (tamas-denes) wrote :

Dear vra and OpenErp developers!

I'm very surprised that You consider working LOT management a whis! (You've set importance to Wishlist)
Probably You didn't realize that with the bugfix #669210 OpenErp's LOT management in mrp modul became practically unusable.

The earlier behavior was much better. I mean that if the user forget to set the intended LOT in the Products to Consume lines than a message box was shown that the prod_lot field can't be empty. Now the software silently generates a new LOT and a serious error becomes hidden. The stock quantities becomes incorrect. Not mentioning that traceability is broken anyway.
For example if You use serial numbers for the parts to be built in You will not know which part was built into a particular product.

I suppose developers usually don't test the stock and mrp modules with LOTs and such problems remain hidden.

Changed in openobject-addons:
importance: Wishlist → Low
Changed in openobject-addons:
status: Confirmed → In Progress
Revision history for this message
Rohan Nayani(Open ERP) (ron-tinyerp) wrote :

Hello Tamás,

It has been fixed in lp:~openerp-dev/openobject-addons/ron-dev-addons2
Revision ID: <email address hidden>
Revision num: 5090.

It will be available in trunk soon,

Changed in openobject-addons:
status: In Progress → Fix Committed
Revision history for this message
Tamás Dénes (tamas-denes) wrote :

Hi ron,

Thanks for such fast response!

I haven't tested the code, but I found a typo in mrp/mrp_view.xml at line 603:

A "d" is missing here (from "draft"):
______V________________________
states="raft,waiting,confirmed,assigned"

Revision history for this message
Rohan Nayani(Open ERP) (ron-tinyerp) wrote :

Hello Tamás,

Thanks for it.
It has been improved in lp:~openerp-dev/openobject-addons/ron-dev-addons2
Revision ID: <email address hidden>
Revision num: 5094.
It will be available in trunk soon,

Changed in openobject-addons:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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