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.
