Product

Product modeling and variations in Omnium

This section provides an overview of how to model products and handle variations in the Omnium system. It covers product types, including single SKUs, products with variants, siblings, and package products. It also includes key considerations and best practices for managing product variations efficiently to ensure optimal performance and clarity.

Product types and variations

Single SKU

• A product that represents a single Stock Keeping Unit (SKU).
• No variations or series (e.g., no multiple colors or sizes).

Example: Individual bicycle pedals.

---

Product with variants

• Contains variations such as size or color.
• Includes a list of SKUs referred to as variants.
• Pricing is often set at the parent level but can also differ for each variant.
• Recommendation: Vary by only one property (e.g., size OR color).

---

Sibling products

• Can be Single SKUs or Products with Variants.
• Share the same Parent ID, connecting them as a series.
• Commonly used in fashion to display variations (e.g., colors).

Example: Jerseys in different colors with sizes as variants.

---

Other product variations

• Package Products: Products that include multiple components.
• Products with Options: Allow users to customize certain features (e.g., engraved text).

---

Key considerations for product modeling

Managing Variants

• Limit Variants: Avoid products with more than 50 variants. If necessary, reconsider your product model.
• Data Duplication: Keep shared information at the product level to avoid duplication.
• Performance: Variants are stored within the product document, so each variant update affects the entire product. Variants are not individually searchable.

Sibling Products

• Share the same ParentId and can inherit properties from each other.
• Example Use Case: For a t-shirt in 10 colors and 5 sizes, create 10 sibling products (one for each color) with 5 size variants each.

Example structure:

Yellow shirt

• ID: shirt-yellow_no
• ProductId: shirt-yellow
• ParentId: shirt
• Variants: Sizes S, M, L

Blue shirt

• ID: shirt-blue_no
• ProductId: shirt-blue
• ParentId: shirt
• Variants: Sizes S, M, L

Best practices

• Centralize Data: Store most information at the product level. Only variant-specific data should be stored in variants.
• Use Null Values: Avoid empty strings; use null instead.
• Focus on Simplicity: Create multiple focused products rather than overly complex ones.
• Avoid Unused Custom Properties: Use product types for editable properties in the UI.

---

Industry-specific examples

Electronics

• Scenario: A smartphone with different storage capacities and colors.
• Recommendation: Separate products by storage (e.g., "Smartphone 64GB" and "Smartphone 128GB") with color variants.

Footwear

• Scenario: Shoes available in multiple colors and sizes.
• Recommendation: Separate products by color (e.g., "Red Sneakers" and "Blue Sneakers") with size and width as variants.

Appliances

• Scenario: Washing machines with different load capacities and energy ratings.
• Recommendation: Separate products by load capacity (e.g., "7kg Washing Machine" and "10kg Washing Machine") with energy rating variants.

---

Assortment using store categories

Setting categories for stores

To control product access via categories, follow these steps:

Assign categories to stores

• Configure the desired category or categories on the relevant stores.

Enrichment process upon product storage

• When a product is stored or updated, an enrichment process is triggered.
• During this enrichment, the system checks whether any stores share a category with the product.
• If a match is found, the storeId for the matching store is added to the product.

How product access works

When a store is selected, the system retrieves all products enriched with a storeId that matches the store’s configured category. This ensures that only products belonging to the specified category are accessible in that store.

Automated Updates Using Scheduled Tasks

To keep product access up to date, you can use the scheduled task:

• Scheduled Task Name: Update assortment by store categories.
• Purpose: Updates the product assortment by verifying and applying the latest category-to-store mappings.
• Recommended Schedule: Run this task nightly to ensure that all product and store configurations remain synchronized.

---