Re: Inventory move ticket system for tracking progress of manufactured parts

[Christian Carlow]

The inventory transferring difficulties mentioned in my last post seem 
invalid.  When a production run is started the BOMs are deducted when 
the first task is completed (by default).  Therefore the inventory would 
not exist to be transferred to the inspection dept when that production 
run task is supposed to occur.  So it seems inventory transfers between 
facilities is irrelevant when dealing with production runs.  In other 
words when the edging inspection production run task occurs, an 
inventory transfer of the BOMs from the Edging dept to the Edging 
Inspection dept does not need to occur.

Once the edging inspection production run task completes, the resultant 
product is ready to be stocked in and the inventory needs to be stored 
in the Inspection facility but it is automatically produced in the 
Edging facility because its the one assigned to the production run.  
Does this mean that the inspection dept would have to create an 
inventory transfer from in the Edging facility to their Edging 
Inspection facility or change the facilityId of the inventory item 
produced manually?  Does it make sense to add a facilityId field to the 
stock-in options so that you can choose to stock the resultant product 
in a different facility than the one from which the BOMs were used?

On 01/31/2014 01:49 PM, Christian Carlow wrote:
I think production runs are sufficient for managing all of the 
information currently handled by the companies custom-built ticket 
system.  The difficulty is in remodeling the ticket data as correct 
production run data in OFBiz.

Basically each ticket could be the equivalent of either a production 
run or a task.  For example, a ticket could be created to send parts 
from a dept to an inspection dept which determines if the pieces are 
ready for the next stage of manufacturing (next production run).  If 
I'm understanding the Data Model correctly, production runs are 
created anytime a new product needs to be manufactured from BOMs in 
inventory.  Because an inspection doesn't technically do anything that 
changes the manufacturing state of the product it seems those tickets 
should be created as tasks rather than production runs (routes).  
Other tickets such as parts moving from the Edging dept to the Coating 
Dept would constitute separate production runs because the Coating 
production run requires the Edging WIP to be created from its 
corresponding production run finishing to produce the required BOM to 
create the Coating product linked to its route template.

The ticket system depts also seem to require remodeling.  Separate 
sub-facilities (WAREHOUSEs) were created for each room within the 
building (parent-facility) that may contain inventory.  Some ticket 
represent movements to depts that actually constitute inventory 
transfers to different facilities while other do not. For example, a 
ticket that moves pieces from the Edging dept to the Edging Inspection 
dept would be modeled as production run with two tasks (edging and 
inspection).  But the ticket wouldn't constitute an inventory transfer 
if the edging inspection is done by the same worker who edged because 
it doesn't leave the facility.  If the edging inspection production 
run task is to be performed by an external inspection dept however, 
then it seems an inventory transfer would be necessary.

If this is the correct way to model the data then difficulties lie in 
the cases where production run tasks are supposed be performed by 
different facilities other than the one for which the production run 
was created.  Take the previous example where a ticket is moved from 
Edging to Edging Inspection where the Edging task is performed in 
Edging dept (facility) for which the production run to create the 
edge-manufactured part was created while the Edging Inspection task is 
to be performed by a separate facility.  In this case, when the 
inspection dept completes the final task of the production run, the 
inventory of the resultant Edging manufactured product would go in the 
Edging facility but it seems they need to be stocked in the inspection 
facility since its the dept that actually contains the 
edge-manufactured part that will be converted into its next stage for 
manufacturing.



On 01/15/2014 02:44 PM, Ted Byers wrote:
On Wed, Jan 15, 2014 at 3:15 PM, Christian Carlow <
christian.car...@gmail.com> wrote:

One important part I'll have to work out is how to handle the 
inspection
department mentioned in the previous post.  I think inspections can be
handled as separate production runs just like normal ticket 
movements.  The
main difference between the inspection and manufacturing dept 
tickets is
that inspection dept has the ability to split a manufacturing ticket 
into
different quantities destined for different locations.  I think this 
can be
handled with the WorkEffortAssoc entity.  Inspection users currently 
select
ticketIds from a list to be inspected.  I guess the ticketIds in 
this case
would be served by workEffortId of the previous production run.

This would have to be flexible, as different manufacturers will have
different protocols.  My father worked all his life in quality control,
just down the hall from the engineer's labs responsible for designing 
new
products.  For any given product, there were sometimes multiple 
protocols,
all of which would be used for a given assembly line.  Each would be 
used
on a random sample of the products coming off the line, and in some of
their facilities, there'd be an extra protocol applied to every unit 
coming
off the line.  One protocol involved something like function or 
integration
tests.  Depending on the facility, and how paranoid about quality the
facility's manger was, this would either be applied to a large random
sample, or to all, of the units coming off the line.  A second, 
including
tests of each component in the unit in addition to the tests in the 
first
protocol, would be applied to a much smaller, but independent, random
sample.  Please note, a sample generally had a minimum size of 100 
units.
In the most recent configuration of that company's QA infrastructure, 
the
assembly lines was not started for a batch of less than 100,000 
units, and
they actually had a computer on the end of the assembly line which
performed all the required tests.  That is to say, every unit coming off
those assembly lines was subjected to at least one suite of tests.  And
there were other protocols also, but I was too young at the time to
remember much else.  But I do know my father would say that the QA 
testing
was not a separate process from the manufacturing process, but an 
integral
part of it.  On the other hand, my brother worked in a company that had
it's own machine shop, and that shop would have to gear up to make a 
single
unit (which of course would be tested thoroughly), because it was 
needed to
permit another department in the same company repair an insanely 
expensive
piece of equipment, the parts of which had not been made in decades.  
These
techs had the product specs on file, and so, using modern equipment, 
made
'obsolete' parts to spec, so that the supported old pieces of equipment
could have a few extra years of life; and they had to do it to 
perfection
since a failure could cost lives.  I would expect that there would be
seemingly countless variants between these two extremes.

I suppose, the question becomes how best to model QA in such a way 
that it
supports the many varied QA protocols that may be encountered. Is the
production run adequate, or can you derived from it something more 
flexible?

I have not studied the code you're working with, or the books to 
which you
referred, but from the perspective of an end user, in the place of 
either
my father or brother, I would look for something that was flexible 
enough
to support either of the cases I described above.

Let me ask you, do you think what you have in mind is flexible enough to
handle such edge cases, and if so, how?

Cheers

Ted