Products: virtual & variant; features & attributes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Products: virtual & variant; features & attributes

Nathan C Hampton
Greetings all!

I'm new at this and a little confused about how to handle products.  
My organization sells books, and we're trying to figure out how to use  
OFBiz to handle our product information. We track a lot of data about  
each item (I won't bore you with the complete list unless you really  
want it), and I'm trying to determine the best way to handle it. Some  
specific examples:

1) We sell Bibles.  Some items, like gift & award Bibles, come in a  
veritable rainbow of colors and even in multiple binding types.  This  
seems to be precisely the situation for which virtual & variant  
products were intended, in which case the binding type and color would  
be selectable features in the virtual product 'gift/award bible' and  
distinguishing features in its variants, such as 'gift/award bible  
(red leatherflex)'.  Is this correct?

2) We also keep track of the binding type for items which don't match  
the virtual/variant model.  (Such items comprise the vast majority of  
our catalog.)  "Splitting Harriet", for example, has the binding type  
"Trade Paper".  For this product, would I use the same binding type  
feature as I used above, again as a distinguishing feature?

3) Binding types are a limited set of pre-defined options.  Other  
information, such as number of pages, is (from a practical standpoint)  
infinitely variable.  It doesn't make sense to me to create a separate  
product feature entry for each possible number of pages from, say, 10  
to 500.  Is this the sort of situation where we would use attributes  
instead of features?  If so, is there a switch somewhere that can turn  
on display of attributes in the default ecommerce website, or will I  
need to use a custom web app to do this?  Alternately, would it be  
easier to simply modify the Product entity to provide a field for this  
information?

4) Books can have one or more authors, one or more editors, one or  
more illustrators, and so forth.  Is this another area where  
attributes would be used?  For "Old Turtle", I'd have the following:
     +----------------+-----------------+----------------+
     | Attribute Name | Attribute Value | Attribute Type |
     +----------------+-----------------+----------------+
     | Contributor    | Douglas Wood    | Author         |
     | Contributor    | Cheng-Kee Chee  | Illustrator    |
     | Contributor    | Jon J Muth      | Illustrator    |
     +----------------+-----------------+----------------+
Would this work?  Also, we need to be able to search this  
information.  Would we just use a keyword search, or is there some way  
to specifically search attributes (or, ideally, specific attribute  
types)?

5) When creating and editing product listings, is there a way to batch  
add attributes (like you can do with feature groups)?  If we wind up  
using attributes for both contributors and page numbers (along with a  
host of other information), I'd like to create a set of standard  
attributes that should be entered for every product.

6) A lot of what we want to track is based on the ONIX standard, which  
is a system for communicating information about books using XML.  ONIX  
defines a bunch of code lists, which appear to match up quite nicely  
with the product feature functions in OFBiz.  If I want to use the  
ONIX code lists, will it cause problems if I import this information  
directly into the database?  (Assume I've ensured unique primary keys.)

7) Is there a way to create rules governing the application of  
features?  Looking at the demo data, for example, it doesn't make  
sense for a single gizmo to have both the Equipment Class features  
Boat and Forklift applied to it, but I don't see any way to prevent  
such things from occurring.  (Of course, it's also possible that I  
haven't looked quite far enough yet.)

8) Would I be better off to create custom entities to handle some of  
the more specialized information, or would this just make a royal mess  
out of everything else?

I think that's all for now.  Thanks in advance for whatever help you  
can offer!

--Nathan C. Hampton ([hidden email])