Inventory move ticket system for tracking progress of manufactured parts

[Christian Carlow]

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]

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/

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]

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?

Post by Anil Patel
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/

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]

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.

Post by Christian Carlow
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?

Post by Anil Patel
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

Post by Christian Carlow
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 <

Post by Christian Carlow
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]

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.

Post by Ted Byers
On Wed, Jan 15, 2014 at 3:15 PM, Christian Carlow <

Post by Christian Carlow
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]

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?

Post by Christian Carlow
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.

Post by Ted Byers
On Wed, Jan 15, 2014 at 3:15 PM, Christian Carlow <

Post by Christian Carlow
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]

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.

Post by 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?

Post by Christian Carlow
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.

Post by Ted Byers
On Wed, Jan 15, 2014 at 3:15 PM, Christian Carlow <

Post by Christian Carlow
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 <

Post by 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.

Post by 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?

Post by Christian Carlow
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.

Post by Ted Byers
On Wed, Jan 15, 2014 at 3:15 PM, Christian Carlow <
One important part I'll have to work out is how to handle the

Post by Christian Carlow
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

Post by 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 <

Post by 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.

Post by 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?

Post by Christian Carlow
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.

Post by Ted Byers
On Wed, Jan 15, 2014 at 3:15 PM, Christian Carlow <
One important part I'll have to work out is how to handle the

Post by Christian Carlow
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]

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?

Post by 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

Post by 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 <

Post by 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.

Post by 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?

Post by Christian Carlow
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.

Post by Ted Byers
On Wed, Jan 15, 2014 at 3:15 PM, Christian Carlow <
One important part I'll have to work out is how to handle the

Post by Christian Carlow
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]

Post by 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.

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,

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

Post by Pierre Smits
But, if your business process(es) regarding the quality inspection of the

Post by Pierre Smits
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