Re: How to track manufacturing rejects by employee based on inspection production run task rejections? Add TimeEntryAssoc entity?

[Christian Carlow]

I changed the title to be more clear.

The company ticket system has inspection functionality that allows 
inspectors to declare multiple types of rejects for the quantity 
specified on manufacturing tickets.  This functionality doesn't seem 
supported in OFBiz.  I've see no way to determine that a worker from a 
production run inspection task inspected work done by a particular 
worker in the prior manufacturing step.  The company relies on this 
functionality to generated a percentage good by employee report that 
analyzes the inspections for rejections and looks at its related 
manufacturing ticket to determine which manufacturing workers produced 
rejects.


I created OFBIZ-5532  
to allow time entries to be created during production run task 
declarations.  To support the functionality explained above, I think the 
an extension would be necessary for relating time entries.  Something 
such as TimeEntryAssoc could be created to relate the inspection task 
time entry to the manufacturing task time entry so that the actual 
workers and associated quantities could be determined.


On 02/24/2014 11:03 AM, Christian Carlow wrote:
Does anyone know how to track manufacturing rejects by employee?  I 
created a production run containing a first task that represents 
manufacturing work and a second that represents the inspection work.  
I need to be able to determine how many bad pieces were caused by the 
employee associated with the first manufacturing task based on 
rejection declarations by the employee associated with the second 
task.  The only way I can think of supporting this is to have some 
relationship between the time entries that relate to the production 
run tasks.

Re: How to track manufacturing rejects by employee based on inspection production run task rejections? Add TimeEntryAssoc entity?

[Christian Carlow]

Another related issue is how to determine the particular rejection 
reasons.  Inspectors may declare rejected pieces as by-products during 
production run inspection steps that may be capable of rework.  The 
percentage good by employee report mentioned in the previous post also 
displays the reasons associated with each rejection.  Each of the 
rejection reason codes were converted to individual products within 
OFBiz, but the problem is how to relate those rejection products 
declared to the inspector work effort time entries. Adding timeEntryId 
to the InventoryItemDetail entity seems to provide a way of relating 
time entries created by production run task declarations.  Is anyone 
against adding timeEntryId to InventoryItemDetail?


On 02/24/2014 12:14 PM, Christian Carlow wrote:

I changed the title to be more clear.

The company ticket system has inspection functionality that allows 
inspectors to declare multiple types of rejects for the quantity 
specified on manufacturing tickets.  This functionality doesn't seem 
supported in OFBiz.  I've see no way to determine that a worker from a 
production run inspection task inspected work done by a particular 
worker in the prior manufacturing step.  The company relies on this 
functionality to generated a percentage good by employee report that 
analyzes the inspections for rejections and looks at its related 
manufacturing ticket to determine which manufacturing workers produced 
rejects.


I created OFBIZ-5532 
 to allow time 
entries to be created during production run task declarations. To 
support the functionality explained above, I think the an extension 
would be necessary for relating time entries. Something such as 
TimeEntryAssoc could be created to relate the inspection task time 
entry to the manufacturing task time entry so that the actual workers 
and associated quantities could be determined.


On 02/24/2014 11:03 AM, Christian Carlow wrote:
Does anyone know how to track manufacturing rejects by employee?  I 
created a production run containing a first task that represents 
manufacturing work and a second that represents the inspection work.  
I need to be able to determine how many bad pieces were caused by the 
employee associated with the first manufacturing task based on 
rejection declarations by the employee associated with the second 
task.  The only way I can think of supporting this is to have some 
relationship between the time entries that relate to the production 
run tasks.

Re: How to track manufacturing rejects by employee based on inspection production run task rejections? Add TimeEntryAssoc entity?

[Christian Carlow]

Is there a reason the two Production Run Declaration 
(manufacturing/control/ProductionRunDeclaration) forms cannot be 
combined into a single form?  If the first form is used to declare 
rejections, why can't the by-products products be declared as inventory 
in the same form instead of having to be done using the second form?


On 02/24/2014 12:36 PM, Christian Carlow wrote:
Another related issue is how to determine the particular rejection 
reasons.  Inspectors may declare rejected pieces as by-products during 
production run inspection steps that may be capable of rework.  The 
percentage good by employee report mentioned in the previous post also 
displays the reasons associated with each rejection.  Each of the 
rejection reason codes were converted to individual products within 
OFBiz, but the problem is how to relate those rejection products 
declared to the inspector work effort time entries. Adding timeEntryId 
to the InventoryItemDetail entity seems to provide a way of relating 
time entries created by production run task declarations.  Is anyone 
against adding timeEntryId to InventoryItemDetail?


On 02/24/2014 12:14 PM, Christian Carlow wrote:

I changed the title to be more clear.

The company ticket system has inspection functionality that allows 
inspectors to declare multiple types of rejects for the quantity 
specified on manufacturing tickets.  This functionality doesn't seem 
supported in OFBiz.  I've see no way to determine that a worker from 
a production run inspection task inspected work done by a particular 
worker in the prior manufacturing step.  The company relies on this 
functionality to generated a percentage good by employee report that 
analyzes the inspections for rejections and looks at its related 
manufacturing ticket to determine which manufacturing workers 
produced rejects.


I created OFBIZ-5532 
 to allow time 
entries to be created during production run task declarations.  To 
support the functionality explained above, I think the an extension 
would be necessary for relating time entries.  Something such as 
TimeEntryAssoc could be created to relate the inspection task time 
entry to the manufacturing task time entry so that the actual workers 
and associated quantities could be determined.


On 02/24/2014 11:03 AM, Christian Carlow wrote:
Does anyone know how to track manufacturing rejects by employee?  I 
created a production run containing a first task that represents 
manufacturing work and a second that represents the inspection 
work.  I need to be able to determine how many bad pieces were 
caused by the employee associated with the first manufacturing task 
based on rejection declarations by the employee associated with the 
second task.  The only way I can think of supporting this is to have 
some relationship between the time entries that relate to the 
production run tasks.

Re: How to track manufacturing rejects by employee based on inspection production run task rejections? Add TimeEntryAssoc entity?

[Christian Carlow]

My last post can be disregarded, splitting the production run 
declaration into two different forms seems correct.  There needs to be a 
way to relate time entries created from the first form to inventory item 
details created in the second form so that the types of rejects that 
were produced from time entries can be determined.


On 02/24/2014 01:05 PM, Christian Carlow wrote:
Is there a reason the two Production Run Declaration 
(manufacturing/control/ProductionRunDeclaration) forms cannot be 
combined into a single form?  If the first form is used to declare 
rejections, why can't the by-products products be declared as 
inventory in the same form instead of having to be done using the 
second form?


On 02/24/2014 12:36 PM, Christian Carlow wrote:
Another related issue is how to determine the particular rejection 
reasons.  Inspectors may declare rejected pieces as by-products 
during production run inspection steps that may be capable of 
rework.  The percentage good by employee report mentioned in the 
previous post also displays the reasons associated with each 
rejection.  Each of the rejection reason codes were converted to 
individual products within OFBiz, but the problem is how to relate 
those rejection products declared to the inspector work effort time 
entries.  Adding timeEntryId to the InventoryItemDetail entity seems 
to provide a way of relating time entries created by production run 
task declarations.  Is anyone against adding timeEntryId to 
InventoryItemDetail?


On 02/24/2014 12:14 PM, Christian Carlow wrote:

I changed the title to be more clear.

The company ticket system has inspection functionality that allows 
inspectors to declare multiple types of rejects for the quantity 
specified on manufacturing tickets.  This functionality doesn't seem 
supported in OFBiz.  I've see no way to determine that a worker from 
a production run inspection task inspected work done by a particular 
worker in the prior manufacturing step.  The company relies on this 
functionality to generated a percentage good by employee report that 
analyzes the inspections for rejections and looks at its related 
manufacturing ticket to determine which manufacturing workers 
produced rejects.


I created OFBIZ-5532 
 to allow time 
entries to be created during production run task declarations.  To 
support the functionality explained above, I think the an extension 
would be necessary for relating time entries.  Something such as 
TimeEntryAssoc could be created to relate the inspection task time 
entry to the manufacturing task time entry so that the actual 
workers and associated quantities could be determined.


On 02/24/2014 11:03 AM, Christian Carlow wrote:
Does anyone know how to track manufacturing rejects by employee? I 
created a production run containing a first task that represents 
manufacturing work and a second that represents the inspection 
work.  I need to be able to determine how many bad pieces were 
caused by the employee associated with the first manufacturing task 
based on rejection declarations by the employee associated with the 
second task.  The only way I can think of supporting this is to 
have some relationship between the time entries that relate to the 
production run tasks.

Re: How to track manufacturing rejects by employee based on inspection production run task rejections? Add TimeEntryAssoc entity?

[Christian Carlow]

After making some progress on this issue by adding the 
timesheet/timeentry functionality to the production run task declaration 
services, I've encountered more difficulties implementing the needed 
functionality.  I added a TimeEntryAssoc entity so that inspectors can 
directly inspect a manufacturing workers prior time entry.  I was going 
to use the TimeEntryAssoc entity to determine the number of bad pieces 
per manufacturing worker by looking at the inspection timeEntry 
quantityRejected and extracting the related manufacturing time entry 
partyId.  The problem with this is that sometimes rejected quantity on 
the inspection ticket might represent faults on the inspectors part 
rather than the manufacturers such as if the inspector drops parts.  For 
this case the inspector should be considered the one who caused the bad 
piece not the manufacturer.


To determine the party at fault for rejected pieces it seems there needs 
to be another entity created to track the info.  Maybe something like 
TimeEntryRejectParty that divides the time entry rejected quantity and 
applies them to the parties actually responsible for the rejects.


The only alternative I've come up with other than adding a new 
TimeEntryRejectParty is to assign the faulty partyId to the 
inventoryItemDetail record that would be created for the by-products 
declared to account for the rejects.  But this method is dependent on 
by-products always being declared when rejects occur which might not 
always happen.  Therefore it seems creating a dedicated entity like 
TimeEntryRejectParty is the better method.


Anyone have any thoughts on this issue?

On 02/24/2014 01:37 PM, Christian Carlow wrote:
My last post can be disregarded, splitting the production run 
declaration into two different forms seems correct.  There needs to be 
a way to relate time entries created from the first form to inventory 
item details created in the second form so that the types of rejects 
that were produced from time entries can be determined.


On 02/24/2014 01:05 PM, Christian Carlow wrote:
Is there a reason the two Production Run Declaration 
(manufacturing/control/ProductionRunDeclaration) forms cannot be 
combined into a single form?  If the first form is used to declare 
rejections, why can't the by-products products be declared as 
inventory in the same form instead of having to be done using the 
second form?


On 02/24/2014 12:36 PM, Christian Carlow wrote:
Another related issue is how to determine the particular rejection 
reasons.  Inspectors may declare rejected pieces as by-products 
during production run inspection steps that may be capable of 
rework.  The percentage good by employee report mentioned in the 
previous post also displays the reasons associated with each 
rejection.  Each of the rejection reason codes were converted to 
individual products within OFBiz, but the problem is how to relate 
those rejection products declared to the inspector work effort time 
entries.  Adding timeEntryId to the InventoryItemDetail entity seems 
to provide a way of relating time entries created by production run 
task declarations.  Is anyone against adding timeEntryId to 
InventoryItemDetail?


On 02/24/2014 12:14 PM, Christian Carlow wrote:

I changed the title to be more clear.

The company ticket system has inspection functionality that allows 
inspectors to declare multiple types of rejects for the quantity 
specified on manufacturing tickets.  This functionality doesn't 
seem supported in OFBiz.  I've see no way to determine that a 
worker from a production run inspection task inspected work done by 
a particular worker in the prior manufacturing step.  The company 
relies on this functionality to generated a percentage good by 
employee report that analyzes the inspections for rejections and 
looks at its related manufacturing ticket to determine which 
manufacturing workers produced rejects.


I created OFBIZ-5532 
 to allow time 
entries to be created during production run task declarations.  To 
support the functionality explained above, I think the an extension 
would be necessary for relating time entries.  Something such as 
TimeEntryAssoc could be created to relate the inspection task time 
entry to the manufacturing task time entry so that the actual 
workers and associated quantities could be determined.


On 02/24/2014 11:03 AM, Christian Carlow wrote:
Does anyone know how to track manufacturing rejects by employee?  
I created a production run containing a first task that represents 
manufacturing work and a second that represents the inspection 
work.  I need to be able to determine how many bad pieces were 
caused by the employee associated with the first manufacturing 
task based on rejection declarations by the employee associated 
with the second task.  The only way I can think of supporting this 
is to have some relationship between the time entries that relate 
to the production 

Re: How to track manufacturing rejects by employee based on inspection production run task rejections? Add TimeEntryAssoc entity?

[Christian Carlow]

I suppose the TimeEntryAssoc entity could be extended to include 
quantityRejected and responsiblePartyId fields to eliminate the need for 
a separate TimeEntryRejectParty entity.


On 02/27/2014 08:53 AM, Christian Carlow wrote:
After making some progress on this issue by adding the 
timesheet/timeentry functionality to the production run task 
declaration services, I've encountered more difficulties implementing 
the needed functionality.  I added a TimeEntryAssoc entity so that 
inspectors can directly inspect a manufacturing workers prior time 
entry.  I was going to use the TimeEntryAssoc entity to determine the 
number of bad pieces per manufacturing worker by looking at the 
inspection timeEntry quantityRejected and extracting the related 
manufacturing time entry partyId.  The problem with this is that 
sometimes rejected quantity on the inspection ticket might represent 
faults on the inspectors part rather than the manufacturers such as if 
the inspector drops parts.  For this case the inspector should be 
considered the one who caused the bad piece not the manufacturer.


To determine the party at fault for rejected pieces it seems there 
needs to be another entity created to track the info. Maybe something 
like TimeEntryRejectParty that divides the time entry rejected 
quantity and applies them to the parties actually responsible for the 
rejects.


The only alternative I've come up with other than adding a new 
TimeEntryRejectParty is to assign the faulty partyId to the 
inventoryItemDetail record that would be created for the by-products 
declared to account for the rejects.  But this method is dependent on 
by-products always being declared when rejects occur which might not 
always happen.  Therefore it seems creating a dedicated entity like 
TimeEntryRejectParty is the better method.


Anyone have any thoughts on this issue?

On 02/24/2014 01:37 PM, Christian Carlow wrote:
My last post can be disregarded, splitting the production run 
declaration into two different forms seems correct.  There needs to 
be a way to relate time entries created from the first form to 
inventory item details created in the second form so that the types 
of rejects that were produced from time entries can be determined.


On 02/24/2014 01:05 PM, Christian Carlow wrote:
Is there a reason the two Production Run Declaration 
(manufacturing/control/ProductionRunDeclaration) forms cannot be 
combined into a single form?  If the first form is used to declare 
rejections, why can't the by-products products be declared as 
inventory in the same form instead of having to be done using the 
second form?


On 02/24/2014 12:36 PM, Christian Carlow wrote:
Another related issue is how to determine the particular rejection 
reasons.  Inspectors may declare rejected pieces as by-products 
during production run inspection steps that may be capable of 
rework.  The percentage good by employee report mentioned in the 
previous post also displays the reasons associated with each 
rejection.  Each of the rejection reason codes were converted to 
individual products within OFBiz, but the problem is how to relate 
those rejection products declared to the inspector work effort time 
entries. Adding timeEntryId to the InventoryItemDetail entity seems 
to provide a way of relating time entries created by production run 
task declarations.  Is anyone against adding timeEntryId to 
InventoryItemDetail?


On 02/24/2014 12:14 PM, Christian Carlow wrote:

I changed the title to be more clear.

The company ticket system has inspection functionality that allows 
inspectors to declare multiple types of rejects for the quantity 
specified on manufacturing tickets.  This functionality doesn't 
seem supported in OFBiz.  I've see no way to determine that a 
worker from a production run inspection task inspected work done 
by a particular worker in the prior manufacturing step. The 
company relies on this functionality to generated a percentage 
good by employee report that analyzes the inspections for 
rejections and looks at its related manufacturing ticket to 
determine which manufacturing workers produced rejects.


I created OFBIZ-5532 
 to allow time 
entries to be created during production run task declarations.  To 
support the functionality explained above, I think the an 
extension would be necessary for relating time entries.  Something 
such as TimeEntryAssoc could be created to relate the inspection 
task time entry to the manufacturing task time entry so that the 
actual workers and associated quantities could be determined.


On 02/24/2014 11:03 AM, Christian Carlow wrote:
Does anyone know how to track manufacturing rejects by employee?  
I created a production run containing a first task that 
represents manufacturing work and a second that represents the 
inspection work. I need to be able to determine how many bad 
pieces were caused by the employee associated with the first 
manuf

Re: How to track manufacturing rejects by employee based on inspection production run task rejections? Add TimeEntryAssoc entity?

[Christian Carlow]

I'm now aware of more complexity.  The inspector supervisor explained 
that partial inspections sometimes occur for which parts are moved from 
a manufacturing dept to an inspection dept that performs partial 
inspection and then sends to another manufacturing dept that ends up 
sending the parts to a final inspection dept for full inspection.  But 
if rejects are declared at the final full inspection stage, then the 
fault is supposed to be applied to the initially manufacturing worker 
not the intermediate one that performs the work after partial inspection.


I think the TimeEntryAssoc should be extended to handle inspection 
associations to both the prior manufacturing stage from which the pieces 
were sent and the manufacturing stage considered at fault for the 
rejects.  Associations between the inspection stage to the prior 
manufacturing stage is necessary for the inspection dept to determine 
how many pieces are left to inspect.


I think some field like timeEntryAssocTypeId could be used to 
distinguish associations of inspection time entries to the prior 
manufacturing stage from those to the faulty manufacturing stage. 
TIME_ENTRY_DEPENDENCY could be used to associate the inspection task to 
the prior manufacturing task and something like TIME_ENTRY_REJECT (with 
parent TIME_ENTRY_DEPENDENCY) could be used to indicate the faulty 
manufacturing task.


This would possibly entail a new TimeEntryAssocType entity.

On 02/27/2014 09:06 AM, Christian Carlow wrote:
I suppose the TimeEntryAssoc entity could be extended to include 
quantityRejected and responsiblePartyId fields to eliminate the need 
for a separate TimeEntryRejectParty entity.


On 02/27/2014 08:53 AM, Christian Carlow wrote:
After making some progress on this issue by adding the 
timesheet/timeentry functionality to the production run task 
declaration services, I've encountered more difficulties implementing 
the needed functionality.  I added a TimeEntryAssoc entity so that 
inspectors can directly inspect a manufacturing workers prior time 
entry.  I was going to use the TimeEntryAssoc entity to determine the 
number of bad pieces per manufacturing worker by looking at the 
inspection timeEntry quantityRejected and extracting the related 
manufacturing time entry partyId.  The problem with this is that 
sometimes rejected quantity on the inspection ticket might represent 
faults on the inspectors part rather than the manufacturers such as 
if the inspector drops parts. For this case the inspector should be 
considered the one who caused the bad piece not the manufacturer.


To determine the party at fault for rejected pieces it seems there 
needs to be another entity created to track the info. Maybe something 
like TimeEntryRejectParty that divides the time entry rejected 
quantity and applies them to the parties actually responsible for the 
rejects.


The only alternative I've come up with other than adding a new 
TimeEntryRejectParty is to assign the faulty partyId to the 
inventoryItemDetail record that would be created for the by-products 
declared to account for the rejects.  But this method is dependent on 
by-products always being declared when rejects occur which might not 
always happen.  Therefore it seems creating a dedicated entity like 
TimeEntryRejectParty is the better method.


Anyone have any thoughts on this issue?

On 02/24/2014 01:37 PM, Christian Carlow wrote:
My last post can be disregarded, splitting the production run 
declaration into two different forms seems correct.  There needs to 
be a way to relate time entries created from the first form to 
inventory item details created in the second form so that the types 
of rejects that were produced from time entries can be determined.


On 02/24/2014 01:05 PM, Christian Carlow wrote:
Is there a reason the two Production Run Declaration 
(manufacturing/control/ProductionRunDeclaration) forms cannot be 
combined into a single form?  If the first form is used to declare 
rejections, why can't the by-products products be declared as 
inventory in the same form instead of having to be done using the 
second form?


On 02/24/2014 12:36 PM, Christian Carlow wrote:
Another related issue is how to determine the particular rejection 
reasons. Inspectors may declare rejected pieces as by-products 
during production run inspection steps that may be capable of 
rework.  The percentage good by employee report mentioned in the 
previous post also displays the reasons associated with each 
rejection.  Each of the rejection reason codes were converted to 
individual products within OFBiz, but the problem is how to relate 
those rejection products declared to the inspector work effort 
time entries.  Adding timeEntryId to the InventoryItemDetail 
entity seems to provide a way of relating time entries created by 
production run task declarations.  Is anyone against adding 
timeEntryId to InventoryItemDetail?


On 02/24/2014 12:14 PM, Christian Carlow wrote:

I changed the title 

Re: How to track manufacturing rejects by employee based on inspection production run task rejections? Add TimeEntryAssoc entity?

[Christian Carlow]

I've made more progress on this issue but it seems another entity might 
be needed to support the intended functionality.  In a previous post I 
suggested adding the timeEntryId field to the InventoryItemDetail entity 
to track by-products created by production run task time entries.  I 
need a way to determine how many by-products have actually been created 
by a task time entry and InventoryItemDetail.quantityOnHandDiff isn't 
sufficient because it doesn't account for possible InventoryItem 
corrections.  Therefore an entity such as TimeEntryInventoryProduced 
will probably have to be created similar to WorkEffortInventoryProduced.


On 02/27/2014 10:39 AM, Christian Carlow wrote:
I'm now aware of more complexity. The inspector supervisor explained 
that partial inspections sometimes occur for which parts are moved 
from a manufacturing dept to an inspection dept that performs partial 
inspection and then sends to another manufacturing dept that ends up 
sending the parts to a final inspection dept for full inspection.  But 
if rejects are declared at the final full inspection stage, then the 
fault is supposed to be applied to the initially manufacturing worker 
not the intermediate one that performs the work after partial inspection.


I think the TimeEntryAssoc should be extended to handle inspection 
associations to both the prior manufacturing stage from which the 
pieces were sent and the manufacturing stage considered at fault for 
the rejects.  Associations between the inspection stage to the prior 
manufacturing stage is necessary for the inspection dept to determine 
how many pieces are left to inspect.


I think some field like timeEntryAssocTypeId could be used to 
distinguish associations of inspection time entries to the prior 
manufacturing stage from those to the faulty manufacturing stage.  
TIME_ENTRY_DEPENDENCY could be used to associate the inspection task 
to the prior manufacturing task and something like TIME_ENTRY_REJECT 
(with parent TIME_ENTRY_DEPENDENCY) could be used to indicate the 
faulty manufacturing task.


This would possibly entail a new TimeEntryAssocType entity.

On 02/27/2014 09:06 AM, Christian Carlow wrote:
I suppose the TimeEntryAssoc entity could be extended to include 
quantityRejected and responsiblePartyId fields to eliminate the need 
for a separate TimeEntryRejectParty entity.


On 02/27/2014 08:53 AM, Christian Carlow wrote:
After making some progress on this issue by adding the 
timesheet/timeentry functionality to the production run task 
declaration services, I've encountered more difficulties 
implementing the needed functionality.  I added a TimeEntryAssoc 
entity so that inspectors can directly inspect a manufacturing 
workers prior time entry.  I was going to use the TimeEntryAssoc 
entity to determine the number of bad pieces per manufacturing 
worker by looking at the inspection timeEntry quantityRejected and 
extracting the related manufacturing time entry partyId.  The 
problem with this is that sometimes rejected quantity on the 
inspection ticket might represent faults on the inspectors part 
rather than the manufacturers such as if the inspector drops parts.  
For this case the inspector should be considered the one who caused 
the bad piece not the manufacturer.


To determine the party at fault for rejected pieces it seems there 
needs to be another entity created to track the info. Maybe 
something like TimeEntryRejectParty that divides the time entry 
rejected quantity and applies them to the parties actually 
responsible for the rejects.


The only alternative I've come up with other than adding a new 
TimeEntryRejectParty is to assign the faulty partyId to the 
inventoryItemDetail record that would be created for the by-products 
declared to account for the rejects.  But this method is dependent 
on by-products always being declared when rejects occur which might 
not always happen.  Therefore it seems creating a dedicated entity 
like TimeEntryRejectParty is the better method.


Anyone have any thoughts on this issue?

On 02/24/2014 01:37 PM, Christian Carlow wrote:
My last post can be disregarded, splitting the production run 
declaration into two different forms seems correct.  There needs to 
be a way to relate time entries created from the first form to 
inventory item details created in the second form so that the types 
of rejects that were produced from time entries can be determined.


On 02/24/2014 01:05 PM, Christian Carlow wrote:
Is there a reason the two Production Run Declaration 
(manufacturing/control/ProductionRunDeclaration) forms cannot be 
combined into a single form?  If the first form is used to declare 
rejections, why can't the by-products products be declared as 
inventory in the same form instead of having to be done using the 
second form?


On 02/24/2014 12:36 PM, Christian Carlow wrote:
Another related issue is how to determine the particular 
rejection reasons. Inspectors may declare rejected pieces as 
by-p

Re: How to track manufacturing rejects by employee based on inspection production run task rejections? Add TimeEntryAssoc entity?

[Jacques Le Roux]

Will you share your effort on this in a Jira?

Jacques

Le 28/02/2014 23:32, Christian Carlow a écrit :
I've made more progress on this issue but it seems another entity might be needed to support the intended functionality.  In a previous post I 
suggested adding the timeEntryId field to the InventoryItemDetail entity to track by-products created by production run task time entries.  I need a 
way to determine how many by-products have actually been created by a task time entry and InventoryItemDetail.quantityOnHandDiff isn't sufficient 
because it doesn't account for possible InventoryItem corrections.  Therefore an entity such as TimeEntryInventoryProduced will probably have to be 
created similar to WorkEffortInventoryProduced.


On 02/27/2014 10:39 AM, Christian Carlow wrote:
I'm now aware of more complexity. The inspector supervisor explained that partial inspections sometimes occur for which parts are moved from a 
manufacturing dept to an inspection dept that performs partial inspection and then sends to another manufacturing dept that ends up sending the 
parts to a final inspection dept for full inspection.  But if rejects are declared at the final full inspection stage, then the fault is supposed 
to be applied to the initially manufacturing worker not the intermediate one that performs the work after partial inspection.


I think the TimeEntryAssoc should be extended to handle inspection associations to both the prior manufacturing stage from which the pieces were 
sent and the manufacturing stage considered at fault for the rejects.  Associations between the inspection stage to the prior manufacturing stage 
is necessary for the inspection dept to determine how many pieces are left to inspect.


I think some field like timeEntryAssocTypeId could be used to distinguish associations of inspection time entries to the prior manufacturing stage 
from those to the faulty manufacturing stage.  TIME_ENTRY_DEPENDENCY could be used to associate the inspection task to the prior manufacturing task 
and something like TIME_ENTRY_REJECT (with parent TIME_ENTRY_DEPENDENCY) could be used to indicate the faulty manufacturing task.


This would possibly entail a new TimeEntryAssocType entity.

On 02/27/2014 09:06 AM, Christian Carlow wrote:
I suppose the TimeEntryAssoc entity could be extended to include quantityRejected and responsiblePartyId fields to eliminate the need for a 
separate TimeEntryRejectParty entity.


On 02/27/2014 08:53 AM, Christian Carlow wrote:
After making some progress on this issue by adding the timesheet/timeentry functionality to the production run task declaration services, I've 
encountered more difficulties implementing the needed functionality.  I added a TimeEntryAssoc entity so that inspectors can directly inspect a 
manufacturing workers prior time entry. I was going to use the TimeEntryAssoc entity to determine the number of bad pieces per manufacturing 
worker by looking at the inspection timeEntry quantityRejected and extracting the related manufacturing time entry partyId.  The problem with 
this is that sometimes rejected quantity on the inspection ticket might represent faults on the inspectors part rather than the manufacturers 
such as if the inspector drops parts.  For this case the inspector should be considered the one who caused the bad piece not the manufacturer.


To determine the party at fault for rejected pieces it seems there needs to be another entity created to track the info. Maybe something like 
TimeEntryRejectParty that divides the time entry rejected quantity and applies them to the parties actually responsible for the rejects.


The only alternative I've come up with other than adding a new TimeEntryRejectParty is to assign the faulty partyId to the inventoryItemDetail 
record that would be created for the by-products declared to account for the rejects.  But this method is dependent on by-products always being 
declared when rejects occur which might not always happen.  Therefore it seems creating a dedicated entity like TimeEntryRejectParty is the 
better method.


Anyone have any thoughts on this issue?

On 02/24/2014 01:37 PM, Christian Carlow wrote:
My last post can be disregarded, splitting the production run declaration into two different forms seems correct.  There needs to be a way to 
relate time entries created from the first form to inventory item details created in the second form so that the types of rejects that were 
produced from time entries can be determined.


On 02/24/2014 01:05 PM, Christian Carlow wrote:
Is there a reason the two Production Run Declaration (manufacturing/control/ProductionRunDeclaration) forms cannot be combined into a single 
form?  If the first form is used to declare rejections, why can't the by-products products be declared as inventory in the same form instead of 
having to be done using the second form?


On 02/24/2014 12:36 PM, Christian Carlow wrote:
Another related issue is how to determine the particula

Re: How to track manufacturing rejects by employee based on inspection production run task rejections? Add TimeEntryAssoc entity?

[Christian Carlow]

Will do Jacques.  It should be handled OFBIZ-5548 and dependencies.  I'm 
almost done implementing the company-specific code after which I will 
upload the patches.


On 03/04/2014 04:24 PM, Jacques Le Roux wrote:

Will you share your effort on this in a Jira?

Jacques

Le 28/02/2014 23:32, Christian Carlow a écrit :
I've made more progress on this issue but it seems another entity 
might be needed to support the intended functionality.  In a previous 
post I suggested adding the timeEntryId field to the 
InventoryItemDetail entity to track by-products created by production 
run task time entries.  I need a way to determine how many 
by-products have actually been created by a task time entry and 
InventoryItemDetail.quantityOnHandDiff isn't sufficient because it 
doesn't account for possible InventoryItem corrections. Therefore an 
entity such as TimeEntryInventoryProduced will probably have to be 
created similar to WorkEffortInventoryProduced.


On 02/27/2014 10:39 AM, Christian Carlow wrote:
I'm now aware of more complexity. The inspector supervisor explained 
that partial inspections sometimes occur for which parts are moved 
from a manufacturing dept to an inspection dept that performs 
partial inspection and then sends to another manufacturing dept that 
ends up sending the parts to a final inspection dept for full 
inspection.  But if rejects are declared at the final full 
inspection stage, then the fault is supposed to be applied to the 
initially manufacturing worker not the intermediate one that 
performs the work after partial inspection.


I think the TimeEntryAssoc should be extended to handle inspection 
associations to both the prior manufacturing stage from which the 
pieces were sent and the manufacturing stage considered at fault for 
the rejects.  Associations between the inspection stage to the prior 
manufacturing stage is necessary for the inspection dept to 
determine how many pieces are left to inspect.


I think some field like timeEntryAssocTypeId could be used to 
distinguish associations of inspection time entries to the prior 
manufacturing stage from those to the faulty manufacturing stage.  
TIME_ENTRY_DEPENDENCY could be used to associate the inspection task 
to the prior manufacturing task and something like TIME_ENTRY_REJECT 
(with parent TIME_ENTRY_DEPENDENCY) could be used to indicate the 
faulty manufacturing task.


This would possibly entail a new TimeEntryAssocType entity.

On 02/27/2014 09:06 AM, Christian Carlow wrote:
I suppose the TimeEntryAssoc entity could be extended to include 
quantityRejected and responsiblePartyId fields to eliminate the 
need for a separate TimeEntryRejectParty entity.


On 02/27/2014 08:53 AM, Christian Carlow wrote:
After making some progress on this issue by adding the 
timesheet/timeentry functionality to the production run task 
declaration services, I've encountered more difficulties 
implementing the needed functionality.  I added a TimeEntryAssoc 
entity so that inspectors can directly inspect a manufacturing 
workers prior time entry. I was going to use the TimeEntryAssoc 
entity to determine the number of bad pieces per manufacturing 
worker by looking at the inspection timeEntry quantityRejected and 
extracting the related manufacturing time entry partyId.  The 
problem with this is that sometimes rejected quantity on the 
inspection ticket might represent faults on the inspectors part 
rather than the manufacturers such as if the inspector drops 
parts.  For this case the inspector should be considered the one 
who caused the bad piece not the manufacturer.


To determine the party at fault for rejected pieces it seems there 
needs to be another entity created to track the info. Maybe 
something like TimeEntryRejectParty that divides the time entry 
rejected quantity and applies them to the parties actually 
responsible for the rejects.


The only alternative I've come up with other than adding a new 
TimeEntryRejectParty is to assign the faulty partyId to the 
inventoryItemDetail record that would be created for the 
by-products declared to account for the rejects. But this method 
is dependent on by-products always being declared when rejects 
occur which might not always happen.  Therefore it seems creating 
a dedicated entity like TimeEntryRejectParty is the better method.


Anyone have any thoughts on this issue?

On 02/24/2014 01:37 PM, Christian Carlow wrote:
My last post can be disregarded, splitting the production run 
declaration into two different forms seems correct.  There needs 
to be a way to relate time entries created from the first form to 
inventory item details created in the second form so that the 
types of rejects that were produced from time entries can be 
determined.


On 02/24/2014 01:05 PM, Christian Carlow wrote:
Is there a reason the two Production Run Declaration 
(manufacturing/control/ProductionRunDeclaration) forms cannot be 
combined into a single form?  If the first form is used to 
declar