Possibly. Is it possible for features to have features, creating a feature hierarchy? The followup to this has to do with pricing. If a feature hierarchy was my solution, can I get pricing rules to first establish price per bean (based on customization) roll that up into a price per bean set, and further roll up the cost of all bean sets in a basket, so as to create a single price?
Thanks, -- Alex On Wed, Jan 25, 2012 at 11:58 AM, Adrian Crum < [email protected]> wrote: > Bean features are features of a bean, and beans are a feature of the gift > basket. Does that meet your requirements? > > -Adrian > > > On 1/25/2012 2:51 PM, Alex Redinger wrote: > >> Here is a hypothetical problem to outline what I am looking for. >> >> Let's say I am selling customizable jellybean gift baskets. At the time of >> purchase, the customer chooses a gift basket and then decides how many >> beans they want in it. Each bean, in turn, may be customized from a list >> of >> various features. There are too many possible bean feature configurations >> for each jelly bean to reasonably be represented as a predefined "feature" >> of the gift basket. What's more, selling the basket and beans as separate >> items runs into a problem if the customer is to purchase multiple baskets >> in the same order. How do I keep track of what (and how many) beans got to >> what basket? >> >> I have been reading through various Ofbiz tutorials and documentation, >> looking for a solution to this. Product configuration and featuring do >> provide a partial solution but does not completely satisfy the question at >> the end of my example. >> >> Do I need to extend the entity model to allow for these kinds of >> product-to-product associations? Or is their already something out there >> that can address my issue? >> >>
