MRP : check_product very strict - BoM line product should not be same as BoM product.

Bug #985525 reported by Antoine
46
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Confirmed
Low
OpenERP Publisher's Warranty Team

Bug Description

In openerp 6.1 on module MRP, there are a function to check product on BoM.
BoM can't contained two lines or sublines with same product.

For example, we have a bom (bomA) with two bom composent, I named it bcomp1 and bcomp2 .
bcomp1 and bcomp2 contain a line with same product, product1 and parent bom is bomA.
With check_product constraint, there are a problem on bomA.

We work in electronic. bcomp1 and bcomp2 are bom of an electronic card and they used same LED (product1).

Why this hard check and not checked products only on BoM and checked products of bom composent without memorised products of parent BoM ?

Tags: maintenance

Related branches

Revision history for this message
Amit Bhavsar (Open ERP) (amb-openerp) wrote :

Hello Antoine,

I have tested your scenario, I am not sure for this behaviour, It is really strict .....Or very strict ;-)

But we should Improve this things. That's why I have attached the video. would you please check it. As per my view, we should make readonly field "bom_id" in BOM Components form view.
So Let the team to take decision on it.

Thanks for the reporting!

Changed in openobject-addons:
status: New → Confirmed
importance: Undecided → Low
assignee: nobody → OpenERP R&D Addons Team 2 (openerp-dev-addons2)
Revision history for this message
Antoine (antoine-suj) wrote :

Hello an thanks for your answer,

Yes there are problem with no check on change parent bom.

But my problem is not really that.
In your video, you create bomA on product « [led] elec card » and two component each on product « [led] led sub prod ».
My scenario is :
- create bomA on product « [led] elec card »
- create component 1 on product « [card1] card »
- create component 2 on product « [card2] card »
- create subcomponent 11 (component of component 1) on product « [led] led sub prod »
 ( at this step normally all is OK but i will use bom component menu or field parent bom )
- create subcomponent 22 (component of component 2) on product « [led] led sub prod »
 (with special manipulation used to make that, you don't have any alert)
We can see our bomA is no respect check_product constraint when we want to edit it.
For me bomA is OK and check_product is too strict because subsubcomponent may have same product association that an other subsubcomponent.

More clearly, I have modify check_product to have a recursion with depth limit at one.

Revision history for this message
Amit Bhavsar (Open ERP) (amb-openerp) wrote :

Hello Antoine,

First of all sorry for the inconvenience.please Ignore my comment#1.
I have checked your Issue as per comment#2, But It's confusing for me.
Would you please elaborate more on this Issue and It's better for us if you provide video for reproduce and sufficient information.

Thanks and waiting for your reply!

Changed in openobject-addons:
status: Confirmed → Incomplete
assignee: OpenERP R&D Addons Team 2 (openerp-dev-addons2) → nobody
importance: Low → Undecided
Revision history for this message
Antoine (antoine-suj) wrote :

With some delay, this is a screencast to explain bug.
I used demo products.
- "set table" is the main product
- with two component : table and tablette (with each same product named "planche" as component (double subcomponent of table)

Antoine (antoine-suj)
Changed in openobject-addons:
status: Incomplete → New
Revision history for this message
Amit Bhavsar (Open ERP) (amb-openerp) wrote :

Hello Antoine,

First of all Thanks for the nice screencast. This Issue are arise when same product are used in two different components. and this case are come in rare case. That's why I am confirm this Issue with low Importance.

Thanks for the reporting

Changed in openobject-addons:
status: New → Confirmed
importance: Undecided → Low
assignee: nobody → OpenERP R&D Addons Team 2 (openerp-dev-addons2)
Revision history for this message
Numérigraphe (numerigraphe) wrote :

Dear Amit Bhavsar,
This is not a rare case at all. Think of all very common components like screws and bolts in mechanical construction; resistors or capacitors in electronics; oil or sugar in food industries...
So this can be a problem for many companies.
Lionel.

Revision history for this message
Colin Bacon (ym8-colin) wrote :

Hello Amit,

I must agree with Lionel - it is very normal practice to have many of the same components within one BOM.

I also have also the same issue for a customer of mine - in the textile industry.

Let me explain:

I'm trying to set-up a 'master' BOM containing many sub-components - consisting of cotton threads. Many of these sub-component (threads) are referencing the same core product - but with slightly varying quantities per meter. i.e. each threads is the same raw-material, same costs per meter, etc. - just different length (due to the patterns the weaving machines are creating).

When trying to add multiple threads directly to the BOM - I also get this error message "ValidateError - Error occurred while validating the field(s) product_id: BoM line product should not be same as BoM product"

Work-around:
One work-around I found that work (well sort-of) -....

a) first create a BOM without any components, but ensure all workcentres and other information has been added.
b) Then create the BOM components with reference to the same products (but with different quantities) and also referencing Parent BOM (in the properties/parent BOM field) .
c) When complete you can open the parent BOM again and see the multiple sub-components have been added.

As I needed an exact sequence of material on the BOM this seems the only way I could create the master BOM.

Nevertheless, the main issue with this work-around is you can't change anything on the master BOM again - without getting the error message :

"ValidateError - Error occurred while validating the field(s) product_id: BoM line product should not be same as BoM product"

The error message in this case is also misleading as the final product (Master BOM) is not included anywhere in the BOM component list - so there is no issues with recursive errors of the same product on this BOM. I only have many repeating items in a BOM - but with varying quantities.

As you can imagine this is really irritating when you have over 10.000's products. So please reconsider a solution for these type of business scenarios.

Thanks

Colin

Revision history for this message
csmarvz (csmarvz) wrote :

Dear all,

Is there a way to disable that constraint?

Thanks

Henry

Revision history for this message
Fabio Colognesi (fabio-colognesi) wrote : Re:[Bug 985525] Re: MRP : check_product very strict - BoM line product should not be same as BoM product.

Hello Henry,

Waiting the right correction from OpenErp I will overload the original function. Attached our patch.

class mrp_bom_patch(osv.osv):
    _inherit = 'mrp.bom'
    def _check_product(self, cr, uid, ids, context=None):
        """
            Override original one, to allow to have multiple lines with same Part Number
        """
        return True
    _constraints = [
        (_check_product, 'BoM line product should not be same as BoM product.', ['product_id']),
    ]
mrp_bom_patch()

Bye
Fabio Colognesi

Da: <email address hidden>
A: <email address hidden>
Cc:
Data: Mon, 22 Oct 2012 07:10:59 -0000
Oggetto: [Bug 985525] Re: MRP : check_product very strict - BoM line product should not be same as BoM product.

> Dear all,
>
> Is there a way to disable that constraint?
>
> Thanks
>
> Henry
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1015679).
> https://bugs.launchpad.net/bugs/985525
>
> Title:
> MRP : check_product very strict - BoM line product should not be same
> as BoM product.
>
> Status in OpenERP Addons (modules):
> Confirmed
>
> Bug description:
> In openerp 6.1 on module MRP, there are a function to check product on BoM.
> BoM can't contained two lines or sublines with same product.
>
> For example, we have a bom (bomA) with two bom composent, I named it bcomp1 and bcomp2 .
> bcomp1 and bcomp2 contain a line with same product, product1 and parent bom is bomA.
> With check_product constraint, there are a problem on bomA.
>
> We work in electronic. bcomp1 and bcomp2 are bom of an electronic card
> and they used same LED (product1).
>
> Why this hard check and not checked products only on BoM and checked
> products of bom composent without memorised products of parent BoM ?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-addons/+bug/985525/+subscriptions

Revision history for this message
csmarvz (csmarvz) wrote :

Thanks Fabio, working for me

Revision history for this message
csmarvz (csmarvz) wrote :
Revision history for this message
csmarvz (csmarvz) wrote :

doesn't work anymore:

Client Traceback (most recent call last):
  File "C:\Program Files\OpenERP 6.1-20121001-232851\Server\server\openerp\addons\web\common\http.py", line 180, in dispatch
  File "C:\Program Files\OpenERP 6.1-20121001-232851\Server\server\openerp\addons\web\controllers\main.py", line 976, in save
  File "C:\Program Files\OpenERP 6.1-20121001-232851\Server\server\openerp\addons\web\common\openerplib\main.py", line 250, in proxy
  File "C:\Program Files\OpenERP 6.1-20121001-232851\Server\server\openerp\addons\web\common\openerplib\main.py", line 117, in proxy
  File "C:\Program Files\OpenERP 6.1-20121001-232851\Server\server\openerp\addons\web\common\http.py", line 608, in send

Server Traceback (most recent call last):
  File "C:\Program Files\OpenERP 6.1-20121001-232851\Server\server\openerp\addons\web\common\http.py", line 593, in send
  File "C:\Program Files\OpenERP 6.1-20121001-232851\Server\server\.\openerp\netsvc.py", line 360, in dispatch_rpc
  File "C:\Program Files\OpenERP 6.1-20121001-232851\Server\server\.\openerp\service\web_services.py", line 582, in dispatch
  File "C:\Program Files\OpenERP 6.1-20121001-232851\Server\server\.\openerp\service\security.py", line 40, in check
  File "C:\Program Files\OpenERP 6.1-20121001-232851\Server\server\.\openerp\pooler.py", line 50, in get_pool
  File "C:\Program Files\OpenERP 6.1-20121001-232851\Server\server\.\openerp\pooler.py", line 33, in get_db_and_pool
  File "C:\Program Files\OpenERP 6.1-20121001-232851\Server\server\.\openerp\modules\registry.py", line 180, in get
  File "C:\Program Files\OpenERP 6.1-20121001-232851\Server\server\.\openerp\modules\registry.py", line 202, in new
  File "C:\Program Files\OpenERP 6.1-20121001-232851\Server\server\.\openerp\modules\loading.py", line 334, in load_modules
  File "C:\Program Files\OpenERP 6.1-20121001-232851\Server\server\.\openerp\modules\loading.py", line 253, in load_marked_modules
  File "C:\Program Files\OpenERP 6.1-20121001-232851\Server\server\.\openerp\modules\loading.py", line 167, in load_module_graph
  File "C:\Program Files\OpenERP 6.1-20121001-232851\Server\server\.\openerp\modules\registry.py", line 109, in load
  File "C:\Program Files\OpenERP 6.1-20121001-232851\Server\server\.\openerp\osv\orm.py", line 877, in create_instance
TypeError: The model "mrp.bom" specifies an unexisting parent class "mrp.bom"
You may need to add a dependency on the parent class' module.

Changed in openobject-addons:
assignee: OpenERP R&D Addons Team 2 (openerp-dev-addons2) → OpenERP Publisher's Warranty Team (openerp-opw)
tags: added: maintenance
Revision history for this message
Ronald Portier (Therp) (rportier1962) wrote :

At present there are two constraints on a bom;

- bom line should not refer to the same product that it is the bom for;
- bom line should not be recursive.

IMHO these checks can easily be merged, while solving this bug.

Just overriding the check as the proposed patch is doing, might do away with a usefull constraint.

Might there be any situation that a user really needs to check that a product is nt used twice in a bom?

Otherwise I think the check against recursion should be sufficient in itself.

Revision history for this message
Fabio Colognesi (fabio-colognesi) wrote :

Hello,
In my opinion it could be more useful to leave the user free to activate this check or not.
Some people works using duplicated rows in BoM, some other doesn't.
But it's really boring to produce a patch to avoid this behavior.
A flag on MRP settings could be more efficient, leaving to users the choice of desired behavior.
Thanks
Fabio

Revision history for this message
Ronald Portier (Therp) (rportier1962) wrote :

One other thing:

The check against recursion is not working. Just created a recursive BOM withouth any problem at all.

Regards, Ronald

Revision history for this message
Ronald Portier (Therp) (rportier1962) wrote :

Fabio adn others,

Adding a flag for user preferences might be the best option for trunk, because it will need a change in the database.

For now I propose the following.

- Correct the check for recursion ta actually work

- Have the check that bomline should not have the same product as the bom it belongs to actuall do what the message says it does

- Have a separate module, that users can optionall install, that guards against duplicate products within a bom.

What do you think?

BTW the check against a bomline referring to itself is much more efficient to define as a SQL constraint.

Kind regards,

Ronald

Revision history for this message
Ronald Portier (Therp) (rportier1962) wrote :

One correction: SQL constraint can not be used for the product check, as check constraints only work on values in the current row.

Revision history for this message
Fabio Colognesi (fabio-colognesi) wrote :

For sure, check on recursion has to be reactivated.

I will prefer to have a flag on user preferences, to check the behavior (duplicates or not in BoM).

To manage existing installations, we could leave the standard behavior and use the short fix I have proposed, to unlock duplicates.

Revision history for this message
Ronald Portier (Therp) (rportier1962) wrote :

Note that this bug is not duplicate with this bug: https://bugs.launchpad.net/openobject-addons/+bug/1155569

But they are closely related.

no longer affects: ocb-addons
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.