What is the purpose of Routing Task Deliverable Products?

[Christian Carlow-OFBizzer]

Can someone explain the purpose of Routing Task Deliverable Products?  
Are deliverable products supposed to be documents or actual products?  I
added a deliverable product record for the first task of a route but I
do not notice any different in data after running and completing the
production run.

[Pierre Smits]

Christian,

Routing Task Deliverable Products are the products that can be declared as
a result of the execution of the task. You could regard these as a the
by-products of the production run. In an earlier thread I referenced
yeast-residiue as a by product. In the beer brewing process this is (often)
the output (beside beer, obviously) of the fermentation action, task or
process step.

Regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[Christian Carlow-OFBizzer]

Thanks Pierre,

I just discovered that Routing Task Deliverable Products controls the
productId field of the production run inventory declaration form.  
Whenever a deliverable product is specified then the declaration form
productId field changes to a drop down with only those deliverable
products specified listed.  If no deliverable products are specified
then the productId becomes a lookup and allows any products to be
declared.  I was unaware deliverable products could limit the
declaration form productIds.  This discovery will allow me to progress
further with OFBIZ-5568
<https://issues.apache.org/jira/browse/OFBIZ-5568>.  It should be
mentioned that preventing products other than those specified as
deliverable products is limited to the front end in which a drop down
appears only listing those deliverable products and that no backend code
exist to guarantee that users cannot change the dropdown values using
something like Firebug to hack the system and declare inventory for a
product other than the ones specified as deliverable products.  In other
words, if I create a deliverable product PEPPERS for the DEFAULT_TASK
but I use something like Firebug to change the drop down list value to
PEPPERS-G, then no logic exists in the backend to prevent PEPPERS-G from
being created.  I think such prevention logic should be implemented in
the backend as well.

On 03/10/2014 09:12 AM, Pierre Smits wrote:

> Christian,
>
> Routing Task Deliverable Products are the products that can be declared as
> a result of the execution of the task. You could regard these as a the
> by-products of the production run. In an earlier thread I referenced
> yeast-residiue as a by product. In the beer brewing process this is (often)
> the output (beside beer, obviously) of the fermentation action, task or
> process step.
>
> Regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>

[Christian Carlow-OFBizzer]

Can anyone think of reasons against changing the Routing Task
Deliverable Products to reference ProductAssoc instead of Product?  If
"BYPRODUCT" and "PRODUCT_REJECT" were added as ProductAssocType then the
entity could be used for implementing more advanced quantity checking
rules when by-products are declared.

On 03/10/2014 09:43 AM, Christian Carlow wrote:

> Thanks Pierre,
>
> I just discovered that Routing Task Deliverable Products controls the
> productId field of the production run inventory declaration form.  
> Whenever a deliverable product is specified then the declaration form
> productId field changes to a drop down with only those deliverable
> products specified listed.  If no deliverable products are specified
> then the productId becomes a lookup and allows any products to be
> declared.  I was unaware deliverable products could limit the
> declaration form productIds.  This discovery will allow me to progress
> further with OFBIZ-5568
> <https://issues.apache.org/jira/browse/OFBIZ-5568>.  It should be
> mentioned that preventing products other than those specified as
> deliverable products is limited to the front end in which a drop down
> appears only listing those deliverable products and that no backend
> code exist to guarantee that users cannot change the dropdown values
> using something like Firebug to hack the system and declare inventory
> for a product other than the ones specified as deliverable products.  
> In other words, if I create a deliverable product PEPPERS for the
> DEFAULT_TASK but I use something like Firebug to change the drop down
> list value to PEPPERS-G, then no logic exists in the backend to
> prevent PEPPERS-G from being created.  I think such prevention logic
> should be implemented in the backend as well.
>
> On 03/10/2014 09:12 AM, Pierre Smits wrote:
>> Christian,
>>
>> Routing Task Deliverable Products are the products that can be declared as
>> a result of the execution of the task. You could regard these as a the
>> by-products of the production run. In an earlier thread I referenced
>> yeast-residiue as a by product. In the beer brewing process this is (often)
>> the output (beside beer, obviously) of the fermentation action, task or
>> process step.
>>
>> Regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM<http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>

[Christian Carlow-OFBizzer]

If the reason field of ProductAssoc were changed to reference the
VarianceReason entity instead of being an open entry field, then the
ProductAssoc entity could be used for Deliverable Products definitions
and the reasons could the only thing that appears in the drop down.  
Anyone predict limitations or problems with such a suggestion?

On 03/10/2014 11:44 AM, Christian Carlow wrote:

> Can anyone think of reasons against changing the Routing Task
> Deliverable Products to reference ProductAssoc instead of Product?  If
> "BYPRODUCT" and "PRODUCT_REJECT" were added as ProductAssocType then
> the entity could be used for implementing more advanced quantity
> checking rules when by-products are declared.
>
> On 03/10/2014 09:43 AM, Christian Carlow wrote:
>> Thanks Pierre,
>>
>> I just discovered that Routing Task Deliverable Products controls the
>> productId field of the production run inventory declaration form.  
>> Whenever a deliverable product is specified then the declaration form
>> productId field changes to a drop down with only those deliverable
>> products specified listed. If no deliverable products are specified
>> then the productId becomes a lookup and allows any products to be
>> declared.  I was unaware deliverable products could limit the
>> declaration form productIds.  This discovery will allow me to
>> progress further with OFBIZ-5568
>> <https://issues.apache.org/jira/browse/OFBIZ-5568>.  It should be
>> mentioned that preventing products other than those specified as
>> deliverable products is limited to the front end in which a drop down
>> appears only listing those deliverable products and that no backend
>> code exist to guarantee that users cannot change the dropdown values
>> using something like Firebug to hack the system and declare inventory
>> for a product other than the ones specified as deliverable products.  
>> In other words, if I create a deliverable product PEPPERS for the
>> DEFAULT_TASK but I use something like Firebug to change the drop down
>> list value to PEPPERS-G, then no logic exists in the backend to
>> prevent PEPPERS-G from being created.  I think such prevention logic
>> should be implemented in the backend as well.
>>
>> On 03/10/2014 09:12 AM, Pierre Smits wrote:
>>> Christian,
>>>
>>> Routing Task Deliverable Products are the products that can be declared as
>>> a result of the execution of the task. You could regard these as a the
>>> by-products of the production run. In an earlier thread I referenced
>>> yeast-residiue as a by product. In the beer brewing process this is (often)
>>> the output (beside beer, obviously) of the fermentation action, task or
>>> process step.
>>>
>>> Regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM<http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>
>

[Christian Carlow-OFBizzer]

To provide the varianceReason drop down suggested in the previous post,
and entity such as ProductAssocVarianceReason could be created for
relating varianceReasons to the productId of ProductAssoc.  Once the
drop down is provided it, the ProductAssocVarianceReason can be used to
automatically create new variant by-product records and related them in
the ProductAssoc similar to the virtual variant auto-create methods.

On 03/10/2014 11:56 AM, Christian Carlow wrote:

> If the reason field of ProductAssoc were changed to reference the
> VarianceReason entity instead of being an open entry field, then the
> ProductAssoc entity could be used for Deliverable Products definitions
> and the reasons could the only thing that appears in the drop down.  
> Anyone predict limitations or problems with such a suggestion?
>
> On 03/10/2014 11:44 AM, Christian Carlow wrote:
>> Can anyone think of reasons against changing the Routing Task
>> Deliverable Products to reference ProductAssoc instead of Product?  
>> If "BYPRODUCT" and "PRODUCT_REJECT" were added as ProductAssocType
>> then the entity could be used for implementing more advanced quantity
>> checking rules when by-products are declared.
>>
>> On 03/10/2014 09:43 AM, Christian Carlow wrote:
>>> Thanks Pierre,
>>>
>>> I just discovered that Routing Task Deliverable Products controls
>>> the productId field of the production run inventory declaration
>>> form.  Whenever a deliverable product is specified then the
>>> declaration form productId field changes to a drop down with only
>>> those deliverable products specified listed.  If no deliverable
>>> products are specified then the productId becomes a lookup and
>>> allows any products to be declared.  I was unaware deliverable
>>> products could limit the declaration form productIds.  This
>>> discovery will allow me to progress further with OFBIZ-5568
>>> <https://issues.apache.org/jira/browse/OFBIZ-5568>.  It should be
>>> mentioned that preventing products other than those specified as
>>> deliverable products is limited to the front end in which a drop
>>> down appears only listing those deliverable products and that no
>>> backend code exist to guarantee that users cannot change the
>>> dropdown values using something like Firebug to hack the system and
>>> declare inventory for a product other than the ones specified as
>>> deliverable products.  In other words, if I create a deliverable
>>> product PEPPERS for the DEFAULT_TASK but I use something like
>>> Firebug to change the drop down list value to PEPPERS-G, then no
>>> logic exists in the backend to prevent PEPPERS-G from being
>>> created.  I think such prevention logic should be implemented in the
>>> backend as well.
>>>
>>> On 03/10/2014 09:12 AM, Pierre Smits wrote:
>>>> Christian,
>>>>
>>>> Routing Task Deliverable Products are the products that can be declared as
>>>> a result of the execution of the task. You could regard these as a the
>>>> by-products of the production run. In an earlier thread I referenced
>>>> yeast-residiue as a by product. In the beer brewing process this is (often)
>>>> the output (beside beer, obviously) of the fermentation action, task or
>>>> process step.
>>>>
>>>> Regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM<http://www.orrtiz.com>*
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> http://www.orrtiz.com
>>>>
>>>
>>
>

[Christian Carlow-OFBizzer]

Since by-product reason variance products wont exist ahead of time, they
can't be related in the WorkEffortGoodStandard entity as is the way it
is currently done. Instead, I think logic should be added to distinguish
between "PRUN_PROD_DELIV" for the production run and its tasks and when
used for a task, derive the variance reasons.  In other words, use
productId of ProductAssoc for WorkEffortGoodStandard for deliverable
products which triggers the retrieval of the variance reasons defined in
ProductAssocVarianceReason.  Anyone see potential issues with this?

On 03/10/2014 12:10 PM, Christian Carlow wrote:

> To provide the varianceReason drop down suggested in the previous
> post, and entity such as ProductAssocVarianceReason could be created
> for relating varianceReasons to the productId of ProductAssoc.  Once
> the drop down is provided it, the ProductAssocVarianceReason can be
> used to automatically create new variant by-product records and
> related them in the ProductAssoc similar to the virtual variant
> auto-create methods.
>
> On 03/10/2014 11:56 AM, Christian Carlow wrote:
>> If the reason field of ProductAssoc were changed to reference the
>> VarianceReason entity instead of being an open entry field, then the
>> ProductAssoc entity could be used for Deliverable Products
>> definitions and the reasons could the only thing that appears in the
>> drop down.  Anyone predict limitations or problems with such a
>> suggestion?
>>
>> On 03/10/2014 11:44 AM, Christian Carlow wrote:
>>> Can anyone think of reasons against changing the Routing Task
>>> Deliverable Products to reference ProductAssoc instead of Product?  
>>> If "BYPRODUCT" and "PRODUCT_REJECT" were added as ProductAssocType
>>> then the entity could be used for implementing more advanced
>>> quantity checking rules when by-products are declared.
>>>
>>> On 03/10/2014 09:43 AM, Christian Carlow wrote:
>>>> Thanks Pierre,
>>>>
>>>> I just discovered that Routing Task Deliverable Products controls
>>>> the productId field of the production run inventory declaration
>>>> form.  Whenever a deliverable product is specified then the
>>>> declaration form productId field changes to a drop down with only
>>>> those deliverable products specified listed.  If no deliverable
>>>> products are specified then the productId becomes a lookup and
>>>> allows any products to be declared.  I was unaware deliverable
>>>> products could limit the declaration form productIds. This
>>>> discovery will allow me to progress further with OFBIZ-5568
>>>> <https://issues.apache.org/jira/browse/OFBIZ-5568>.  It should be
>>>> mentioned that preventing products other than those specified as
>>>> deliverable products is limited to the front end in which a drop
>>>> down appears only listing those deliverable products and that no
>>>> backend code exist to guarantee that users cannot change the
>>>> dropdown values using something like Firebug to hack the system and
>>>> declare inventory for a product other than the ones specified as
>>>> deliverable products.  In other words, if I create a deliverable
>>>> product PEPPERS for the DEFAULT_TASK but I use something like
>>>> Firebug to change the drop down list value to PEPPERS-G, then no
>>>> logic exists in the backend to prevent PEPPERS-G from being
>>>> created.  I think such prevention logic should be implemented in
>>>> the backend as well.
>>>>
>>>> On 03/10/2014 09:12 AM, Pierre Smits wrote:
>>>>> Christian,
>>>>>
>>>>> Routing Task Deliverable Products are the products that can be declared as
>>>>> a result of the execution of the task. You could regard these as a the
>>>>> by-products of the production run. In an earlier thread I referenced
>>>>> yeast-residiue as a by product. In the beer brewing process this is (often)
>>>>> the output (beside beer, obviously) of the fermentation action, task or
>>>>> process step.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> *ORRTIZ.COM<http://www.orrtiz.com>*
>>>>> Services & Solutions for Cloud-
>>>>> Based Manufacturing, Professional
>>>>> Services and Retail & Trade
>>>>> http://www.orrtiz.com
>>>>>
>>>>
>>>
>>
>

[Christian Carlow-OFBizzer]

I'm moving forward since no one suggested any issues.  I have a feeling
that are aren't many out there using OFBiz for manufacturing and no one
seems very familiar other than Pierre and Jacopo.  A ProductReason
entity will be used in place of the ProductAssocVarianceReason entity
suggested in my previous post.  The ProductReason entity will reference
the varianceReasonId of the VarianceReason entity.  I don't want to get
too off track but it seems to make sense to generalize the
VarianceReason entity into just a Reason entity with type and parent
like other similar entities.  I might include this in the manufacturing
patches to come if no one is against it and it isn't too inconvenient.

On 03/10/2014 12:34 PM, Christian Carlow wrote:

> Since by-product reason variance products wont exist ahead of time,
> they can't be related in the WorkEffortGoodStandard entity as is the
> way it is currently done.  Instead, I think logic should be added to
> distinguish between "PRUN_PROD_DELIV" for the production run and its
> tasks and when used for a task, derive the variance reasons.  In other
> words, use productId of ProductAssoc for WorkEffortGoodStandard for
> deliverable products which triggers the retrieval of the variance
> reasons defined in ProductAssocVarianceReason.  Anyone see potential
> issues with this?
>
> On 03/10/2014 12:10 PM, Christian Carlow wrote:
>> To provide the varianceReason drop down suggested in the previous
>> post, and entity such as ProductAssocVarianceReason could be created
>> for relating varianceReasons to the productId of ProductAssoc.  Once
>> the drop down is provided it, the ProductAssocVarianceReason can be
>> used to automatically create new variant by-product records and
>> related them in the ProductAssoc similar to the virtual variant
>> auto-create methods.
>>
>> On 03/10/2014 11:56 AM, Christian Carlow wrote:
>>> If the reason field of ProductAssoc were changed to reference the
>>> VarianceReason entity instead of being an open entry field, then the
>>> ProductAssoc entity could be used for Deliverable Products
>>> definitions and the reasons could the only thing that appears in the
>>> drop down.  Anyone predict limitations or problems with such a
>>> suggestion?
>>>
>>> On 03/10/2014 11:44 AM, Christian Carlow wrote:
>>>> Can anyone think of reasons against changing the Routing Task
>>>> Deliverable Products to reference ProductAssoc instead of Product?  
>>>> If "BYPRODUCT" and "PRODUCT_REJECT" were added as ProductAssocType
>>>> then the entity could be used for implementing more advanced
>>>> quantity checking rules when by-products are declared.
>>>>
>>>> On 03/10/2014 09:43 AM, Christian Carlow wrote:
>>>>> Thanks Pierre,
>>>>>
>>>>> I just discovered that Routing Task Deliverable Products controls
>>>>> the productId field of the production run inventory declaration
>>>>> form.  Whenever a deliverable product is specified then the
>>>>> declaration form productId field changes to a drop down with only
>>>>> those deliverable products specified listed.  If no deliverable
>>>>> products are specified then the productId becomes a lookup and
>>>>> allows any products to be declared.  I was unaware deliverable
>>>>> products could limit the declaration form productIds.  This
>>>>> discovery will allow me to progress further with OFBIZ-5568
>>>>> <https://issues.apache.org/jira/browse/OFBIZ-5568>.  It should be
>>>>> mentioned that preventing products other than those specified as
>>>>> deliverable products is limited to the front end in which a drop
>>>>> down appears only listing those deliverable products and that no
>>>>> backend code exist to guarantee that users cannot change the
>>>>> dropdown values using something like Firebug to hack the system
>>>>> and declare inventory for a product other than the ones specified
>>>>> as deliverable products.  In other words, if I create a
>>>>> deliverable product PEPPERS for the DEFAULT_TASK but I use
>>>>> something like Firebug to change the drop down list value to
>>>>> PEPPERS-G, then no logic exists in the backend to prevent
>>>>> PEPPERS-G from being created.  I think such prevention logic
>>>>> should be implemented in the backend as well.
>>>>>
>>>>> On 03/10/2014 09:12 AM, Pierre Smits wrote:
>>>>>> Christian,
>>>>>>
>>>>>> Routing Task Deliverable Products are the products that can be declared as
>>>>>> a result of the execution of the task. You could regard these as a the
>>>>>> by-products of the production run. In an earlier thread I referenced
>>>>>> yeast-residiue as a by product. In the beer brewing process this is (often)
>>>>>> the output (beside beer, obviously) of the fermentation action, task or
>>>>>> process step.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Pierre Smits
>>>>>>
>>>>>> *ORRTIZ.COM<http://www.orrtiz.com>*
>>>>>> Services & Solutions for Cloud-
>>>>>> Based Manufacturing, Professional
>>>>>> Services and Retail & Trade
>>>>>> http://www.orrtiz.com
>>>>>>
>>>>>
>>>>
>>>
>>
>

[Pierre Smits]

Christian,

It is ok when you go ahead with trying to solve this issue that you have
within your companies implementation.

Unfortunately, it seems that you believe that others than you don't have
have schedules to meet. Please understand that the contributions and/or
questions you posted need time to get assessed regarding impact and
applicability.

Regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[Jacques Le Roux]

Feel free to create a Jira

BTW I saw you asked a lot of question on manufacturing. I know it's only a book for newbies, but if ever you have not it on your shelf, I will
recommend you Sharan's book (see books page on wiki)

Jacques

Le 10/03/2014 15:43, Christian Carlow a écrit :

> Thanks Pierre,
>
> I just discovered that Routing Task Deliverable Products controls the productId field of the production run inventory declaration form.  Whenever a
> deliverable product is specified then the declaration form productId field changes to a drop down with only those deliverable products specified
> listed.  If no deliverable products are specified then the productId becomes a lookup and allows any products to be declared.  I was unaware
> deliverable products could limit the declaration form productIds.  This discovery will allow me to progress further with OFBIZ-5568
> <https://issues.apache.org/jira/browse/OFBIZ-5568>.  It should be mentioned that preventing products other than those specified as deliverable
> products is limited to the front end in which a drop down appears only listing those deliverable products and that no backend code exist to
> guarantee that users cannot change the dropdown values using something like Firebug to hack the system and declare inventory for a product other
> than the ones specified as deliverable products.  In other words, if I create a deliverable product PEPPERS for the DEFAULT_TASK but I use something
> like Firebug to change the drop down list value to PEPPERS-G, then no logic exists in the backend to prevent PEPPERS-G from being created.  I think
> such prevention logic should be implemented in the backend as well.
>
> On 03/10/2014 09:12 AM, Pierre Smits wrote:
>> Christian,
>>
>> Routing Task Deliverable Products are the products that can be declared as
>> a result of the execution of the task. You could regard these as a the
>> by-products of the production run. In an earlier thread I referenced
>> yeast-residiue as a by product. In the beer brewing process this is (often)
>> the output (beside beer, obviously) of the fermentation action, task or
>> process step.
>>
>> Regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>
>