Why production run tasks cannot be changed after confirmation? How to model rework on parts?

[Christian Carlow-OFBizzer]

The Tasks tab of production runs that appears before the production run
is confirmed allows tasks to be added, edited, or removed.  Why is this
functionality lost once confirmed?

I'm trying to correctly model "rework" on parts that do not pass
inspection and require being the preceding manufacturing process to be
performed further.  This could be modeled as the following tasks linked
to a route:

 1. Stock Out - task that deducts BOMs from inventory production run
 2. Manufacturing - task that represents the manufacturing performed on
    the BOMs
 3. Inspection - task that represents inspection by the dept where
    manufacturing was performed
 4. Cleaning/Inpection - task that represents cleaning performed by an
    external dept which is capable of detecting flaws the previous
    inspection dept sometimes cannot

If "rework" were modeled using production run tasks then they would need
allow for changes even after production run confirmation.  For example,
for a production run to produce 2 of a product, the inspection step
performed after manufacturing might reject both pieces.  If the pieces
are deemed capable of rework instead of being considered scrap, the
manufacturing task would need to be performed again.  It seems the
manufacturing task would need to be added to the production run again to
be run after the Inspection step and the Inspection task added again to
be performed after the second manufacturing and before the remaining
Cleaning/Inspection task.

The alternative would to leave the existing functionality preventing
task changes after confirmation and just create a new production run to
account for the pieces rejected.  This seems to be the more correct way
to handle model rework on parts.  Can anyone confirm this?

[Pierre Smits]

Christian,

In essence the basic manufacturing process for producing an end product is
the executing of a happy flow. When registering a new production run of
e.g. 1000 washers it is the intention to register (as output of that
production run) 1000 washers into inventory.

With predefined inputs (components, production resources like machines and
workers) the defined output is generated. This is based on the BoM (the
what) and the associated production schema (the how).

Deviations of the happy flow leads to a diminished quality of the end
product (not only when assessing the end product with regards to its
acceptance parameters, but also when taking the cost of the product into
consideration).
Yes, the average cost of quality inspection and rework can be incorporated
into the standard cost price. But these are based on statistics. The actual
cost of the real inspection and rework on the (intermediate) product of a
production run can deviate enormously from the standard calculation.

With current functionality in the manufacturing component only the happy
flow is addressed, with only a few predefined deviations. These deviations
are also predefined, namely the registration of by and waste products and
rejected end products.

Now, back to your 'rework' scenario. Executing this scenario is hardly a
happy flow. The amount of effort in this is difficult to define up front,
and the output can be vary from scenario to scenario. So this is difficult
to define in a BoM and related production schema. For that you can add
tasks, components and resources to a production before confirmation.

Moreover, given the variance of tasks, components and resources applicable
from rework to rework you could regard it (in a way) as product development
or (re-)engineering. But definitely not manufacturing.

Regards,

Pierre Smits

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

[Pierre Smits]

Christian,

Your problem should be  easy to solve.
Create in the catalog a product for the defective end product, eg
'Defective End Product. Associate that product with the cleaning task as
deliverable product. When the task is executed in the production run for
good end products, declare the defective end products) as by-products. You
will then have your defective end products in inventory. From there on you
can transfer these to the facility that does the rework.

Regards,

Pierre Smits

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

[Christian Carlow-OFBizzer]

Thanks Pierre,

Are the only tasks that should be related to production runs those that
represent work performed by the same facility as the production run?  
The cleaning/inspection tasks is actually performed by a dept/facility
external to the one that performed manufacturing.  But when the
cleaning/inspection task is complete, the pieces can only be stocked in
at the facility associated with the production run which is the
manufacturing facility where the BOMs were derived.  It seems to get the
finished pieces into the cleaning/inspection facility, an Inventory
Transfer would have to occur.  This is fine but it seems not to reflect
what actually happened.  In other words, cleaning/inspection was not
performed in the manufacturing facility and then transferred to the
cleaning/inspection dept.  Instead the transfer took place after the
initial inspection task was complete. Therefore it seems the pieces
should technically be considered in the cleaning/inspection facility not
the manufacturing facility.

I'm still not entirely sure how the inspections should be modeled. As
production runs themselves or tasks that share a production run with
prior manufacturing tasks.

[Pierre Smits]

Christian,

You can bring any task into a production run planned to be executed in any
facility. The facility is set when you register the production run. If the
associated facility does not hold the components in stock then you need to
transfer the quantity needed to that facility.

You seem to be focused on executing the cleaning/inspection in a production
run associated to one facility but have the task executed in another
facility. This is currently not an ootb functionality/feature.

You have multiple options here. One is to do as I decribed earlier. Another
is to design your solution needed and implement it in your environment. And
there are more.

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 Sun, Feb 2, 2014 at 5:08 PM, Christian Carlow <[hidden email]
> wrote:

> Thanks Pierre,
>
> Are the only tasks that should be related to production runs those that
> represent work performed by the same facility as the production run?  The
> cleaning/inspection tasks is actually performed by a dept/facility external
> to the one that performed manufacturing.  But when the cleaning/inspection
> task is complete, the pieces can only be stocked in at the facility
> associated with the production run which is the manufacturing facility
> where the BOMs were derived.  It seems to get the finished pieces into the
> cleaning/inspection facility, an Inventory Transfer would have to occur.
>  This is fine but it seems not to reflect what actually happened.  In other
> words, cleaning/inspection was not performed in the manufacturing facility
> and then transferred to the cleaning/inspection dept.  Instead the transfer
> took place after the initial inspection task was complete. Therefore it
> seems the pieces should technically be considered in the
> cleaning/inspection facility not the manufacturing facility.
>
> I'm still not entirely sure how the inspections should be modeled. As
> production runs themselves or tasks that share a production run with prior
> manufacturing tasks.
>