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

[Christian Carlow]

Answering my own question, I think adding a separate facilityId field to 
the production run stock in options is unnecessary.  The current method 
where the facilityId is automatically set to the one assigned to the 
production run seems correct.  Inventory transfers seems to be the 
correct way to handle cases where production run stocks are supposed to 
end up in a facility other than the one assigned to the production run.  
It just seems awkward doing it this way because technically the transfer 
occurred during the production run when Edging sent the pieces to Edging 
Inspection for the inspection task.  If this were modeled in the ticket 
system, its as if the inspection dept sent the pieces back to the Edging 
dept just so it could send it back to the Inspection dept.  But I think 
this awkwardness is due to the incorrect data modeling used for the 
ticket system.

On 01/31/2014 02:32 PM, Christian Carlow wrote:
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