unique constraint UNIQUE(product, bom) in production_bom_input and production_bom_output

[Ralf Peschke]

Hi,

is there a technical reason for this constraint or only the functional
one (a bom should have one part only one times listed)?
For our customer we need to remove this constraint, but are not sure if
there are any side affects removing it.

Thanks in advance

Ralf

--

Peschke IT-Beratung

Ralf Peschke
Hüffener Heide 3
D-32257 Bünde
Tel: 0049 (0)5223 - 97 89 079
Mobil: 0049 (0)175 - 32 72 561
E-Mail: rpes...@peschke-it.de
Homepage: www.peschke-it.de

[Sergi Almacellas Abellana]

El 10/05/17 a les 15:48, Ralf Peschke ha escrit:

> Hi,
>
> is there a technical reason for this constraint or only the functional
> one (a bom should have one part only one times listed)?

I don't think so.

> For our customer we need to remove this constraint, but are not sure if
> there are any side affects removing it.

Can you explain what your use case? Then we can give a better advice.


What's the objective of having the same input/output product on the same
production multiple times? Defining only one time the same product
easies the pick process.


--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk

[Cédric Krier]

On 2017-05-10 15:52, Sergi Almacellas Abellana wrote:
> El 10/05/17 a les 15:48, Ralf Peschke ha escrit:
> > Hi,
> >
> > is there a technical reason for this constraint or only the functional
> > one (a bom should have one part only one times listed)?
> I don't think so.

If I remember correctly, it is for the BOM.compute_factor
So maybe the constraint could be added only to output.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Ralf Peschke]

> El 10/05/17 a les 15:48, Ralf Peschke ha escrit:
>> Hi,
>>
>> is there a technical reason for this constraint or only the functional
>> one (a bom should have one part only one times listed)?
> I don't think so.

Very good!
Then we should remove the constraint from the module, when there is no
technical reason for it!?

>
>> For our customer we need to remove this constraint, but are not sure if
>> there are any side affects removing it.
> Can you explain what your use case? Then we can give a better advice.
>

Our customer gets bom's from his customers and sometimes they are using
the same product more than one times on same hierarchy level. Our
customer wants to keep the "original" boms. It is only unique together
with the position number and sometimes more a construction recipe than a
simple bom.

Problem is that it is not possible to remove the original constraint
without patching the module itself.
The _register_ method of the production module is executed before the
remove in the setup of the extending module is executed.

>
> What's the objective of having the same input/output product on the same
> production multiple times? Defining only one time the same product
> easies the pick process.
>
>

Sure, but we cannot convince all customers of our customer;-)

[Ralf Peschke]

Am 10.05.2017 um 18:19 schrieb Cédric Krier:
> On 2017-05-10 15:52, Sergi Almacellas Abellana wrote:
>> El 10/05/17 a les 15:48, Ralf Peschke ha escrit:
>>> Hi,
>>>
>>> is there a technical reason for this constraint or only the functional
>>> one (a bom should have one part only one times listed)?
>> I don't think so.
>
> If I remember correctly, it is for the BOM.compute_factor
> So maybe the constraint could be added only to output.
>

Thank you for this information.
Could we remove the constraint from the input bom? This would be
sufficient for us!

--

Peschke IT-Beratung

Ralf Peschke
Hüffener Heide 3
D-32257 Bünde
Tel: 0049 (0)5223 - 97 89 079
Mobil: 0049 (0)175 - 32 72 561
E-Mail: rpes...@peschke-it.de
Homepage: www.peschke-it.de

--------------------------------------
Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte
Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.

[Sergi Almacellas Abellana]

El 15/05/17 a les 11:09, Ralf Peschke ha escrit:

> Am 10.05.2017 um 18:19 schrieb Cédric Krier:
>> On 2017-05-10 15:52, Sergi Almacellas Abellana wrote:
>>> El 10/05/17 a les 15:48, Ralf Peschke ha escrit:
>>>> Hi,
>>>>
>>>> is there a technical reason for this constraint or only the functional
>>>> one (a bom should have one part only one times listed)?
>>> I don't think so.
>> If I remember correctly, it is for the BOM.compute_factor
>> So maybe the constraint could be added only to output.
>>
> Thank you for this information.
> Could we remove the constraint from the input bom? This would be
> sufficient for us!

I think so. So maybe you can contribute a patch as explained on:

http://www.tryton.org/how-to-contribute.html

Thanks!