Inventory move ticket system for tracking progress of manufactured parts

[Christian Carlow-OFBizzer]

The company manufactures raw pieces of glass into high precision lenses
according to specification drawing and currently uses what it calls a
"Ticket System" to track the manufacturing stage of the glass its
manufacturing.  Each ticket has a productId, deptFrom, deptTo,
operatorId, and ticketDate.  There is also the ability for a ticket to
be inspected either by the initial operator or one within the inspection
department.  There is also a reason code for the move as well as a
comments field.  The company generates a Work-In-Process report that
lists the number of pieces for each product row for each dept column.

Workers are able to determine the manufacturing progress of parts based
on the dept they are located.

The company also generated "Percentage Good" reports based on the
tickets for each employee (operator of the ticket).  When a part is to
be scrapped the operator moves it to a scrap location with a reason code
that indicates its scrap which is used to determine how many bad pieces
were caused by an operator.

Anyone have any ideas about getting OFBiz to support this system?

[Anil Patel-3]

Sounds like your requirements can be best served by Ofbiz Manufacturing application. You may reference “Getting Started with Apache OFBiz Manufacturing and MRP” by Sharan Foga. It will get you started.


Thanks and Regards
Anil Patel
Hotwax Media Inc
http://www.hotwaxmedia.com/
ApacheCon US 2013 Gold Sponsor
http://na.apachecon.com/sponsors/



On Jan 15, 2014, at 9:21 AM, Christian Carlow <[hidden email]> wrote:

> The company manufactures raw pieces of glass into high precision lenses according to specification drawing and currently uses what it calls a "Ticket System" to track the manufacturing stage of the glass its manufacturing.  Each ticket has a productId, deptFrom, deptTo, operatorId, and ticketDate.  There is also the ability for a ticket to be inspected either by the initial operator or one within the inspection department.  There is also a reason code for the move as well as a comments field.  The company generates a Work-In-Process report that lists the number of pieces for each product row for each dept column.
>
> Workers are able to determine the manufacturing progress of parts based on the dept they are located.
>
> The company also generated "Percentage Good" reports based on the tickets for each employee (operator of the ticket).  When a part is to be scrapped the operator moves it to a scrap location with a reason code that indicates its scrap which is used to determine how many bad pieces were caused by an operator.
>
> Anyone have any ideas about getting OFBiz to support this system?
>

[Christian Carlow-OFBizzer]

Thanks Anil,

I looked over the book again and think I grasp the concept of how the
manufacturing app is supposed to work.  In the existing ERP, employees
are somewhat creating production runs and facility/location inventory
transfers/stock moves at the same time when they are creating tickets.  
When an employee creates a ticket to move a part to a different dept,
technically they could be considered to be creating a new WIP from the
previous WIP which could be considered a production run in OFBiz.  
However, the company ticket system resembles the facility inventory
transfer and location stock moves applications much more than the
production run app.  In other cases, such as when the assembly dept
creates a ticket, a product is created from components which is clearly
a production run.

Another part of the ticket system is the inspection functionality.  All
tickets are inspected before moving on to their next location and are
actually sent to inspection depts before moving on to their next
manufacturing dept.  Three inspection depts are considered to be in the
same dept as the one that manufactured the part and in these cases the
same employee is the manufacturer and inspector of the ticket.  One
inspection dept is external from the manufacturing dept and so the
inspectors are different from the manufacturing employees.  The
inspection depts are never considered to be creating new tickets but
inspecting existing ones to approve them to move to their next intended
manufacturing dept.

Ultimately the company just needs to be able to generate a report that
indicates how much of each product row is in each dept column.  If I
were to use the WIP method then having something like a dept identifier
field in the product entity might be necessary in order for the company
WIP dept inventory/manufacuring stage report to be generated correctly.

The only alternative to using the WIP method I can think of is storing
facilities as depts or locations and using the inventory transfer or
stock moves app to track how many pieces of products are stored in
depts.  Because of the assembly dept (and other stages requiring
production runs), the company is going to require production runs
regardless of whether the use the WIP method or not.  Because of this,
it seems that depts would need to be stored as facilities because a
facilityId must be specified when production runs are created, which I
assume is from where the raw materials to produce the finished good are
supposed to be used, and a production run might mistakenly take the
materials from the wrong dept if they are stored as locations.

Storing depts as facilities seems to have its own set of problems
dealing with inventory.  If depts were stored as facilities then I guess
they would be stored as children of the parent facility containing them?
Does OFBiz know how to calculate inventory of parent facilities based on
child facilities?

The WIP progress method seems like the easiest and best way to replace
the existing functionality.

Anyone agree with WIP method or have other ideas?


On 01/15/2014 10:39 AM, Anil Patel wrote:

> Sounds like your requirements can be best served by Ofbiz Manufacturing application. You may reference “Getting Started with Apache OFBiz Manufacturing and MRP” by Sharan Foga. It will get you started.
>
>
> Thanks and Regards
> Anil Patel
> Hotwax Media Inc
> http://www.hotwaxmedia.com/
> ApacheCon US 2013 Gold Sponsor
> http://na.apachecon.com/sponsors/
>
>
>
> On Jan 15, 2014, at 9:21 AM, Christian Carlow <[hidden email]> wrote:
>
>> The company manufactures raw pieces of glass into high precision lenses according to specification drawing and currently uses what it calls a "Ticket System" to track the manufacturing stage of the glass its manufacturing.  Each ticket has a productId, deptFrom, deptTo, operatorId, and ticketDate.  There is also the ability for a ticket to be inspected either by the initial operator or one within the inspection department.  There is also a reason code for the move as well as a comments field.  The company generates a Work-In-Process report that lists the number of pieces for each product row for each dept column.
>>
>> Workers are able to determine the manufacturing progress of parts based on the dept they are located.
>>
>> The company also generated "Percentage Good" reports based on the tickets for each employee (operator of the ticket).  When a part is to be scrapped the operator moves it to a scrap location with a reason code that indicates its scrap which is used to determine how many bad pieces were caused by an operator.
>>
>> Anyone have any ideas about getting OFBiz to support this system?
>>

[Christian Carlow-OFBizzer]

Unless someone suggests otherwise, I'm going with the WIP method.  Every
inventory move ticket in the company's existing ERP will be handled by a
production run.  I'm probably going to design a custom UI that looks the
same to the users but behaves differently in the background by
automatically creating manufacturing data necessary to account for the
move. The custom UI will probably include a DeptTo field that will be
used to automatically create new WIP considered to be in the
manufacturing stage of the dept chosen.  Then the newly created WIP
product will be used to automatically create parent BOM a relationship
to the previous WIP.  I suppose Routings and Routing Tasks would also
need to be automatically created using the auto-created WIPs.

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.

On 01/15/2014 12:31 PM, Christian Carlow wrote:

> Thanks Anil,
>
> I looked over the book again and think I grasp the concept of how the
> manufacturing app is supposed to work.  In the existing ERP, employees
> are somewhat creating production runs and facility/location inventory
> transfers/stock moves at the same time when they are creating
> tickets.  When an employee creates a ticket to move a part to a
> different dept, technically they could be considered to be creating a
> new WIP from the previous WIP which could be considered a production
> run in OFBiz.  However, the company ticket system resembles the
> facility inventory transfer and location stock moves applications much
> more than the production run app.  In other cases, such as when the
> assembly dept creates a ticket, a product is created from components
> which is clearly a production run.
>
> Another part of the ticket system is the inspection functionality.  
> All tickets are inspected before moving on to their next location and
> are actually sent to inspection depts before moving on to their next
> manufacturing dept.  Three inspection depts are considered to be in
> the same dept as the one that manufactured the part and in these cases
> the same employee is the manufacturer and inspector of the ticket.  
> One inspection dept is external from the manufacturing dept and so the
> inspectors are different from the manufacturing employees.  The
> inspection depts are never considered to be creating new tickets but
> inspecting existing ones to approve them to move to their next
> intended manufacturing dept.
>
> Ultimately the company just needs to be able to generate a report that
> indicates how much of each product row is in each dept column.  If I
> were to use the WIP method then having something like a dept
> identifier field in the product entity might be necessary in order for
> the company WIP dept inventory/manufacuring stage report to be
> generated correctly.
>
> The only alternative to using the WIP method I can think of is storing
> facilities as depts or locations and using the inventory transfer or
> stock moves app to track how many pieces of products are stored in
> depts.  Because of the assembly dept (and other stages requiring
> production runs), the company is going to require production runs
> regardless of whether the use the WIP method or not.  Because of this,
> it seems that depts would need to be stored as facilities because a
> facilityId must be specified when production runs are created, which I
> assume is from where the raw materials to produce the finished good
> are supposed to be used, and a production run might mistakenly take
> the materials from the wrong dept if they are stored as locations.
>
> Storing depts as facilities seems to have its own set of problems
> dealing with inventory.  If depts were stored as facilities then I
> guess they would be stored as children of the parent facility
> containing them? Does OFBiz know how to calculate inventory of parent
> facilities based on child facilities?
>
> The WIP progress method seems like the easiest and best way to replace
> the existing functionality.
>
> Anyone agree with WIP method or have other ideas?
>
>
> On 01/15/2014 10:39 AM, Anil Patel wrote:
>> Sounds like your requirements can be best served by Ofbiz
>> Manufacturing application. You may reference “Getting Started with
>> Apache OFBiz Manufacturing and MRP” by Sharan Foga. It will get you
>> started.
>>
>>
>> Thanks and Regards
>> Anil Patel
>> Hotwax Media Inc
>> http://www.hotwaxmedia.com/
>> ApacheCon US 2013 Gold Sponsor
>> http://na.apachecon.com/sponsors/
>>
>>
>>
>> On Jan 15, 2014, at 9:21 AM, Christian Carlow
>> <[hidden email]> wrote:
>>
>>> The company manufactures raw pieces of glass into high precision
>>> lenses according to specification drawing and currently uses what it
>>> calls a "Ticket System" to track the manufacturing stage of the
>>> glass its manufacturing. Each ticket has a productId, deptFrom,
>>> deptTo, operatorId, and ticketDate.  There is also the ability for a
>>> ticket to be inspected either by the initial operator or one within
>>> the inspection department.  There is also a reason code for the move
>>> as well as a comments field.  The company generates a
>>> Work-In-Process report that lists the number of pieces for each
>>> product row for each dept column.
>>>
>>> Workers are able to determine the manufacturing progress of parts
>>> based on the dept they are located.
>>>
>>> The company also generated "Percentage Good" reports based on the
>>> tickets for each employee (operator of the ticket).  When a part is
>>> to be scrapped the operator moves it to a scrap location with a
>>> reason code that indicates its scrap which is used to determine how
>>> many bad pieces were caused by an operator.
>>>
>>> Anyone have any ideas about getting OFBiz to support this system?
>>>
>

[Ted Byers]

On Wed, Jan 15, 2014 at 3:15 PM, Christian Carlow <
[hidden email]> 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

[Christian Carlow-OFBizzer]

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 <
> [hidden email]> 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
>

[Christian Carlow-OFBizzer]

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 <
>> [hidden email]> 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
>>
>

[Christian Carlow-OFBizzer]

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 <
>>> [hidden email]> 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
>>>
>>
>

[Pierre Smits]

Christian,

Reading through the mails in this thread I will try to address your issues.

First, a production run can include tasks for quality inspection. When
done, the standard cost of the inspection is incorporated in the cost price
of the product to be manufactured.

However, including such a task does not define the sub process the quality
inspection department has to execute. It will merely tell the production
manager (when such sub process has been defined properly) what to do with
the conclusions of that department regarding the production run (meaning,
everything is ok, everything is wrong, only parts are wrong). The
production manager can subsequently set the correct output of the
production run and the defects.

Secondly, if there is indeed a strong need to have this quality inspection
process in manufacturing and it has multiple tasks to be performed, it can
be solved with ootb functions in the manufacturing process.

Regards,


Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Fri, Jan 31, 2014 at 10:10 PM, Christian Carlow <
[hidden email]> wrote:

> 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 <
>>>> [hidden email]> 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
>>>>
>>>>
>>>
>>
>

[Pierre Smits]

But, if your business process(es) regarding the quality inspection of the
products have the requirement that forms need to be filled out that are
specific to that process and need to be done by other persons than those in
the manufacturing process then you will need something else than just the
functionalities in the manufacturing component.

Maybe you are not aware of this, but underneath the manufacturing
functionalities (and supporting those) are services and entities from the
workeffort component. Maybe you should look at that component as well to
figure out how your challenge should be solved.

Regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Sat, Feb 1, 2014 at 5:19 PM, Pierre Smits <[hidden email]> wrote:

> Christian,
>
> Reading through the mails in this thread I will try to address your issues.
>
> First, a production run can include tasks for quality inspection. When
> done, the standard cost of the inspection is incorporated in the cost price
> of the product to be manufactured.
>
> However, including such a task does not define the sub process the quality
> inspection department has to execute. It will merely tell the production
> manager (when such sub process has been defined properly) what to do with
> the conclusions of that department regarding the production run (meaning,
> everything is ok, everything is wrong, only parts are wrong). The
> production manager can subsequently set the correct output of the
> production run and the defects.
>
> Secondly, if there is indeed a strong need to have this quality inspection
> process in manufacturing and it has multiple tasks to be performed, it can
> be solved with ootb functions in the manufacturing process.
>
> Regards,
>
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
>
> On Fri, Jan 31, 2014 at 10:10 PM, Christian Carlow <
> [hidden email]> wrote:
>
>> 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 <
>>>>> [hidden email]> 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
>>>>>
>>>>>
>>>>
>>>
>>
>

[Christian Carlow-OFBizzer]

Thanks Pierre,

I've been examining the WorkEffort entity its sufficient for handling
any of the gaps in the Manufacturing app.

Currently I'm having trouble wrapping my head around how production run
task declarations are supposed to work.  I created a production run to
produce 2 of a product from a route containing 3 routing tasks:

 1. DEFAULT_TASK -  used to stock out the BOMs and represent the
    manufacturing work performed
 2. Inspection - performed in the same dept as manufacturing
 3. Cleaning/Inspection - performed by a dept other than the one where
    manufacturing was performed (capable of detecting flaws the previous
    inspection could not while cleaning to prepare for the next
    manufacturing stage)

I issued components and completed the first task.  Then I started the
second task and declared 1 reject and completed. Before completing, task
2 (Inspection) indicated a producted quantity of 0.  Upon completion,
the quantity produced was changed to 1 (2 from DEFAULT_TASK - 1
reject).  Then I started the third task and declared 1 reject and
completed.  Before completing the third task, the producted quantity
indicated 0 (1 non-reject from task2 - 1 reject) but upon completion the
produced quantity = 1.  Also, the rejected quantity remains 0 after all
tasks are completed.

Shouldn't the rejected quantity be 2 and quantity produced be 0 for the
last task?  Am I misunderstanding something or is this a bug?

On 02/01/2014 02:10 PM, Pierre Smits wrote:

> But, if your business process(es) regarding the quality inspection of the
> products have the requirement that forms need to be filled out that are
> specific to that process and need to be done by other persons than those in
> the manufacturing process then you will need something else than just the
> functionalities in the manufacturing component.
>
> Maybe you are not aware of this, but underneath the manufacturing
> functionalities (and supporting those) are services and entities from the
> workeffort component. Maybe you should look at that component as well to
> figure out how your challenge should be solved.
>
> Regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
>
> On Sat, Feb 1, 2014 at 5:19 PM, Pierre Smits <[hidden email]> wrote:
>
>> Christian,
>>
>> Reading through the mails in this thread I will try to address your issues.
>>
>> First, a production run can include tasks for quality inspection. When
>> done, the standard cost of the inspection is incorporated in the cost price
>> of the product to be manufactured.
>>
>> However, including such a task does not define the sub process the quality
>> inspection department has to execute. It will merely tell the production
>> manager (when such sub process has been defined properly) what to do with
>> the conclusions of that department regarding the production run (meaning,
>> everything is ok, everything is wrong, only parts are wrong). The
>> production manager can subsequently set the correct output of the
>> production run and the defects.
>>
>> Secondly, if there is indeed a strong need to have this quality inspection
>> process in manufacturing and it has multiple tasks to be performed, it can
>> be solved with ootb functions in the manufacturing process.
>>
>> Regards,
>>
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>>
>> On Fri, Jan 31, 2014 at 10:10 PM, Christian Carlow <
>> [hidden email]> wrote:
>>
>>> 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 <
>>>>>> [hidden email]> 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
>>>>>>
>>>>>>

[Christian Carlow-OFBizzer]

>> But, if your business process(es) regarding the quality inspection of the
>> products have the requirement that forms need to be filled out that are
>> specific to that process and need to be done by other persons than those in
>> the manufacturing process then you will need something else than just the
>> functionalities in the manufacturing component.
>>
The inspection tasks do require forms to be filled out and I'm trying to
determine how this should be handled.  Aren't "Deliverable Products" of
Routing Tasks supposed to link to forms, documents, etc?

[Pierre Smits]

Christian,

You are correct. When registering production rejection on a task it should
be reflected on the production header and on subsequent tasks. In your
scenario it should result in total rejected products 2 vs total
manufactured products 0.

This should also be reflected on the overview of tasks.

With such a registered output the production run should be able to be
completed and closed. But it can't. I will register a bug for it in JIRA.

Regards.

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[Pierre Smits]

Christian,

The 'deliverable products' associated to a routing task are intended to be
able to register by-products on a production run, leading to inventory
change.

Follow this example:
Suppose there is the production schema for manufacturing metal washers of
1mm thick from a bar of steel. The production schema consists of only 1
task, cutting steel bar. The bom has only 1 component per 1mm thick washer,
namely 1.2mm of steel (coming from the bar of steel).

Now when executing the production run of 1 washer, your input will be 1.2mm
of steel (leading to the cost of production) and output is 1 washer
(costing 1.2mm of steel + cutting cost).

If that would be all, you would be done. But there is also the by-product,
namely the steel cutting residue. This you can't set as output of the
production run, as you can only define 1 end product. You can define
manually it on a running task as output, but if you know that there will a
by-product you better have registered on a predefined task so it won't be
forgotten when the production is executed.

Regards,


Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Sat, Feb 1, 2014 at 9:44 PM, Christian Carlow <[hidden email]
> wrote:

>
>  But, if your business process(es) regarding the quality inspection of the
>>> products have the requirement that forms need to be filled out that are
>>> specific to that process and need to be done by other persons than those
>>> in
>>> the manufacturing process then you will need something else than just the
>>> functionalities in the manufacturing component.
>>>
>>>  The inspection tasks do require forms to be filled out and I'm trying
> to determine how this should be handled.  Aren't "Deliverable Products" of
> Routing Tasks supposed to link to forms, documents, etc?
>