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 <[EMAIL PROTECTED]> > > Date: Tue, 4 Dec 2007 19:52:15 > To:user@ofbiz.apache.org > 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. > > > -- View this message in context: http://www.nabble.com/In-Search-Of%3A-Theory-of-product-catalog-composition-tf4946653.html#a14198819 Sent from the OFBiz - User mailing list archive at Nabble.com.
