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
