- v1.0.0-latest-prod
As of Broadleaf 1.4, the concept of ProductTypes was introduced to streamline the process of defining products and preparing them to go live on your site. In the context of the CatalogServices, the primary benefit of ProductTypes is the ability to define type-specific metadata, default values, and validation. This means that you’ll use the same backing Product/JpaProduct domain to manage your products, but can leverage metadata to completely customize the admin form for each ProductType.
Additionally, within the admin, we’ve established separate collections to browse products for each type independently.
|
Note
|
By default, only the standard, variant-based, and bundle product types are exposed in the admin. To enable other product types, add SELECTOR or MERCHANDISING_PRODUCT to the broadleaf.catalog.metadata.active-product-types list.
|
By default, we include the following ProductTypes…
A standard product represents a simple sellable good that doesn’t require the customer to select options or variations. A good example of this would be a basketball, or a hot sauce.
Key attributes:
The product has a single, unique SKU for tracking inventory
The product doesn’t have any variations that require the customer to declare a size, color, etc. before purchasing
Variant-based products are different from standard products in that they represent a good that is defined by a set of variants. For example, a shirt is best represented by a variant-based product. In this case, you may have several variants of the shirt such as a small, red variant and a large, blue variant. When the customer purchases one of these items, they must declare which variant they wish to purchase. Simply declaring that they’d like to purchase a shirt would not suffice. Instead, we must know if they wish to purchase the small, red shirt or the large, blue shirt. When rendering the product detail page, the customer can be presented with a list of variants, or they can be given size and color selectors to identify the specific variant that they’d like to purchase.
|
Note
|
ProductOptions should be used to define the attributes (e.g. size and color) that are required to identify specific variants and the possible values of those attributes (e.g. small, medium, and large for the size option). |
Key attributes:
The product itself cannot be purchased. Instead, the product’s variants are the items that can be purchased.
Each variant within the product must have a unique sku, and a "default" variant can be declared for the product by setting the Product.sku field with one of its variant’s skus. This distinction can be leveraged for things like auto-selecting the variant for the product’s PDP.
Inventory is not tracked for the product. Instead, inventory is tracked for the product’s variants.
Default pricing can be declared on the product, but it is only used if the variant does not declare its own pricing. For example, we could declare on the product that all of the shirt’s variants are $10 by default, but on each of the blue shirt variants, we could declare a $12 price.
As a product merchandiser, you might choose to group a set of items at a slightly lower price to drive additional sales. A bundle product is composed of items that could be sold individually but are grouped and sold as a single unit.
Key attributes:
Pricing is declared for the overall bundle, instead of summing individual components of the bundle.
Discounts can only target the bundle. Discounts targeting individual bundle items are not considered.
To determine if a bundle is available (i.e. if there is available inventory), we must check if all components of the bundle are available. If inventory isn’t available for any of the bundle items, then the entire bundle is considered unavailable for purchase.
Selector products simplify a specific use-case we’ve seen from different clients and prospective clients where a customer is given a choice between several product offers. For example, imagine that you have several different product bundles that you want the customer to be able to choose between. Each bundle could be related but offering a slightly different combination of products. The customer can choose one of these bundles to purchase, with the selector product itself providing general details about the information common to each bundle.
This type of product does not have inventory or a price of its own, but instead allows several products to be displayed and made purchasable on a single landing page. Thus, it is purely a wrapper for related products.
|
Note
|
Due to the fact that selector products are not widely used, the ability to create/manage them via the admin is hidden by default. To enable this product type, add SELECTOR to the broadleaf.catalog.metadata.active-product-types list.
|
A merchandising product is ideal when you want to create a configurable bundle of various items. For example, you could create a bundle that allows the customer to choose between 3 and 10 items for $5 each. Or you could create a "Buy a shirt from category X and jeans from category Y" type bundle. These are similar to bundle products with two key differences:
The customer is given the opportunity to declare which items to include in the bundle.
The bundle’s price is determined by the sum of the bundle’s items. In other words, each item that is selected by the customer contributes its price to the overall price of the bundle. Note: price overrides can be declared for individual item choices to provide more control over the overall bundle’s price.
Since merchandising products are a means of dynamically bundling other products, they don’t have a SKU value and don’t have any inventory information.
|
Note
|
Due to the overall complexity of merchandising products, we consider them an experimental feature and have decided to hide the ability to create/manage them via the admin by default. To enable this product type, add MERCHANDISING_PRODUCT to the broadleaf.catalog.metadata.active-product-types list.
|