Broadleaf Commerce Discussion Forums

I see SKU as list in Product entity, when I look at the demo data, product and SKU are mapped 1:1, which means in Product entity I will always have one entry in the List<SKU>

Can you please help me understand the thought process behind this.

Is this meant to support multiple options selections for a product and based on the selection the total price of the product changes. For example I have a product and I can change couple of features, each feature costs different price. Will this product be configured in such a way that the options are captured in terms of SKU.

Or that the product can be preconfigured with options that can be swapped across and the total price of the product gets calculated.

Thank you for all the support
Sai

We have two possibilities for associating skus with products. One option is to relate them in an OneToOne fashion. The other way is to establish a ManyToMany relationship between the two. Most customers model their product domain using the OneToOne relationship represented by org.broadleafcommerce.core.catalog.domain.ProductSkuImpl. This is the approach that is demonstrated in the admin as well. The admin currently works using the OneToOne relationship. With the ManyToMany approach represented in org.broadleafcommerce.core.catalog.domain.ProductImpl, there is a possibility to represent your domain in terms of multiple skus per product. The classic example of this would be a hat product. Each sku associated with this product might be a different color, for example a red hat and a blue hat. These could conceivably have the same price or different prices as well. However, this is not the approach one would use to dynamically price an item based on features/modifiers. I spent some time explaining the approach to achieve this in another post:

viewtopic.php?f=11&t=509&p=1535#p1535

We are working on adding an optional UI to the admin application that would allow managing the ManyToMany relationship style as well.

Thank you for quick response Jeff.

I read through the other post and see that I cannot use the SKU in a manner that each SKU can be a product's feature/modifier. That is good to know.

Here is what I am trying to do. I have a product where I give multiple features, one can choose from. Which is the reason why I was looking for opportunity to see if I can reflect the product and its options selections in terms of SKU's, where one product mapped to multiple SKU (a.k.a feature/modifier).

Since I cannot use that, I was wondering, if I can create a product on the fly with chosen options in the Site project itself. Currently products can be added through Admin project.

What would be my best option to be able to create product on fly, after customer chooses features/modifier on a product.

Please advise.

Thank you for the support. I appreciate it very much.

The topic I referenced above (viewtopic.php?f=11&t=509&p=1535#p1535) explains the approach to do exactly what you're talking about. What you want, I think, is a DiscreteOrderItem in the cart (which is basically an individual customer specific instance of a Product) with modifiers on it that can affect the price. This is what DiscreteOrderItemFreePriceImpl provides.

Is there an example that I can look at which depicts the Discrete Order Item scenario?

I am trying to play through the scenario on how I can capture the base product and tie it to the features.

If I create a product per feature in BLC_PRODUCT, how can I tie these multiple products, will it be by creating one product as Base product and then create features as products and add base product id to each of the feature(product), inorder for me to tie them together, when I am displaying the Base product with features.

While saving, a DiscreteOrderItem is created with BaseProduct & features(products) together as one Order Bundle.

Please correct me if I am not thinking in the right direction.

Hey James, you hit the nail on the head. We are currently right in the middle of changing around our domain model to support the idea of multiple Skus based on product options (just as you described in your initial post). We already have a fair amount of development towards this (see ProductOption.java and ProductOptionValue.java) and I believe we have what we want from a domain modeling perspective. Essentially, a Product can have multiple ProductOptions (which would be something like 'Size' or 'Color') and each ProductOption has a list of ProductOptionValues (like 'Small' 'Medium', 'Large' or 'Blue'). Sku also has a ManyToMany to ProductOptionValue which allows you to base a Sku off of a particular Product and a particular set of ProductOptionValues.

The ManyToMany between Product and Sku is thus going away and is being replace by a OneToMany from Product -> Sku. I believe the initial idea of a ManyToMany was to support bundles (a Sku could be a member of many Products) but we have solved that in a different fashion: ProductBundle.java and SkuBundleItem.java.

All of these changes that I mentioned are currently in the develop branch of our repository which represents the 1.7.0-SNAPSHOT version of the framework (which I believe is going to change to 2.0 because we have so many changes going in).

Just an additional clarification, all of the features that I mentioned will be modifiable in the admin panel (most of them are already in the 1.7.0-SNAPSHOT version).