Product Variants and Integration for E-Commerce

Product variants allow shoppers to select a specific version of a product—such as a shirt’s color and size or a shoe’s size and width—without browsing a separate product page for every combination.

Retailers and POS/ERP systems may call these product variants, gridded products, matrix products, or style-based products. Some systems use the term “soft goods,” but the underlying structure applies to much more than clothing. Hardware, marine supplies, garden products, and other merchandise can also have variations.

Modern Retail connects these product structures to your e-commerce platform by grouping related items while preserving the identity, inventory, and pricing of each sellable variation.

The central principle is simple: related variations share a product grouping, but each sellable variation has its own SKU.

This guide explains Modern Retail’s product variant model. The fields available from your POS/ERP and the capabilities of its integration determine how that model is implemented.

Consider a shirt available in two colors and three sizes.

• Product: Everyday T-Shirt.

• Options: Color and Size.

• Color values: Navy and Sand.

• Size values: Small, Medium, and Large.

• Variants: Navy/Small, Navy/Medium, Navy/Large, Sand/Small, Sand/Medium, and Sand/Large.

This product has two option dimensions and six sellable variants.

That distinction matters when discussing Modern Retail’s three-option limit. The limit concerns the number of independent option dimensions—not the number of colors, sizes, or sellable variations.

Modern Retail uses the ALU to identify which variants belong together.

In a POS/ERP that uses a parent-and-child structure, the parent or style SKU can populate the ALU. Each child retains its own sellable SKU while sharing the parent’s grouping identifier.

For example:

Modern Retail can use the shared TEE-100 grouping to organize these six variations under one online product.

The ALU and the variant SKU serve different purposes:

• The ALU identifies the product family.

• The SKU identifies the exact item being sold.

A source system does not have to label its grouping field “ALU.” It may use a parent item number, style identifier, or another shared value. The integration maps the appropriate source information into Modern Retail’s grouping structure.

Grouping identifiers and variant SKUs should remain consistent over time. Changes to those identifiers need to be reviewed because they can affect how existing online products and variations are matched.

Some information describes the whole product. Other information belongs to an individual variation.

The parent/style record typically supplies:

• Product name.

• Product description.

• Other supported descriptive information shared by the variations.

Using the parent’s name and description helps avoid building the online product from a child description that has size, color, or other attributes appended to it.

This can also prevent shortened or truncated child descriptions from becoming the main online product description.

Each sellable variation carries its own relevant information, including:

• SKU.

• Option names and values.

• Inventory quantity.

• Price.

• UPC or barcode, where supplied.

• Weight, where supported.

Additional information, such as shipping dimensions, depends on the source system and integration.

Variants do not have to share the same price, inventory, barcode, or weight.

An extra-large shirt may cost more than a small shirt. A larger item may weigh more. A navy/medium shirt can be in stock while the sand/medium version is sold out.

Those differences belong to the individual variant.

Modern Retail’s model stores the individual sellable variations and uses the parent information to populate their shared product details.

A separate sellable parent item is not required within that model. Modern Retail needs enough source information to determine:

• Which variations belong together.

• Which information describes the shared product.

• Which information belongs to each sellable variation.

The typical workflow is:

1. Create or maintain the product structure in the POS/ERP. Define the product family and its individual sellable variations.

2. Provide the grouping information. Each variation must be associated with the correct parent/style identifier or other agreed grouping value.

3. Provide each variant’s SKU and option details. Modern Retail needs to know both the option names and their corresponding values.

4. Provide shared and variant-specific data. This includes the common product information and supported variation-level pricing, inventory, and other fields.

5. Modern Retail organizes the online product. Related variants are grouped according to the configured mapping.

6. Manage website presentation in the e-commerce platform. Images, videos, and other merchandising elements are maintained through the website’s supported tools.

The exact delivery method—such as an API or product feed—depends on the POS/ERP integration. The important requirement is that the data contains the relationships and values needed to build the product correctly.

Modern Retail is not limited to options named “Color” and “Size.”

Different products can use different option names:

• Shirts: Color and Size.

• Shoes: Size, Width, and Color.

• Pants: Waist, Inseam, and Color.

• Gloves: Size and Material.

• Other merchandise: Length, Diameter, Finish, Capacity, or another relevant attribute.

Modern Retail consumes the option names and values supplied through the integration. Products do not all need to use the same set of options.

For example, a clothing product can use Waist and Inseam, while another product uses Material and Length.

Consistent source data makes the online product easier to understand and maintain.

For example:

• Choose a consistent approach to “Small” versus “S.”

• Avoid unintentionally mixing “Navy” and “Navy Blue” for the same color.

• Use consistent units for measurements.

• Keep option names meaningful to shoppers.

• Ensure each variant has the values needed to distinguish it from the others in its group.

The integration should receive explicit option information wherever possible. Do not assume that a size or color embedded only in a description will automatically be interpreted as a product option.

A product can contain all the correct variants and still be confusing to shop if its options appear in the wrong order.

For example, alphabetical sorting might display clothing sizes as:

Large, Medium, Small

Text-based sorting can also produce an unexpected sequence for numeric-looking values:

1, 10, 11, 12, 2

The intended shopper experience may instead be:

Extra Small, Small, Medium, Large, Extra Large

Where supported, the source data can include a separate numeric field indicating the intended order of the variations.

That field might be called a sort order, sequence, or ordinal.

For example:

The sequence groups the small sizes first, followed by medium and large.

The approach discussed for Modern Retail places the ordinal on the individual variation/SKU record. It does not require a universal size table that every product must use.

Without an explicit ordering field, variants may be created in the order received or according to another default behavior. The result can look arbitrary or alphabetical.

An ordinal therefore provides useful direction, but its availability and use must be confirmed for the integration. The e-commerce platform and theme also influence the final presentation.

During onboarding, verify both the incoming sequence and the order shoppers actually see on the product page.

Modern Retail currently supports up to three independent option dimensions per product.

Examples include:

• Color + Size + Width.

• Waist + Inseam + Color.

• Material + Length + Finish.

This does not mean a product is limited to three sellable variants.

For example, a product with:

• Four colors.

• Five sizes.

• Two widths.

Could have 40 sellable combinations while still using only three option dimensions.

The number of option dimensions and the number of variant combinations are separate considerations. Your e-commerce platform may also impose its own limits, so the final structure must fit both Modern Retail’s integration model and the platform.

Products requiring more than three independent options have been very uncommon in Modern Retail’s experience. When they do arise, restructuring the product can provide a practical solution.

Suppose a product has four option dimensions:

Color + Waist + Inseam + Fabric

One approach is to separate the product by color.

The result could be:

• Blue Work Pants: Waist, Inseam, and Fabric.

• Black Work Pants: Waist, Inseam, and Fabric.

Each resulting product now has three option dimensions.

If there are more colors, the same approach can produce additional products.

Modern Retail can implement this separation programmatically as part of the configured integration mapping.

The process uses a selected attribute—such as color—to determine which online product receives each variation. The remaining attributes become the selectable options within that product.

This should be planned as an implementation rule. It is not something to assume happens automatically whenever a fourth option appears.

The mapping needs to define:

• Which attribute determines the split.

• How each resulting product is identified and named.

• Which variants belong to each resulting product.

• How the original variant SKUs remain associated with their inventory and pricing.

• How future variants and new attribute values follow the same rule.

Each resulting online product needs a distinct grouping identity, while the sellable variants must remain correctly connected to their source items.

The best attribute depends on how customers shop.

Color can be a useful choice when shoppers benefit from seeing separate product images in search results or category listings. Material, finish, or another major distinction may be more appropriate for other products.

For example, marine equipment with Material, Size, Pitch, and Rotation could potentially be separated by material, leaving three options within each resulting product.

Separate products can sometimes be presented as related choices—for example, showing another color as a selectable image or link.

That presentation is handled through the e-commerce platform, theme, or an appropriate website feature. It is separate from Modern Retail’s work to group and synchronize the product data.

An existing product can grow over time.

For example, a shirt initially available in Small, Medium, and Large may later gain an Extra Large option.

To add the new variation, the integration needs:

• Its new sellable SKU.

• The correct existing product grouping/ALU.

• Its option names and values.

• Its supported price, inventory, and other variant information.

• Its intended ordinal, if sort order is supplied.

Modern Retail can then add the variation to the existing product through the supported integration.

The grouping information is particularly important. A new size should point to the existing product family when it belongs on that product page.

For products that use programmatic splitting, new variants must also follow the agreed splitting rule.

Adding a variant and removing one are different operations.

Do not assume that deleting or deactivating a variant in the POS/ERP automatically deletes it from the website.

These situations should be distinguished:

• A variant temporarily has zero inventory.

• A variant is discontinued but still has a product record.

• A variant is no longer intended for online sale.

• A variant is removed from the source system.

The desired online behavior and available integration support must be established for each case.

Changes to grouping identifiers, option names, or the structure of an existing live product should also be reviewed before they are made.

In the product integration model described here, images are managed in the e-commerce platform.

This includes associating different images with different variations where the platform supports it. For example, selecting a navy shirt can display the navy product image, while selecting sand can display the sand image.

Modern Retail’s variant data establishes the product relationships and option values. Image assignment and presentation are website merchandising tasks.

This workflow does not include ingesting product images from the POS/ERP. Product videos and other rich presentation elements are also managed through the website’s tools.

• Maintain accurate product groupings and sellable SKUs.

• Enter consistent option names and values.

• Maintain supported variant-level pricing and inventory.

• Identify the desired option order.

• Explain how discontinued and newly added variants should behave.

• Make the required product relationships and variant fields available through the supported API or feed.

• Clarify how parent/style items, child SKUs, attributes, and any ordinals are represented.

• Identify any source-system limitations.

• Map the source product grouping to the appropriate ALU structure.

• Associate sellable SKUs with their product families.

• Use shared and variant-specific information to build the supported online product structure.

• Synchronize the supported fields.

• Configure agreed transformations, including programmatic product splitting where required.

• Manage images, videos, and merchandising.

• Configure the product-page presentation.

• Verify the shopper’s option-selection experience.

• Implement any desired links between separately presented products.

Core product model: Modern Retail groups sellable variants using a shared identifier and supports up to three option dimensions. Each variation retains its own SKU and supported pricing, inventory, and other fields.

Integration-specific configuration: Source field mappings, parent identification, sort order, update behavior, and variant lifecycle handling depend on the POS/ERP and e-commerce integration.

Optional transformation: Programmatic splitting can accommodate products with more than three option dimensions when an appropriate mapping is configured.

Additional development: A POS/ERP may support variants internally without exposing all the required data to an integration. Missing API or feed capabilities may require development before the desired workflow is available.

No. Each sellable variant can have its own price. A larger size, different material, or another variation can be priced differently.

Inventory is associated with the individual sellable variation. The stock of a navy/medium shirt is separate from the stock of a sand/medium shirt.

Yes. Each distinct sellable variation needs its own SKU within the integration’s agreed identification model.

No. Option names are flexible. Use the attributes that describe the product accurately.

No. Size is one option dimension. It can have multiple values. The limit concerns independent dimensions such as Size, Color, and Width.

There may be a straightforward solution. Modern Retail can configure a programmatic split based on one dimension so that each resulting product uses no more than three options.

It should be added to the existing product when its grouping information correctly identifies that product family and the integration supports the update.

Do not assume they will. An explicit numeric ordinal can help establish the intended sequence. Confirm the supported mapping and verify the website display.

1. Select representative products. Include a simple product, a product with several options, and any unusual cases.

2. Identify the source grouping field. Confirm how Modern Retail will recognize the parent/style relationship and populate the ALU.

3. Verify variant identifiers. Confirm that every sellable combination has the correct SKU.

4. Review shared and variant-specific fields. Check names, descriptions, option values, inventory, prices, barcodes, and supported shipping information.

5. Define the intended sort order. Determine whether the source can provide a variation-level ordinal.

6. Identify products with more than three dimensions. Agree on a splitting strategy where needed.

7. Define addition and removal behavior. Confirm how new sizes, discontinued variations, and changes to existing products will be handled.

8. Prepare website merchandising. Assign images and configure the product-page experience.

9. Test the complete product lifecycle. Verify initial creation, price and inventory changes, new variants, ordering, and the configured handling of inactive or removed items.

When reporting a variant issue, provide the product grouping/ALU, affected variant SKUs, expected option values, and a description of the behavior you see online.

For sorting issues, include the intended sequence. For grouping issues, identify which variations should appear together.

These details help Modern Retail determine whether the issue concerns source data, integration mapping, product updates, or website presentation.