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.
