In Search Of: Theory of product catalog composition

[jason_lunn]

Hello OFBiz-Users,

I'm just getting started with OFBiz and I am looking for a thread, wiki entry, document, or video that gives an in depth treatment to the different ways one could conceivably design one's product catalog.

The best series of documents I have found on the subject so far have been included in the oftaps user manuals.

I'm basically after a discussion of tradeoffs between the various ways one could describe the same set of products. Amongst other questions, this discussion would answer:

1) How is each product type different from the others in terms of the way they're treated by the standard OFBiz applications?
2) When is it most appropriate to use sub-assemblies?
3) The product being sold has a *lot* of permutations, say on the order of 10,000 different possibilities. What is the process for deciding which permutations should be features and which should be configurations?

Sincerely,

 - Jason

[BJ Freeman]

first I suggest you get the The Data Model Resource Book, Revised
Edition, Volumes 1 & 2" books referred
here
http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Related+Books
this will let you know the abilities of ofbiz.
then read
http://docs.ofbiz.org/display/OFBENDUSER/Catalog
Your questions would be answered differently for each industry.


jason_lunn sent the following on 12/4/2007 4:26 PM:

> Hello OFBiz-Users,
>
> I'm just getting started with OFBiz and I am looking for a thread, wiki
> entry, document, or video that gives an in depth treatment to the different
> ways one could conceivably design one's product catalog.
>
> The best series of documents I have found on the subject so far have been
> included in the
> http://sourceforge.net/project/showfiles.php?group_id=145855&package_id=189005
> oftaps user manuals .
>
> I'm basically after a discussion of tradeoffs between the various ways one
> could describe the same set of products. Amongst other questions, this
> discussion would answer:
>
> 1) How is each product type different from the others in terms of the way
> they're treated by the standard OFBiz applications?
> 2) When is it most appropriate to use sub-assemblies?
> 3) The product being sold has a *lot* of permutations, say on the order of
> 10,000 different possibilities. What is the process for deciding which
> permutations should be features and which should be configurations?
>
> Sincerely,
>
>  - Jason

[jason_lunn]

BJ Freeman wrote

first I suggest you get the The Data Model Resource Book, Revised
Edition, Volumes 1 & 2" books referred
here
http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Related+Books
this will let you know the abilities of ofbiz.
then read
http://docs.ofbiz.org/display/OFBENDUSER/Catalog
Your questions would be answered differently for each industry.

BJ,

Thanks for your response. I don't mean to come off sounding cheap, as I will definitely consider buying this book if I can figure out how to make OFBiz do what I need, but surely there is a free (as in beer) resource? I'm still in the proof of concept phase with my OFBiz adoption...

The wiki page doesn't really answer the "why" questions I posed. I think they're a great resource to understand how to build and edit my catalog once I've designed how the products will relate to one another, but I'm without a guideline for which tactic to adopt.

If it helps, the target industry is hand built custom musical instruments. There are dozens of options for every part of the instrument itself, and more options for the accessories, like the case and bow.

Some of the composition questions answer themselves. Obviously the components that are going to be available for sale as separate components, like the case and bow, will themselves be products. And since there are so many dimensions of options, it seems inefficient, even if it is possible, to make every permutation into it's own variant product with standard features. Does this mean it should be purely configuration, with nothing represented as a feature? Or, if there should be a mix, as I suspect, how should I go about deciding what should be a configuration and what should be a feature? Also, there's a hole in the knowledge I've sponged up so far as to what subassemblies are good for and when I should use those.

In the end, the goal is to a traditional eCommerce site that makes it possible to order non-custom products and to request quotes for custom instruments. We'd like to leverage as much of the MRP functionality as possible, even though right now the entire production facility is literally in a basement.

[v. sunder anand]

Data model resource book version-1 precisely describes this situation in the chapter 'products#products and parts'

In my opinion, You may be better off referencing the book and ofbiz data (entity) schema in parallel since you are sure about your needs.

-----Original Message-----
From: jason_lunn <[hidden email]>

Date: Tue, 4 Dec 2007 19:52:15
To:[hidden email]
Subject: Re: In Search Of: Theory of product catalog composition




BJ Freeman wrote:

>
> first I suggest you get the The Data Model Resource Book, Revised
> Edition, Volumes 1 & 2" books referred
> here
> http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Related+Books
> this will let you know the abilities of ofbiz.
> then read
> http://docs.ofbiz.org/display/OFBENDUSER/Catalog
> Your questions would be answered differently for each industry.
>

BJ,

Thanks for your response. I don't mean to come off sounding cheap, as I will
definitely consider buying this book if I can figure out how to make OFBiz
do what I need, but surely there is a free (as in beer) resource? I'm still
in the proof of concept phase with my OFBiz adoption...

The wiki page doesn't really answer the "why" questions I posed. I think
they're a great resource to understand how to build and edit my catalog once
I've designed how the products will relate to one another, but I'm without a
guideline for which tactic to adopt.

If it helps, the target industry is hand built custom musical instruments.
There are dozens of options for every part of the instrument itself, and
more options for the accessories, like the case and bow.

Some of the composition questions answer themselves. Obviously the
components that are going to be available for sale as separate components,
like the case and bow, will themselves be products. And since there are so
many dimensions of options, it seems inefficient, even if it is possible, to
make every permutation into it's own variant product with standard features.
Does this mean it should be purely configuration, with nothing represented
as a feature? Or, if there should be a mix, as I suspect, how should I go
about deciding what should be a configuration and what should be a feature?
Also, there's a hole in the knowledge I've sponged up so far as to what
subassemblies are good for and when I should use those.

In the end, the goal is to a traditional eCommerce site that makes it
possible to order non-custom products and to request quotes for custom
instruments. We'd like to leverage as much of the MRP functionality as
possible, even though right now the entire production facility is literally
in a basement.


--
View this message in context: http://www.nabble.com/In-Search-Of%3A-Theory-of-product-catalog-composition-tf4946653.html#a14164822
Sent from the OFBiz - User mailing list archive at Nabble.com.

[BJ Freeman]

then it is best to look at the demo data that comes with ofbiz.
the PC001 is a configurable item.
you can also do a BOM in manufacturing that is built of an item.
the trick is to combine the two if you want to capture the manufacturing
in to the configuration.



jason_lunn sent the following on 12/4/2007 7:52 PM:

>
> BJ Freeman wrote:
>> first I suggest you get the The Data Model Resource Book, Revised
>> Edition, Volumes 1 & 2" books referred
>> here
>> http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Related+Books
>> this will let you know the abilities of ofbiz.
>> then read
>> http://docs.ofbiz.org/display/OFBENDUSER/Catalog
>> Your questions would be answered differently for each industry.
>>
>
> BJ,
>
> Thanks for your response. I don't mean to come off sounding cheap, as I will
> definitely consider buying this book if I can figure out how to make OFBiz
> do what I need, but surely there is a free (as in beer) resource? I'm still
> in the proof of concept phase with my OFBiz adoption...
>
> The wiki page doesn't really answer the "why" questions I posed. I think
> they're a great resource to understand how to build and edit my catalog once
> I've designed how the products will relate to one another, but I'm without a
> guideline for which tactic to adopt.
>
> If it helps, the target industry is hand built custom musical instruments.
> There are dozens of options for every part of the instrument itself, and
> more options for the accessories, like the case and bow.
>
> Some of the composition questions answer themselves. Obviously the
> components that are going to be available for sale as separate components,
> like the case and bow, will themselves be products. And since there are so
> many dimensions of options, it seems inefficient, even if it is possible, to
> make every permutation into it's own variant product with standard features.
> Does this mean it should be purely configuration, with nothing represented
> as a feature? Or, if there should be a mix, as I suspect, how should I go
> about deciding what should be a configuration and what should be a feature?
> Also, there's a hole in the knowledge I've sponged up so far as to what
> subassemblies are good for and when I should use those.
>
> In the end, the goal is to a traditional eCommerce site that makes it
> possible to order non-custom products and to request quotes for custom
> instruments. We'd like to leverage as much of the MRP functionality as
> possible, even though right now the entire production facility is literally
> in a basement.
>
>

[jason_lunn]

Sunder,

Thanks for your reply. If I can find a copy of this book I'll check out that chapter. In the meantime, does is it seem odd to anyone else that such a core functionality of an Apache project is documented only in a $55 book? Having been published in 2001, this is not sitting on the shelves at Barnes and Noble or Borders any more (at least, not where I live).

Perhaps I need to modify my original question - can anyone explain to me how to decide what elements of a product should be features, configurations, and subassemblies and the tradeoffs between them?

 - Jason

Sunder Anand wrote

Data model resource book version-1 precisely describes this situation in the chapter 'products#products and parts'

In my opinion, You may be better off referencing the book and ofbiz data (entity) schema in parallel since you are sure about your needs.

-----Original Message-----
From: jason_lunn <[e-mail]>

Date: Tue, 4 Dec 2007 19:52:15
To:[e-mail]
Subject: Re: In Search Of: Theory of product catalog composition




BJ Freeman wrote:
>
> first I suggest you get the The Data Model Resource Book, Revised
> Edition, Volumes 1 & 2" books referred
> here
> http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Related+Books
> this will let you know the abilities of ofbiz.
> then read
> http://docs.ofbiz.org/display/OFBENDUSER/Catalog
> Your questions would be answered differently for each industry.
>

BJ,

Thanks for your response. I don't mean to come off sounding cheap, as I will
definitely consider buying this book if I can figure out how to make OFBiz
do what I need, but surely there is a free (as in beer) resource? I'm still
in the proof of concept phase with my OFBiz adoption...

The wiki page doesn't really answer the "why" questions I posed. I think
they're a great resource to understand how to build and edit my catalog once
I've designed how the products will relate to one another, but I'm without a
guideline for which tactic to adopt.

If it helps, the target industry is hand built custom musical instruments.
There are dozens of options for every part of the instrument itself, and
more options for the accessories, like the case and bow.

Some of the composition questions answer themselves. Obviously the
components that are going to be available for sale as separate components,
like the case and bow, will themselves be products. And since there are so
many dimensions of options, it seems inefficient, even if it is possible, to
make every permutation into it's own variant product with standard features.
Does this mean it should be purely configuration, with nothing represented
as a feature? Or, if there should be a mix, as I suspect, how should I go
about deciding what should be a configuration and what should be a feature?
Also, there's a hole in the knowledge I've sponged up so far as to what
subassemblies are good for and when I should use those.

In the end, the goal is to a traditional eCommerce site that makes it
possible to order non-custom products and to request quotes for custom
instruments. We'd like to leverage as much of the MRP functionality as
possible, even though right now the entire production facility is literally
in a basement.


--
View this message in context: http://www.nabble.com/In-Search-Of%3A-Theory-of-product-catalog-composition-tf4946653.html#a14164822
Sent from the OFBiz - User mailing list archive at Nabble.com.

[BJ Freeman]

that is more than can be accomplished in a mailing list.
first would be a document that details your whole opertaion.
then, against that document, deciding how to implement that into ofbiz.
it is best to get someone that understand ofbiz to go over the document
with you to accomplish this in a short time.

jason_lunn sent the following on 12/6/2007 11:08 AM:

> Sunder,
>
> Thanks for your reply. If I can find a copy of this book I'll check out that
> chapter. In the meantime, does is it seem odd to anyone else that such a
> core functionality of an Apache project is documented only in a $55 book?
> Having been published in 2001, this is not sitting on the shelves at Barnes
> and Noble or Borders any more (at least, not where I live).
>
> Perhaps I need to modify my original question - can anyone explain to me how
> to decide what elements of a product should be features, configurations, and
> subassemblies and the tradeoffs between them?
>
>  - Jason
>
>
> Sunder Anand wrote:
>> Data model resource book version-1 precisely describes this situation in
>> the chapter 'products#products and parts'
>>
>> In my opinion, You may be better off referencing the book and ofbiz data
>> (entity) schema in parallel since you are sure about your needs.
>>
>> -----Original Message-----
>> From: jason_lunn <[hidden email]>
>>
>> Date: Tue, 4 Dec 2007 19:52:15
>> To:[hidden email]
>> Subject: Re: In Search Of: Theory of product catalog composition
>>
>>
>>
>>
>> BJ Freeman wrote:
>>> first I suggest you get the The Data Model Resource Book, Revised
>>> Edition, Volumes 1 & 2" books referred
>>> here
>>> http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Related+Books
>>> this will let you know the abilities of ofbiz.
>>> then read
>>> http://docs.ofbiz.org/display/OFBENDUSER/Catalog
>>> Your questions would be answered differently for each industry.
>>>
>> BJ,
>>
>> Thanks for your response. I don't mean to come off sounding cheap, as I
>> will
>> definitely consider buying this book if I can figure out how to make OFBiz
>> do what I need, but surely there is a free (as in beer) resource? I'm
>> still
>> in the proof of concept phase with my OFBiz adoption...
>>
>> The wiki page doesn't really answer the "why" questions I posed. I think
>> they're a great resource to understand how to build and edit my catalog
>> once
>> I've designed how the products will relate to one another, but I'm without
>> a
>> guideline for which tactic to adopt.
>>
>> If it helps, the target industry is hand built custom musical instruments.
>> There are dozens of options for every part of the instrument itself, and
>> more options for the accessories, like the case and bow.
>>
>> Some of the composition questions answer themselves. Obviously the
>> components that are going to be available for sale as separate components,
>> like the case and bow, will themselves be products. And since there are so
>> many dimensions of options, it seems inefficient, even if it is possible,
>> to
>> make every permutation into it's own variant product with standard
>> features.
>> Does this mean it should be purely configuration, with nothing represented
>> as a feature? Or, if there should be a mix, as I suspect, how should I go
>> about deciding what should be a configuration and what should be a
>> feature?
>> Also, there's a hole in the knowledge I've sponged up so far as to what
>> subassemblies are good for and when I should use those.
>>
>> In the end, the goal is to a traditional eCommerce site that makes it
>> possible to order non-custom products and to request quotes for custom
>> instruments. We'd like to leverage as much of the MRP functionality as
>> possible, even though right now the entire production facility is
>> literally
>> in a basement.
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/In-Search-Of%3A-Theory-of-product-catalog-composition-tf4946653.html#a14164822
>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>
>>
>>
>

[jason_lunn]

Sunder Anand wrote

Data model resource book version-1 precisely describes this situation in the chapter 'products#products and parts'

In my opinion, You may be better off referencing the book and ofbiz data (entity) schema in parallel since you are sure about your needs.

Sunder,

I managed to find this section using the Amazon "search inside this book" feature.

It addresses my knowledge gap with regard to subassemblies very well. I now understand that subassemblies are supposed to represent raw materials that have been processed in house with some work effort but are not directly for sale. Thanks for citation.

I'm still unclear as to how to decide what elements of my products that are determined by buyer preference should be implemented as OFBiz Features and which should implemented as OFBiz Configurations. Again, the context of this is a highly configurable custom instrument (dozens of dimensions of customizability), and I'm hoping to get OFBiz to help me build a system for letting users submit requests for quotes.

It seems like I should not set out to develop thousands of concrete product variants, each implementing a set of standard features selected by the users' choices. Should I completely avoid any use of Features because of the number of dimensions of customizability, and instead use only Configurations? If I should use a mix, how should I decide what to make a Feature and what to make a Configuration?

[Adrian Crum]

Jason,

Much of this has been discussed in the past. Perhaps a Google search will give you more information:

http://www.google.com/search?hl=en&q=ofbiz+product+features+configurations+variants&btnG=Google+Search

-Adrian

jason_lunn wrote:

>
> Sunder Anand wrote:
>
>>Data model resource book version-1 precisely describes this situation in
>>the chapter 'products#products and parts'
>>
>>In my opinion, You may be better off referencing the book and ofbiz data
>>(entity) schema in parallel since you are sure about your needs.
>>
>
>
> Sunder,
>
> I managed to find this section using the Amazon "search inside this book"
> feature.
>
> It addresses my knowledge gap with regard to subassemblies very well. I now
> understand that subassemblies are supposed to represent raw materials that
> have been processed in house with some work effort but are not directly for
> sale. Thanks for citation.
>
> I'm still unclear as to how to decide what elements of my products that are
> determined by buyer preference should be implemented as OFBiz Features and
> which should implemented as OFBiz Configurations. Again, the context of this
> is a highly configurable custom instrument (dozens of dimensions of
> customizability), and I'm hoping to get OFBiz to help me build a system for
> letting users submit requests for quotes.
>
> It seems like I should not set out to develop thousands of concrete product
> variants, each implementing a set of standard features selected by the
> users' choices. Should I completely avoid any use of Features because of the
> number of dimensions of customizability, and instead use only
> Configurations? If I should use a mix, how should I decide what to make a
> Feature and what to make a Configuration?

[David E Jones]

I think BJ is right here. It sounds like you have a specific set of  
requirements (even if they aren't totally defined or clear yet), and  
in order to implement a system some analysis and design will be  
required, and that isn't something you can get from a book or an open  
source project.

Both are simply resources that once understood can be used as a  
foundation and tools to make your design and implementation efforts  
easier and less risky.

-David


On Dec 6, 2007, at 12:45 PM, BJ Freeman wrote:

> that is more than can be accomplished in a mailing list.
> first would be a document that details your whole opertaion.
> then, against that document, deciding how to implement that into  
> ofbiz.
> it is best to get someone that understand ofbiz to go over the  
> document
> with you to accomplish this in a short time.
>
> jason_lunn sent the following on 12/6/2007 11:08 AM:
>> Sunder,
>>
>> Thanks for your reply. If I can find a copy of this book I'll check  
>> out that
>> chapter. In the meantime, does is it seem odd to anyone else that  
>> such a
>> core functionality of an Apache project is documented only in a $55  
>> book?
>> Having been published in 2001, this is not sitting on the shelves  
>> at Barnes
>> and Noble or Borders any more (at least, not where I live).
>>
>> Perhaps I need to modify my original question - can anyone explain  
>> to me how
>> to decide what elements of a product should be features,  
>> configurations, and
>> subassemblies and the tradeoffs between them?
>>
>> - Jason
>>
>>
>> Sunder Anand wrote:
>>> Data model resource book version-1 precisely describes this  
>>> situation in
>>> the chapter 'products#products and parts'
>>>
>>> In my opinion, You may be better off referencing the book and  
>>> ofbiz data
>>> (entity) schema in parallel since you are sure about your needs.
>>>
>>> -----Original Message-----
>>> From: jason_lunn <[hidden email]>
>>>
>>> Date: Tue, 4 Dec 2007 19:52:15
>>> To:[hidden email]
>>> Subject: Re: In Search Of: Theory of product catalog composition
>>>
>>>
>>>
>>>
>>> BJ Freeman wrote:
>>>> first I suggest you get the The Data Model Resource Book, Revised
>>>> Edition, Volumes 1 & 2" books referred
>>>> here
>>>> http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Related+Books
>>>> this will let you know the abilities of ofbiz.
>>>> then read
>>>> http://docs.ofbiz.org/display/OFBENDUSER/Catalog
>>>> Your questions would be answered differently for each industry.
>>>>
>>> BJ,
>>>
>>> Thanks for your response. I don't mean to come off sounding cheap,  
>>> as I
>>> will
>>> definitely consider buying this book if I can figure out how to  
>>> make OFBiz
>>> do what I need, but surely there is a free (as in beer) resource?  
>>> I'm
>>> still
>>> in the proof of concept phase with my OFBiz adoption...
>>>
>>> The wiki page doesn't really answer the "why" questions I posed. I  
>>> think
>>> they're a great resource to understand how to build and edit my  
>>> catalog
>>> once
>>> I've designed how the products will relate to one another, but I'm  
>>> without
>>> a
>>> guideline for which tactic to adopt.
>>>
>>> If it helps, the target industry is hand built custom musical  
>>> instruments.
>>> There are dozens of options for every part of the instrument  
>>> itself, and
>>> more options for the accessories, like the case and bow.
>>>
>>> Some of the composition questions answer themselves. Obviously the
>>> components that are going to be available for sale as separate  
>>> components,
>>> like the case and bow, will themselves be products. And since  
>>> there are so
>>> many dimensions of options, it seems inefficient, even if it is  
>>> possible,
>>> to
>>> make every permutation into it's own variant product with standard
>>> features.
>>> Does this mean it should be purely configuration, with nothing  
>>> represented
>>> as a feature? Or, if there should be a mix, as I suspect, how  
>>> should I go
>>> about deciding what should be a configuration and what should be a
>>> feature?
>>> Also, there's a hole in the knowledge I've sponged up so far as to  
>>> what
>>> subassemblies are good for and when I should use those.
>>>
>>> In the end, the goal is to a traditional eCommerce site that makes  
>>> it
>>> possible to order non-custom products and to request quotes for  
>>> custom
>>> instruments. We'd like to leverage as much of the MRP  
>>> functionality as
>>> possible, even though right now the entire production facility is
>>> literally
>>> in a basement.
>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/In-Search-Of%3A-Theory-of-product-catalog-composition-tf4946653.html#a14164822
>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>
>>>
>>>
>>

[jason_lunn]

Adrian Crum wrote

Jason,

Much of this has been discussed in the past. Perhaps a Google search will give you more information:

http://www.google.com/search?hl=en&q=ofbiz+product+features+configurations+variants&btnG=Google+Search

-Adrian

Adrian,

Thanks for the search terms. I didn't come across anything that I hadn't either seen before or was unhelpful in learning what the specific tradeoffs are.

Perhaps you could explain some of your own process to me? Do you mostly use Features or Configurations, and why? Do you ever mix the two, and what basis do you decide what to make a Feature and what to make a Configuration?

[v. sunder anand]

Jason,

How different is your product from a 'apple book' check out this link

http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore.woa/91324000/wo/WL5TonGOQkXf2h1Hy1L1ZvhTSUw/2.?p=0

Can we combine 'features' and 'configuration' elements and collectively call
it as specification. Each specification could be represent a different
product.

Regards. v.sunder anand

On Dec 7, 2007 1:30 AM, jason_lunn <[hidden email]> wrote:

>
>
> Sunder Anand wrote:
> >
> > Data model resource book version-1 precisely describes this situation in
> > the chapter 'products#products and parts'
> >
> > In my opinion, You may be better off referencing the book and ofbiz data
> > (entity) schema in parallel since you are sure about your needs.
> >
>
> Sunder,
>
> I managed to find this section using the Amazon "search inside this book"
> feature.
>
> It addresses my knowledge gap with regard to subassemblies very well. I
> now
> understand that subassemblies are supposed to represent raw materials that
> have been processed in house with some work effort but are not directly
> for
> sale. Thanks for citation.
>
> I'm still unclear as to how to decide what elements of my products that
> are
> determined by buyer preference should be implemented as OFBiz Features and
> which should implemented as OFBiz Configurations. Again, the context of
> this
> is a highly configurable custom instrument (dozens of dimensions of
> customizability), and I'm hoping to get OFBiz to help me build a system
> for
> letting users submit requests for quotes.
>
> It seems like I should not set out to develop thousands of concrete
> product
> variants, each implementing a set of standard features selected by the
> users' choices. Should I completely avoid any use of Features because of
> the
> number of dimensions of customizability, and instead use only
> Configurations? If I should use a mix, how should I decide what to make a
> Feature and what to make a Configuration?
> --
> View this message in context:
> http://www.nabble.com/In-Search-Of%3A-Theory-of-product-catalog-composition-tf4946653.html#a14199745
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>
>

[v. sunder anand]

Jason,

Start from page 76 in data model resource book. You may find it useful.  I
am really new to OFbiz platform and my input is on the system analysis
perspective, which I am myself doing it for my requirement.

Regards, v.sunder anand


On Dec 7, 2007 6:58 AM, V. Sunder Anand <[hidden email]> wrote:

> Jason,
>
> How different is your product from a 'apple book' check out this link
>
> http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore.woa/91324000/wo/WL5TonGOQkXf2h1Hy1L1ZvhTSUw/2.?p=0
>
>
> Can we combine 'features' and 'configuration' elements and collectively
> call it as specification. Each specification could be represent a different
> product.
>
> Regards. v.sunder anand
>
>
> On Dec 7, 2007 1:30 AM, jason_lunn <[hidden email]> wrote:
>
> >
> >
> > Sunder Anand wrote:
> > >
> > > Data model resource book version-1 precisely describes this situation
> > in
> > > the chapter 'products#products and parts'
> > >
> > > In my opinion, You may be better off referencing the book and ofbiz
> > data
> > > (entity) schema in parallel since you are sure about your needs.
> > >
> >
> > Sunder,
> >
> > I managed to find this section using the Amazon "search inside this
> > book"
> > feature.
> >
> > It addresses my knowledge gap with regard to subassemblies very well. I
> > now
> > understand that subassemblies are supposed to represent raw materials
> > that
> > have been processed in house with some work effort but are not directly
> > for
> > sale. Thanks for citation.
> >
> > I'm still unclear as to how to decide what elements of my products that
> > are
> > determined by buyer preference should be implemented as OFBiz Features
> > and
> > which should implemented as OFBiz Configurations. Again, the context of
> > this
> > is a highly configurable custom instrument (dozens of dimensions of
> > customizability), and I'm hoping to get OFBiz to help me build a system
> > for
> > letting users submit requests for quotes.
> >
> > It seems like I should not set out to develop thousands of concrete
> > product
> > variants, each implementing a set of standard features selected by the
> > users' choices. Should I completely avoid any use of Features because of
> > the
> > number of dimensions of customizability, and instead use only
> > Configurations? If I should use a mix, how should I decide what to make
> > a
> > Feature and what to make a Configuration?
> > --
> > View this message in context:
> > http://www.nabble.com/In-Search-Of%3A-Theory-of-product-catalog-composition-tf4946653.html#a14199745
> > Sent from the OFBiz - User mailing list archive at Nabble.com.
> >
> >
>

[BJ Freeman]

BTW you link give a session timed out.
here is the ofbiz demo for configuration.
http://demo.hotwaxmedia.com/ecommerce/control/product/~category_id=PROMOTIONS/~product_id=PC001
I believe what Jason is trying to figure out is how to put the BOM into
the cart and have the create parts as the order comes in from the
ecommerce side.
though the mechanism is there, there may be some work he or a programmer
 to do.

The part that is not really done is to have a bom built from the
configuration then have the manufacturing generate the work order to
build those parts.
at least that is one way.
however till there is an understanding of how he builds these, I would
guess this is not going to be the only changes necessary.



V. Sunder Anand sent the following on 12/6/2007 5:28 PM:

> Jason,
>
> How different is your product from a 'apple book' check out this link
>
> http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore.woa/91324000/wo/WL5TonGOQkXf2h1Hy1L1ZvhTSUw/2.?p=0
>
> Can we combine 'features' and 'configuration' elements and collectively call
> it as specification. Each specification could be represent a different
> product.
>
> Regards. v.sunder anand
>
> On Dec 7, 2007 1:30 AM, jason_lunn <[hidden email]> wrote:
>
>>
>> Sunder Anand wrote:
>>> Data model resource book version-1 precisely describes this situation in
>>> the chapter 'products#products and parts'
>>>
>>> In my opinion, You may be better off referencing the book and ofbiz data
>>> (entity) schema in parallel since you are sure about your needs.
>>>
>> Sunder,
>>
>> I managed to find this section using the Amazon "search inside this book"
>> feature.
>>
>> It addresses my knowledge gap with regard to subassemblies very well. I
>> now
>> understand that subassemblies are supposed to represent raw materials that
>> have been processed in house with some work effort but are not directly
>> for
>> sale. Thanks for citation.
>>
>> I'm still unclear as to how to decide what elements of my products that
>> are
>> determined by buyer preference should be implemented as OFBiz Features and
>> which should implemented as OFBiz Configurations. Again, the context of
>> this
>> is a highly configurable custom instrument (dozens of dimensions of
>> customizability), and I'm hoping to get OFBiz to help me build a system
>> for
>> letting users submit requests for quotes.
>>
>> It seems like I should not set out to develop thousands of concrete
>> product
>> variants, each implementing a set of standard features selected by the
>> users' choices. Should I completely avoid any use of Features because of
>> the
>> number of dimensions of customizability, and instead use only
>> Configurations? If I should use a mix, how should I decide what to make a
>> Feature and what to make a Configuration?
>> --
>> View this message in context:
>> http://www.nabble.com/In-Search-Of%3A-Theory-of-product-catalog-composition-tf4946653.html#a14199745
>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>
>>
>