Virtual Product Production Run

[Scott Gray]

Hi All

I need to create a virtual product production run, where if the routings
are associated with the virtual product then the variants can be
combined into a single run.  This is pretty standard for the apparel
industry where all the colours and sizes are produced together.

I was wondering if anyone thinks this might harm the way they do things
in different scenarios or if anyone thinks it's just a plain bad idea
for inclusion in the svn code.  Any input would be appreciated.

Thanks
Scott

[Jacopo Cappellato]

Hi Scott,

thanks for the interesting post.

My guess is that you need something like this for planning/scheduling
purposes.
For example, let's say that your forecast is to sell 10000 t-shirt of
type "A" in the next 2 months; the t-shirt "A" are virtual product that
are available in two sizes, S and L.
The materials needed to manufacture one t-shirt of size S is mostly the
same of the materials needed to manufacture one t-shirt of type L.
You would like to simulate (materials and resources needed) the
manufacturing process to create 10000 t-shirt of type "A", regardless of
their sizes.
I agree that creating a 'virtual' production run is a big temptation in
this situations; however I really advice against this approach: we have
seen many times this approach implemented by customers in the past but
at the end it causes a lot of problems... for example, the MRP
simulations can be messed up by this approach.

I'd recommend to implement something different:

1) introduce the concept of a "family of products"; this could be a
special type of Product that is only used as a planning tool; in the
example above, you could create a new product of type "family of
products" to represent your type "A" t-shirts

2) create a bom for your family of products where each component is a
variant product; for example: family "A" has two components, the variant
product "t-shirt A size S" and "t-shirt A size L"; the bom coefficient
is used here to forecast the number of sizes that will be sold (for
example, 0.4 for S and 0.6 for L)

3) then you'll create one production run for the family "A" of 10000
units with start date in the future; the production run will never be
executed (i.e. its components, the variant products, will not be taken
from warehouse)

4) by running the MRP you'll get a simulation of the materials needed
(to manufacture 4000 t-shirt of size S and 6000 t-shirt of size L) and
it will generate the *requirements* for them (that once approved will
become new production runs for real variant products).

Does it make sense?

Jacopo


Scott Gray wrote:

> Hi All
>
> I need to create a virtual product production run, where if the routings
> are associated with the virtual product then the variants can be
> combined into a single run.  This is pretty standard for the apparel
> industry where all the colours and sizes are produced together.
>
> I was wondering if anyone thinks this might harm the way they do things
> in different scenarios or if anyone thinks it's just a plain bad idea
> for inclusion in the svn code.  Any input would be appreciated.
>
> Thanks
> Scott

[Scott Gray]

Hi Jacopo

Thanks for your comments, I like the idea of what you've suggested for
production planning.  However what I need is garments that are actually
physically made together, I'll use your example of the T-Shirt to illustrate
what i mean:

There are 3 basic routing tasks for making a garment -
1. Cutting - the patterns for both sizes are marked on to a template, the
template is then layed on to say 50 layers of fabric in order to cut 50
t-shirts, cutting the sizes together saves on set up times and also raw
material usage.

2. Making - once the garments are cut they all require the same sewing
regardless of size. Side seams, neck binding, hemming etc., is always more
efficient if you do them all in one go, you would never completely make size
S and then get started on size L.

3.  Finishing - once again all items are processed together.

Perhaps not suitable for svn?  Another process that comes to mind is getting
garments embroidered with logo's where 10 different products might have the
same process performed in one run.

Regards
Scott


On 23/08/06, Jacopo Cappellato <[hidden email]> wrote:

>
> Hi Scott,
>
> thanks for the interesting post.
>
> My guess is that you need something like this for planning/scheduling
> purposes.
> For example, let's say that your forecast is to sell 10000 t-shirt of
> type "A" in the next 2 months; the t-shirt "A" are virtual product that
> are available in two sizes, S and L.
> The materials needed to manufacture one t-shirt of size S is mostly the
> same of the materials needed to manufacture one t-shirt of type L.
> You would like to simulate (materials and resources needed) the
> manufacturing process to create 10000 t-shirt of type "A", regardless of
> their sizes.
> I agree that creating a 'virtual' production run is a big temptation in
> this situations; however I really advice against this approach: we have
> seen many times this approach implemented by customers in the past but
> at the end it causes a lot of problems... for example, the MRP
> simulations can be messed up by this approach.
>
> I'd recommend to implement something different:
>
> 1) introduce the concept of a "family of products"; this could be a
> special type of Product that is only used as a planning tool; in the
> example above, you could create a new product of type "family of
> products" to represent your type "A" t-shirts
>
> 2) create a bom for your family of products where each component is a
> variant product; for example: family "A" has two components, the variant
> product "t-shirt A size S" and "t-shirt A size L"; the bom coefficient
> is used here to forecast the number of sizes that will be sold (for
> example, 0.4 for S and 0.6 for L)
>
> 3) then you'll create one production run for the family "A" of 10000
> units with start date in the future; the production run will never be
> executed (i.e. its components, the variant products, will not be taken
> from warehouse)
>
> 4) by running the MRP you'll get a simulation of the materials needed
> (to manufacture 4000 t-shirt of size S and 6000 t-shirt of size L) and
> it will generate the *requirements* for them (that once approved will
> become new production runs for real variant products).
>
> Does it make sense?
>
> Jacopo
>
>
> Scott Gray wrote:
> > Hi All
> >
> > I need to create a virtual product production run, where if the routings
> > are associated with the virtual product then the variants can be
> > combined into a single run.  This is pretty standard for the apparel
> > industry where all the colours and sizes are produced together.
> >
> > I was wondering if anyone thinks this might harm the way they do things
> > in different scenarios or if anyone thinks it's just a plain bad idea
> > for inclusion in the svn code.  Any input would be appreciated.
> >
> > Thanks
> > Scott
>
>

[Rodrigo Aguinaga]

Hi,

I actually had this problems some time ago when I configured ofbiz for a
clothes and aparel company, the solution that I found was to create products
that are associated in a BOM formula(subassembly products), using the
t-shirt sample.

Virtual Tshit:
  Finish Shirt
  - Not finish shirt
    - front, back neck, sleeves....
      - color garment
        - ink
        - raw garment

So what I did was to create different routes to create some of this
products, like  one to create the color garment, another to create the
front, back, nech, sleeves together so you can work with the garment
template (use the concept of phantom product to associate the products as
one), and the same in the making, and in the finishing. I use a lot the mrp
so you create a wrun for the finished shirt and the mrp creates the proposed
mrp for the other parts

Regards
Rodrigo

2006/8/22, Scott Gray <[hidden email]>:

>
> Hi Jacopo
>
> Thanks for your comments, I like the idea of what you've suggested for
> production planning.  However what I need is garments that are actually
> physically made together, I'll use your example of the T-Shirt to
> illustrate
> what i mean:
>
> There are 3 basic routing tasks for making a garment -
> 1. Cutting - the patterns for both sizes are marked on to a template, the
> template is then layed on to say 50 layers of fabric in order to cut 50
> t-shirts, cutting the sizes together saves on set up times and also raw
> material usage.
>
> 2. Making - once the garments are cut they all require the same sewing
> regardless of size. Side seams, neck binding, hemming etc., is always more
> efficient if you do them all in one go, you would never completely make
> size
> S and then get started on size L.
>
> 3.  Finishing - once again all items are processed together.
>
> Perhaps not suitable for svn?  Another process that comes to mind is
> getting
> garments embroidered with logo's where 10 different products might have
> the
> same process performed in one run.
>
> Regards
> Scott
>
>
> On 23/08/06, Jacopo Cappellato <[hidden email]> wrote:
> >
> > Hi Scott,
> >
> > thanks for the interesting post.
> >
> > My guess is that you need something like this for planning/scheduling
> > purposes.
> > For example, let's say that your forecast is to sell 10000 t-shirt of
> > type "A" in the next 2 months; the t-shirt "A" are virtual product that
> > are available in two sizes, S and L.
> > The materials needed to manufacture one t-shirt of size S is mostly the
> > same of the materials needed to manufacture one t-shirt of type L.
> > You would like to simulate (materials and resources needed) the
> > manufacturing process to create 10000 t-shirt of type "A", regardless of
> > their sizes.
> > I agree that creating a 'virtual' production run is a big temptation in
> > this situations; however I really advice against this approach: we have
> > seen many times this approach implemented by customers in the past but
> > at the end it causes a lot of problems... for example, the MRP
> > simulations can be messed up by this approach.
> >
> > I'd recommend to implement something different:
> >
> > 1) introduce the concept of a "family of products"; this could be a
> > special type of Product that is only used as a planning tool; in the
> > example above, you could create a new product of type "family of
> > products" to represent your type "A" t-shirts
> >
> > 2) create a bom for your family of products where each component is a
> > variant product; for example: family "A" has two components, the variant
> > product "t-shirt A size S" and "t-shirt A size L"; the bom coefficient
> > is used here to forecast the number of sizes that will be sold (for
> > example, 0.4 for S and 0.6 for L)
> >
> > 3) then you'll create one production run for the family "A" of 10000
> > units with start date in the future; the production run will never be
> > executed (i.e. its components, the variant products, will not be taken
> > from warehouse)
> >
> > 4) by running the MRP you'll get a simulation of the materials needed
> > (to manufacture 4000 t-shirt of size S and 6000 t-shirt of size L) and
> > it will generate the *requirements* for them (that once approved will
> > become new production runs for real variant products).
> >
> > Does it make sense?
> >
> > Jacopo
> >
> >
> > Scott Gray wrote:
> > > Hi All
> > >
> > > I need to create a virtual product production run, where if the
> routings
> > > are associated with the virtual product then the variants can be
> > > combined into a single run.  This is pretty standard for the apparel
> > > industry where all the colours and sizes are produced together.
> > >
> > > I was wondering if anyone thinks this might harm the way they do
> things
> > > in different scenarios or if anyone thinks it's just a plain bad idea
> > > for inclusion in the svn code.  Any input would be appreciated.
> > >
> > > Thanks
> > > Scott
> >
> >
>
>

[Jacopo Cappellato]

This is a good way of handling this.

Rodrigo, I'm just curious: did you setup it using Neogia manufacturing
or the standard OFBiz manufacturing component?

Jacopo

Rodrigo Aguinaga wrote:

> Hi,
>
> I actually had this problems some time ago when I configured ofbiz for a
> clothes and aparel company, the solution that I found was to create
> products
> that are associated in a BOM formula(subassembly products), using the
> t-shirt sample.
>
> Virtual Tshit:
>  Finish Shirt
>  - Not finish shirt
>    - front, back neck, sleeves....
>      - color garment
>        - ink
>        - raw garment
>
> So what I did was to create different routes to create some of this
> products, like  one to create the color garment, another to create the
> front, back, nech, sleeves together so you can work with the garment
> template (use the concept of phantom product to associate the products as
> one), and the same in the making, and in the finishing. I use a lot the mrp
> so you create a wrun for the finished shirt and the mrp creates the
> proposed
> mrp for the other parts
>
> Regards
> Rodrigo
>

[Jacopo Cappellato]

Scott,

thanks for the example that is very helpful.
I still think that you should try to keep them as separate production runs.
Why do you really need to create just one production run? In order to
simplify the production run creation? In order to provide a single
document to the workcenters' operators?

In order to make the process more user friendly you could develop
instead a new "create production run" screen (it would be nice to
include it in svn too) that, for example, makes you select the virtual
product and then the units that you want to manufacture for each
variants and then it will automatically create all the production runs
(maybe we could associate all the production runs together using a
naming convention or the WorkEffortAssoc entity or the parentWorkEffortId).
And you could customize the manufacturing documents (pdf) to put
together the information (sorted by task) from all the production runs
of this group.
In my opinion this will allow you to keep low the development costs and
to maintain everything compatible with the existing processes (MRP etc...)

Does it make sense?

Jacopo


Scott Gray wrote:

> Hi Jacopo
>
> Thanks for your comments, I like the idea of what you've suggested for
> production planning.  However what I need is garments that are actually
> physically made together, I'll use your example of the T-Shirt to
> illustrate
> what i mean:
>
> There are 3 basic routing tasks for making a garment -
> 1. Cutting - the patterns for both sizes are marked on to a template, the
> template is then layed on to say 50 layers of fabric in order to cut 50
> t-shirts, cutting the sizes together saves on set up times and also raw
> material usage.
>
> 2. Making - once the garments are cut they all require the same sewing
> regardless of size. Side seams, neck binding, hemming etc., is always more
> efficient if you do them all in one go, you would never completely make
> size
> S and then get started on size L.
>
> 3.  Finishing - once again all items are processed together.
>
> Perhaps not suitable for svn?  Another process that comes to mind is
> getting
> garments embroidered with logo's where 10 different products might have the
> same process performed in one run.
>
> Regards
> Scott
>

[Scott Gray]

Hi Jacopo

I think we're pretty much on the same page now :-), I figured there were
a couple of ways to go about it but a new grouping above the existing
production run does seem like the easiest way to achieve what I'm
after.  I might put together a couple of rough screen shots for
feedback. Many thanks to you and Rodrigo for your input, those tricks
will certainly come in handy later on.

Thanks
Scott

Jacopo Cappellato wrote:

> Scott,
>
> thanks for the example that is very helpful.
> I still think that you should try to keep them as separate production
> runs.
> Why do you really need to create just one production run? In order to
> simplify the production run creation? In order to provide a single
> document to the workcenters' operators?
>
> In order to make the process more user friendly you could develop
> instead a new "create production run" screen (it would be nice to
> include it in svn too) that, for example, makes you select the virtual
> product and then the units that you want to manufacture for each
> variants and then it will automatically create all the production runs
> (maybe we could associate all the production runs together using a
> naming convention or the WorkEffortAssoc entity or the
> parentWorkEffortId).
> And you could customize the manufacturing documents (pdf) to put
> together the information (sorted by task) from all the production runs
> of this group.
> In my opinion this will allow you to keep low the development costs
> and to maintain everything compatible with the existing processes (MRP
> etc...)
>
> Does it make sense?
>
> Jacopo
>
>
> Scott Gray wrote:
>> Hi Jacopo
>>
>> Thanks for your comments, I like the idea of what you've suggested for
>> production planning.  However what I need is garments that are actually
>> physically made together, I'll use your example of the T-Shirt to
>> illustrate
>> what i mean:
>>
>> There are 3 basic routing tasks for making a garment -
>> 1. Cutting - the patterns for both sizes are marked on to a template,
>> the
>> template is then layed on to say 50 layers of fabric in order to cut 50
>> t-shirts, cutting the sizes together saves on set up times and also raw
>> material usage.
>>
>> 2. Making - once the garments are cut they all require the same sewing
>> regardless of size. Side seams, neck binding, hemming etc., is always
>> more
>> efficient if you do them all in one go, you would never completely
>> make size
>> S and then get started on size L.
>>
>> 3.  Finishing - once again all items are processed together.
>>
>> Perhaps not suitable for svn?  Another process that comes to mind is
>> getting
>> garments embroidered with logo's where 10 different products might
>> have the
>> same process performed in one run.
>>
>> Regards
>> Scott
>>
>
>

[Rodrigo Aguinaga]

Hi Jacopo,

Actually I used Neogia manufacturing... I didn't make any software changes
on it, because it had already everything I needed to configure it, but I've
seen that the regular ofbiz, also support everything I need to configure
this as well. Though neogia developed a couple of nice screens that I
haven't seen on ofbiz, but also they didn't had fixed asset support (only
machine) and I think that's necesary on the aparel bussisness.

By away that screen that you talk about it would be a nice asset since
there's the need to create a wrun for each variant product.

Greetings
Rodrigo



2006/8/23, Scott Gray <[hidden email]>:

>
> Hi Jacopo
>
> I think we're pretty much on the same page now :-), I figured there were
> a couple of ways to go about it but a new grouping above the existing
> production run does seem like the easiest way to achieve what I'm
> after.  I might put together a couple of rough screen shots for
> feedback. Many thanks to you and Rodrigo for your input, those tricks
> will certainly come in handy later on.
>
> Thanks
> Scott
>
> Jacopo Cappellato wrote:
> > Scott,
> >
> > thanks for the example that is very helpful.
> > I still think that you should try to keep them as separate production
> > runs.
> > Why do you really need to create just one production run? In order to
> > simplify the production run creation? In order to provide a single
> > document to the workcenters' operators?
> >
> > In order to make the process more user friendly you could develop
> > instead a new "create production run" screen (it would be nice to
> > include it in svn too) that, for example, makes you select the virtual
> > product and then the units that you want to manufacture for each
> > variants and then it will automatically create all the production runs
> > (maybe we could associate all the production runs together using a
> > naming convention or the WorkEffortAssoc entity or the
> > parentWorkEffortId).
> > And you could customize the manufacturing documents (pdf) to put
> > together the information (sorted by task) from all the production runs
> > of this group.
> > In my opinion this will allow you to keep low the development costs
> > and to maintain everything compatible with the existing processes (MRP
> > etc...)
> >
> > Does it make sense?
> >
> > Jacopo
> >
> >
> > Scott Gray wrote:
> >> Hi Jacopo
> >>
> >> Thanks for your comments, I like the idea of what you've suggested for
> >> production planning.  However what I need is garments that are actually
> >> physically made together, I'll use your example of the T-Shirt to
> >> illustrate
> >> what i mean:
> >>
> >> There are 3 basic routing tasks for making a garment -
> >> 1. Cutting - the patterns for both sizes are marked on to a template,
> >> the
> >> template is then layed on to say 50 layers of fabric in order to cut 50
> >> t-shirts, cutting the sizes together saves on set up times and also raw
> >> material usage.
> >>
> >> 2. Making - once the garments are cut they all require the same sewing
> >> regardless of size. Side seams, neck binding, hemming etc., is always
> >> more
> >> efficient if you do them all in one go, you would never completely
> >> make size
> >> S and then get started on size L.
> >>
> >> 3.  Finishing - once again all items are processed together.
> >>
> >> Perhaps not suitable for svn?  Another process that comes to mind is
> >> getting
> >> garments embroidered with logo's where 10 different products might
> >> have the
> >> same process performed in one run.
> >>
> >> Regards
> >> Scott
> >>
> >
> >
>
>

[Scott Gray]

Hi Jacopo

I've been looking through the production run process a bit more and I'm
just not feeling that comfortable with doing a grouping above multiple
production runs, it seems like more of a hack than a solid improvement.  
I'm thinking a better approach would be to just cater in the UI for
multiple WorkEffortGoodStandards (PRUN_PROD_DELIV) for each production
run, the data model seems like it would handle this no problem, except
that we would probably need to link what raw materials each product
consumed for actual costings.  I've had a quick look through the mrp run
code and  I can't see where this approach would cause problems, am I
missing something?

Thanks
Scott

Scott Gray wrote:

> Hi Jacopo
>
> I think we're pretty much on the same page now :-), I figured there
> were a couple of ways to go about it but a new grouping above the
> existing production run does seem like the easiest way to achieve what
> I'm after.  I might put together a couple of rough screen shots for
> feedback. Many thanks to you and Rodrigo for your input, those tricks
> will certainly come in handy later on.
>
> Thanks
> Scott
>
> Jacopo Cappellato wrote:
>> Scott,
>>
>> thanks for the example that is very helpful.
>> I still think that you should try to keep them as separate production
>> runs.
>> Why do you really need to create just one production run? In order to
>> simplify the production run creation? In order to provide a single
>> document to the workcenters' operators?
>>
>> In order to make the process more user friendly you could develop
>> instead a new "create production run" screen (it would be nice to
>> include it in svn too) that, for example, makes you select the
>> virtual product and then the units that you want to manufacture for
>> each variants and then it will automatically create all the
>> production runs (maybe we could associate all the production runs
>> together using a naming convention or the WorkEffortAssoc entity or
>> the parentWorkEffortId).
>> And you could customize the manufacturing documents (pdf) to put
>> together the information (sorted by task) from all the production
>> runs of this group.
>> In my opinion this will allow you to keep low the development costs
>> and to maintain everything compatible with the existing processes
>> (MRP etc...)
>>
>> Does it make sense?
>>
>> Jacopo
>>
>>
>> Scott Gray wrote:
>>> Hi Jacopo
>>>
>>> Thanks for your comments, I like the idea of what you've suggested for
>>> production planning.  However what I need is garments that are actually
>>> physically made together, I'll use your example of the T-Shirt to
>>> illustrate
>>> what i mean:
>>>
>>> There are 3 basic routing tasks for making a garment -
>>> 1. Cutting - the patterns for both sizes are marked on to a
>>> template, the
>>> template is then layed on to say 50 layers of fabric in order to cut 50
>>> t-shirts, cutting the sizes together saves on set up times and also raw
>>> material usage.
>>>
>>> 2. Making - once the garments are cut they all require the same sewing
>>> regardless of size. Side seams, neck binding, hemming etc., is
>>> always more
>>> efficient if you do them all in one go, you would never completely
>>> make size
>>> S and then get started on size L.
>>>
>>> 3.  Finishing - once again all items are processed together.
>>>
>>> Perhaps not suitable for svn?  Another process that comes to mind is
>>> getting
>>> garments embroidered with logo's where 10 different products might
>>> have the
>>> same process performed in one run.
>>>
>>> Regards
>>> Scott
>>>
>>
>>
>
>

[Jacopo Cappellato]

Hi Scott,

if I'm not wrong what you are suggesting implies:

1) the materials, fixed asset usage etc... are the same for each of the
variants

2) when the production run is created, the units that we want to
manufacture for each variants are known and set in the create production
run form

In my opinion #1 can be a strong and limiting assumpion: I could make many
examples of variants of the same virtual composed by different components.

About #2: this can really be done only when you manually create a
production run; when the production runs are created following the mrp
path, the system will create one production run for each variant...

Jacopo


Scott Gray wrote:

> Hi Jacopo
>
> I've been looking through the production run process a bit more and I'm
> just not feeling that comfortable with doing a grouping above multiple
> production runs, it seems like more of a hack than a solid improvement.
> I'm thinking a better approach would be to just cater in the UI for
> multiple WorkEffortGoodStandards (PRUN_PROD_DELIV) for each production
> run, the data model seems like it would handle this no problem, except
> that we would probably need to link what raw materials each product
> consumed for actual costings.  I've had a quick look through the mrp run
> code and  I can't see where this approach would cause problems, am I
> missing something?
>
> Thanks
> Scott

[Scott Gray]

Hi Jacopo

1. It would not use the same materials for each variant, it would still
have separate WorkEffortGoodStandards(PRUNT_PROD_NEEDED) for each
required material, if the same material was need for more than one
product it would just use the total required (this is the spot where I
see a problem because there would be no way currently to determine what
each product used later on for costings/avg usage etc. without looking
at the boms).  In regards to fixed asset usage, I haven't looked at it
yet as I won't be using it, but yes for each routing task they would all
use the same fixed asset, that's sort of the point of the whole thing,
to allow multiple products (not neccesarily just variants of one
virtual) to be processed through the same set of routing tasks together

2. While I'm still pretty limited in knowing how the mrp process works,
wouldn't it be possible to put a flag on a routing(not a task) that
signals that multiple products associated with this routing can be run
together?  Even if this can't be done initially it wouldn't remove any
existing functionality.

Scott


Jacopo Cappellato wrote:

> Hi Scott,
>
> if I'm not wrong what you are suggesting implies:
>
> 1) the materials, fixed asset usage etc... are the same for each of the
> variants
>
> 2) when the production run is created, the units that we want to
> manufacture for each variants are known and set in the create production
> run form
>
> In my opinion #1 can be a strong and limiting assumpion: I could make many
> examples of variants of the same virtual composed by different components.
>
> About #2: this can really be done only when you manually create a
> production run; when the production runs are created following the mrp
> path, the system will create one production run for each variant...
>
> Jacopo
>
>
> Scott Gray wrote:
>  
>> Hi Jacopo
>>
>> I've been looking through the production run process a bit more and I'm
>> just not feeling that comfortable with doing a grouping above multiple
>> production runs, it seems like more of a hack than a solid improvement.
>> I'm thinking a better approach would be to just cater in the UI for
>> multiple WorkEffortGoodStandards (PRUN_PROD_DELIV) for each production
>> run, the data model seems like it would handle this no problem, except
>> that we would probably need to link what raw materials each product
>> consumed for actual costings.  I've had a quick look through the mrp run
>> code and  I can't see where this approach would cause problems, am I
>> missing something?
>>
>> Thanks
>> Scott
>>    
>
>
>