Cannot post consume on production order

Bug #733156 reported by Bogdan
52
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Fix Committed
Low
OpenERP Publisher's Warranty Team

Bug Description

Using v6, I defined a BOM wich has same raw material on 2 lines - because the raw material is added in 2 steps of production process.
eg. in demo database - change CPU_GEN BOM, raw material CPU1 exists with qty=1 then add new line (after other raw materials) CPU1 with qty=2. Make Production order CPU_GEN qty=3
When posting consumption with regular user (even new admin user - not uid 1 admin) the following message shows:
Quantities, UoMs, Products and Locations cannot be modified on stock moves that have already been processed (except by the Administrator). If I take each line of raw material and post, the consume is made without problems.
When posting with admin (uid=1) the consume is posted. This is because is a uid = 1 verification when changing stock moves.
I noticed that consumption lines are different from products to consume :to consume - 2 lines with qty=3 and 6, consumed - 3 lines each with qty=3.

There are 2 issues:
- cannot post consumption in the above situation
- split of consumption lines

Tags: maintenance

Related branches

affects: openobject-server → openobject-addons
Revision history for this message
Lucas (lucasbrosnon) wrote :

yes i agree.

Changed in openobject-addons:
status: New → Confirmed
Amit Parik (amit-parik)
Changed in openobject-addons:
assignee: nobody → OpenERP Publisher's Warranty Team (openerp-opw)
importance: Undecided → Low
Revision history for this message
Amit Parik (amit-parik) wrote :

Hello,

This issue have been generated in stable 6.0 only due to the constraint on BOM this is not generated in trunk.

Thanks.

Revision history for this message
Bogdan (bogdand) wrote :

Hello,

This is blocking from my point of view - as cannot post consumption.
So should we use trunk not stable version?

I assume that the issue that is not generated in trunk is the first one, consumption constrain (cannot post).
The second issue, split of consumption lines (which probably generates the first) is still happening.

Thanks

Revision history for this message
Francisco Pascual -- Ting! (francisco-pascual) wrote :

This is blocking from our point of view also. "Split of consumption lines" is really wrong, because in most of the cases lots have got more than one unit.

This is not low at all, is blocking traceability and I doubt somebody is using MRP for real in any case with lots.

Revision history for this message
Francisco Pascual -- Ting! (francisco-pascual) wrote :

You can find attached a video we have recorded of the anormal functionality of the standard MRP modules with lots.

If I select a product to consume, click in the "folder icon" of the record and introduce the corresponding lot, two different behaviours happen when:

- I directly click in the "right arrow" icon of the list of products to consume the system automatically creates one different lot for each one of units of the product.
* You can see the example in the video with the product "Huevos"

- If I press "Process now" in the pop-up of the record, it works well, moving all the units to consume for the specified product in the lot selected.
* You can see the example in the video with the product "Jamon York"

As you can see in the example also, when I change the quantity to consume in the information of the product, automatically is well updated in the list. But clicking in the wizard with the "right arrow" the quantity returns to the original value... and crashes our server (I don't know if due to the wrong change or due to the high amount of product to consume)

Thanks.

Revision history for this message
Ana Juaristi Olalde (ajuaristio) wrote :

I totally agree with Fran that it's blocking and very high importance error.
Thanks

Revision history for this message
Mannu Sharma (mannu) wrote :

I am also facing the same issue.

Is there any solution/resolution for this issue.

Thanks.

Revision history for this message
Mannu Sharma (mannu) wrote :
Download full text (5.1 KiB)

Got the solution by adding a flag variable in action_produce function in mrp.py.

Here is the code... but check it once by yourself.

def action_produce(self, cr, uid, production_id, production_qty, production_mode, context=None):
        """ To produce final product based on production mode (consume/consume&produce).
        If Production mode is consume, all stock move lines of raw materials will be done/consumed.
        If Production mode is consume & produce, all stock move lines of raw materials will be done/consumed
        and stock move lines of final product will be also done/produced.
        @param production_id: the ID of mrp.production object
        @param production_qty: specify qty to produce
        @param production_mode: specify production mode (consume/consume&produce).
        @return: True
        """
        count=0
        stock_mov_obj = self.pool.get('stock.move')
        production = self.browse(cr, uid, production_id, context=context)

        final_product_todo = []

        produced_qty = 0
        if production_mode == 'consume_produce':
            produced_qty = production_qty

        for produced_product in production.move_created_ids2:
            if (produced_product.scrapped) or (produced_product.product_id.id <> production.product_id.id):
                continue
            produced_qty += produced_product.product_qty

        if production_mode in ['consume', 'consume_produce']:
            consumed_products = {}
            check = {}
            scrapped = map(lambda x:x.scrapped, production.move_lines2).count(True)

            for consumed_product in production.move_lines2:
                consumed = consumed_product.product_qty
                if consumed_product.scrapped:
                    continue
                if not consumed_products.get(consumed_product.product_id.id, False):
                    consumed_products[consumed_product.product_id.id] = consumed_product.product_qty
                    check[consumed_product.product_id.id] = 0
                for f in production.product_lines:
                    if f.product_id.id == consumed_product.product_id.id:
                        if (len(production.move_lines2) - scrapped) > len(production.product_lines):
                            check[consumed_product.product_id.id] += consumed_product.product_qty
                            consumed = check[consumed_product.product_id.id]
                        rest_consumed = produced_qty * f.product_qty / production.product_qty - consumed
                        consumed_products[consumed_product.product_id.id] = rest_consumed

            for raw_product in production.move_lines:
                count=0
                for f in production.product_lines:
                    if f.product_id.id == raw_product.product_id.id and count==0:
                        count=count+1
                        consumed_qty = consumed_products.get(raw_product.product_id.id, 0)
                        if consumed_qty == 0:
                            consumed_qty = production_qty * f.product_qty / production.product_qty
                        if consumed_qty > 0:
                            stock_mov_obj.actio...

Read more...

tags: added: maintenance
Changed in openobject-addons:
status: Confirmed → In Progress
Revision history for this message
Amit Dodiya (OpenERP) (ado-openerp) wrote :

Hello Bogdan,

1). The issue of same raw material on 2 lines of BOM is fixed in following branch:
Branch: lp:~openerp-dev/openobject-addons/6.0-opw-516475-ado with
Revision-id: <email address hidden> and
Revision-no: 5103

2). For the issue consumption lines are different from products to consume and for production lot issue all works fine as per the expectations at our end.
For better clarification we have uploaded a video here : http://blip.tv/openerp-support/consuming-the-product-in-manufacturing-order-case-516475-5996792

Regards,
Amit

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

Other bug subscribers

Bug attachments

Remote bug watches

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