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.
