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 <
[hidden email]> 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?
>>
>>
Locked
