How to track manufacturing rejects by employee?

[Christian Carlow-OFBizzer]

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.

[Christian Carlow-OFBizzer]

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 <https://issues.apache.org/jira/browse/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.

[Christian Carlow-OFBizzer]

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
> <https://issues.apache.org/jira/browse/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.
>

[Christian Carlow-OFBizzer]

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
>> <https://issues.apache.org/jira/browse/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.
>>
>

[Christian Carlow-OFBizzer]

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
>>> <https://issues.apache.org/jira/browse/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.
>>>
>>
>

[Christian Carlow-OFBizzer]

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
>>>> <https://issues.apache.org/jira/browse/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.
>>>>
>>>
>>
>

[Christian Carlow-OFBizzer]

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
>>>>> <https://issues.apache.org/jira/browse/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.
>>>>>
>>>>
>>>
>>
>

[Christian Carlow-OFBizzer]

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 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
>>>>>> <https://issues.apache.org/jira/browse/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.
>>>>>>
>>>>>
>>>>
>>>
>>
>

[Christian Carlow-OFBizzer]

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-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
>>>>>>> <https://issues.apache.org/jira/browse/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.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

[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 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 <https://issues.apache.org/jira/browse/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.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>

[Christian Carlow-OFBizzer]

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
>>>>>>> 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
>>>>>>>>> <https://issues.apache.org/jira/browse/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.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>