You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Pierre Smits <pi...@gmail.com> on 2014/02/01 17:19:46 UTC
Re: Inventory move ticket system for tracking progress of
manufactured parts
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 <
christian.carlow@gmail.com> 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 <
>>>> christian.carlow@gmail.com> wrote:
>>>>
>>>> One important part I'll have to work out is how to handle the
>>>>> inspection
>>>>> department mentioned in the previous post. I think inspections can be
>>>>> handled as separate production runs just like normal ticket movements.
>>>>> The
>>>>> main difference between the inspection and manufacturing dept tickets
>>>>> is
>>>>> that inspection dept has the ability to split a manufacturing ticket
>>>>> into
>>>>> different quantities destined for different locations. I think this
>>>>> can be
>>>>> handled with the WorkEffortAssoc entity. Inspection users currently
>>>>> select
>>>>> ticketIds from a list to be inspected. I guess the ticketIds in this
>>>>> case
>>>>> would be served by workEffortId of the previous production run.
>>>>>
>>>>> This would have to be flexible, as different manufacturers will have
>>>> different protocols. My father worked all his life in quality control,
>>>> just down the hall from the engineer's labs responsible for designing
>>>> new
>>>> products. For any given product, there were sometimes multiple
>>>> protocols,
>>>> all of which would be used for a given assembly line. Each would be
>>>> used
>>>> on a random sample of the products coming off the line, and in some of
>>>> their facilities, there'd be an extra protocol applied to every unit
>>>> coming
>>>> off the line. One protocol involved something like function or
>>>> integration
>>>> tests. Depending on the facility, and how paranoid about quality the
>>>> facility's manger was, this would either be applied to a large random
>>>> sample, or to all, of the units coming off the line. A second,
>>>> including
>>>> tests of each component in the unit in addition to the tests in the
>>>> first
>>>> protocol, would be applied to a much smaller, but independent, random
>>>> sample. Please note, a sample generally had a minimum size of 100
>>>> units.
>>>> In the most recent configuration of that company's QA infrastructure,
>>>> the
>>>> assembly lines was not started for a batch of less than 100,000 units,
>>>> and
>>>> they actually had a computer on the end of the assembly line which
>>>> performed all the required tests. That is to say, every unit coming off
>>>> those assembly lines was subjected to at least one suite of tests. And
>>>> there were other protocols also, but I was too young at the time to
>>>> remember much else. But I do know my father would say that the QA
>>>> testing
>>>> was not a separate process from the manufacturing process, but an
>>>> integral
>>>> part of it. On the other hand, my brother worked in a company that had
>>>> it's own machine shop, and that shop would have to gear up to make a
>>>> single
>>>> unit (which of course would be tested thoroughly), because it was
>>>> needed to
>>>> permit another department in the same company repair an insanely
>>>> expensive
>>>> piece of equipment, the parts of which had not been made in decades.
>>>> These
>>>> techs had the product specs on file, and so, using modern equipment,
>>>> made
>>>> 'obsolete' parts to spec, so that the supported old pieces of equipment
>>>> could have a few extra years of life; and they had to do it to
>>>> perfection
>>>> since a failure could cost lives. I would expect that there would be
>>>> seemingly countless variants between these two extremes.
>>>>
>>>> I suppose, the question becomes how best to model QA in such a way that
>>>> it
>>>> supports the many varied QA protocols that may be encountered. Is the
>>>> production run adequate, or can you derived from it something more
>>>> flexible?
>>>>
>>>> I have not studied the code you're working with, or the books to which
>>>> you
>>>> referred, but from the perspective of an end user, in the place of
>>>> either
>>>> my father or brother, I would look for something that was flexible
>>>> enough
>>>> to support either of the cases I described above.
>>>>
>>>> Let me ask you, do you think what you have in mind is flexible enough to
>>>> handle such edge cases, and if so, how?
>>>>
>>>> Cheers
>>>>
>>>> Ted
>>>>
>>>>
>>>
>>
>
Re: Inventory move ticket system for tracking progress of
manufactured parts
Posted by Pierre Smits <pi...@gmail.com>.
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 <christian.carlow@gmail.com
> 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?
>
Re: Inventory move ticket system for tracking progress of manufactured
parts
Posted by Christian Carlow <ch...@gmail.com>.
>> 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?
Re: Inventory move ticket system for tracking progress of
manufactured parts
Posted by Pierre Smits <pi...@gmail.com>.
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
Re: Inventory move ticket system for tracking progress of manufactured
parts
Posted by Christian Carlow <ch...@gmail.com>.
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 <pi...@gmail.com> 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 <
>> christian.carlow@gmail.com> 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 <
>>>>>> christian.carlow@gmail.com> wrote:
>>>>>>
>>>>>> One important part I'll have to work out is how to handle the
>>>>>>> inspection
>>>>>>> department mentioned in the previous post. I think inspections can be
>>>>>>> handled as separate production runs just like normal ticket
>>>>>>> movements. The
>>>>>>> main difference between the inspection and manufacturing dept tickets
>>>>>>> is
>>>>>>> that inspection dept has the ability to split a manufacturing ticket
>>>>>>> into
>>>>>>> different quantities destined for different locations. I think this
>>>>>>> can be
>>>>>>> handled with the WorkEffortAssoc entity. Inspection users currently
>>>>>>> select
>>>>>>> ticketIds from a list to be inspected. I guess the ticketIds in this
>>>>>>> case
>>>>>>> would be served by workEffortId of the previous production run.
>>>>>>>
>>>>>>> This would have to be flexible, as different manufacturers will have
>>>>>> different protocols. My father worked all his life in quality control,
>>>>>> just down the hall from the engineer's labs responsible for designing
>>>>>> new
>>>>>> products. For any given product, there were sometimes multiple
>>>>>> protocols,
>>>>>> all of which would be used for a given assembly line. Each would be
>>>>>> used
>>>>>> on a random sample of the products coming off the line, and in some of
>>>>>> their facilities, there'd be an extra protocol applied to every unit
>>>>>> coming
>>>>>> off the line. One protocol involved something like function or
>>>>>> integration
>>>>>> tests. Depending on the facility, and how paranoid about quality the
>>>>>> facility's manger was, this would either be applied to a large random
>>>>>> sample, or to all, of the units coming off the line. A second,
>>>>>> including
>>>>>> tests of each component in the unit in addition to the tests in the
>>>>>> first
>>>>>> protocol, would be applied to a much smaller, but independent, random
>>>>>> sample. Please note, a sample generally had a minimum size of 100
>>>>>> units.
>>>>>> In the most recent configuration of that company's QA infrastructure,
>>>>>> the
>>>>>> assembly lines was not started for a batch of less than 100,000 units,
>>>>>> and
>>>>>> they actually had a computer on the end of the assembly line which
>>>>>> performed all the required tests. That is to say, every unit coming
>>>>>> off
>>>>>> those assembly lines was subjected to at least one suite of tests. And
>>>>>> there were other protocols also, but I was too young at the time to
>>>>>> remember much else. But I do know my father would say that the QA
>>>>>> testing
>>>>>> was not a separate process from the manufacturing process, but an
>>>>>> integral
>>>>>> part of it. On the other hand, my brother worked in a company that had
>>>>>> it's own machine shop, and that shop would have to gear up to make a
>>>>>> single
>>>>>> unit (which of course would be tested thoroughly), because it was
>>>>>> needed to
>>>>>> permit another department in the same company repair an insanely
>>>>>> expensive
>>>>>> piece of equipment, the parts of which had not been made in decades.
>>>>>> These
>>>>>> techs had the product specs on file, and so, using modern equipment,
>>>>>> made
>>>>>> 'obsolete' parts to spec, so that the supported old pieces of equipment
>>>>>> could have a few extra years of life; and they had to do it to
>>>>>> perfection
>>>>>> since a failure could cost lives. I would expect that there would be
>>>>>> seemingly countless variants between these two extremes.
>>>>>>
>>>>>> I suppose, the question becomes how best to model QA in such a way
>>>>>> that it
>>>>>> supports the many varied QA protocols that may be encountered. Is the
>>>>>> production run adequate, or can you derived from it something more
>>>>>> flexible?
>>>>>>
>>>>>> I have not studied the code you're working with, or the books to which
>>>>>> you
>>>>>> referred, but from the perspective of an end user, in the place of
>>>>>> either
>>>>>> my father or brother, I would look for something that was flexible
>>>>>> enough
>>>>>> to support either of the cases I described above.
>>>>>>
>>>>>> Let me ask you, do you think what you have in mind is flexible enough
>>>>>> to
>>>>>> handle such edge cases, and if so, how?
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Ted
>>>>>>
>>>>>>
Re: Inventory move ticket system for tracking progress of
manufactured parts
Posted by Pierre Smits <pi...@gmail.com>.
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 <pi...@gmail.com> 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 <
> christian.carlow@gmail.com> 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 <
>>>>> christian.carlow@gmail.com> wrote:
>>>>>
>>>>> One important part I'll have to work out is how to handle the
>>>>>> inspection
>>>>>> department mentioned in the previous post. I think inspections can be
>>>>>> handled as separate production runs just like normal ticket
>>>>>> movements. The
>>>>>> main difference between the inspection and manufacturing dept tickets
>>>>>> is
>>>>>> that inspection dept has the ability to split a manufacturing ticket
>>>>>> into
>>>>>> different quantities destined for different locations. I think this
>>>>>> can be
>>>>>> handled with the WorkEffortAssoc entity. Inspection users currently
>>>>>> select
>>>>>> ticketIds from a list to be inspected. I guess the ticketIds in this
>>>>>> case
>>>>>> would be served by workEffortId of the previous production run.
>>>>>>
>>>>>> This would have to be flexible, as different manufacturers will have
>>>>> different protocols. My father worked all his life in quality control,
>>>>> just down the hall from the engineer's labs responsible for designing
>>>>> new
>>>>> products. For any given product, there were sometimes multiple
>>>>> protocols,
>>>>> all of which would be used for a given assembly line. Each would be
>>>>> used
>>>>> on a random sample of the products coming off the line, and in some of
>>>>> their facilities, there'd be an extra protocol applied to every unit
>>>>> coming
>>>>> off the line. One protocol involved something like function or
>>>>> integration
>>>>> tests. Depending on the facility, and how paranoid about quality the
>>>>> facility's manger was, this would either be applied to a large random
>>>>> sample, or to all, of the units coming off the line. A second,
>>>>> including
>>>>> tests of each component in the unit in addition to the tests in the
>>>>> first
>>>>> protocol, would be applied to a much smaller, but independent, random
>>>>> sample. Please note, a sample generally had a minimum size of 100
>>>>> units.
>>>>> In the most recent configuration of that company's QA infrastructure,
>>>>> the
>>>>> assembly lines was not started for a batch of less than 100,000 units,
>>>>> and
>>>>> they actually had a computer on the end of the assembly line which
>>>>> performed all the required tests. That is to say, every unit coming
>>>>> off
>>>>> those assembly lines was subjected to at least one suite of tests. And
>>>>> there were other protocols also, but I was too young at the time to
>>>>> remember much else. But I do know my father would say that the QA
>>>>> testing
>>>>> was not a separate process from the manufacturing process, but an
>>>>> integral
>>>>> part of it. On the other hand, my brother worked in a company that had
>>>>> it's own machine shop, and that shop would have to gear up to make a
>>>>> single
>>>>> unit (which of course would be tested thoroughly), because it was
>>>>> needed to
>>>>> permit another department in the same company repair an insanely
>>>>> expensive
>>>>> piece of equipment, the parts of which had not been made in decades.
>>>>> These
>>>>> techs had the product specs on file, and so, using modern equipment,
>>>>> made
>>>>> 'obsolete' parts to spec, so that the supported old pieces of equipment
>>>>> could have a few extra years of life; and they had to do it to
>>>>> perfection
>>>>> since a failure could cost lives. I would expect that there would be
>>>>> seemingly countless variants between these two extremes.
>>>>>
>>>>> I suppose, the question becomes how best to model QA in such a way
>>>>> that it
>>>>> supports the many varied QA protocols that may be encountered. Is the
>>>>> production run adequate, or can you derived from it something more
>>>>> flexible?
>>>>>
>>>>> I have not studied the code you're working with, or the books to which
>>>>> you
>>>>> referred, but from the perspective of an end user, in the place of
>>>>> either
>>>>> my father or brother, I would look for something that was flexible
>>>>> enough
>>>>> to support either of the cases I described above.
>>>>>
>>>>> Let me ask you, do you think what you have in mind is flexible enough
>>>>> to
>>>>> handle such edge cases, and if so, how?
>>>>>
>>>>> Cheers
>>>>>
>>>>> Ted
>>>>>
>>>>>
>>>>
>>>
>>
>