Designing SKU (Trade Offers) in 1C-Bitrix

You launch an e-commerce store on 1C-Bitrix with hundreds of product variations: sofas in 20 colors, sneakers in 10 sizes, laptops with different memory sizes. The standard infoblock schema often overlooks the specifics of a multi-variant catalog, leading to scaling issues. The parameter filter must show only what is in stock, and the exchange with 1C must not produce duplicates.

If you make an error in SKU design at this stage, the consequences will affect performance and stock accuracy. Every extra database query reduces response speed, and incorrect linking of offers creates duplicates. We design trade offers (SKU) so that filtering works instantly and stocks are not duplicated.

Our experience includes dozens of projects with thousands of product variations. We know how to properly separate product and offer properties, configure the faceted index, and organize stable exchange with 1C. We will assess your project turnkey in 3-8 days — just contact us. Get a consultation and we will analyze your catalog structure.

Technical SKU schema in Bitrix

A trade offer is an element of the offer infoblock linked to the parent product. In the database:

• b_iblock_element — product (type TYPE_PRODUCT)
• b_iblock_element — offer (type TYPE_OFFER)
• b_catalog_product.OWNER_ID — link
• b_catalog_price — price at the offer level
• b_catalog_store_amount — stocks

The term SKU (Stock Keeping Unit) is used to uniquely identify a variant. Link setup: Content → Catalog → [infoblock] → Trade offers. The catalog.element component displays the product card; it must correctly select the active offer.

How to properly separate product and offer properties?

The main rule: a property belongs to an offer if its value changes the price or stock. For example:

• Product properties: name, description, brand, category, base images.
• Offer properties: color, size, volume, SKU, barcode, variant image.

An error is to put color in the product: then it is impossible to filter "blue dresses size 42" because stocks are tied to the offer.

Why does filtering by offer properties slow down?

The standard bitrix:catalog.smart.filter component can filter by offer properties, but the faceted index is built separately. If a product has 50+ offers, queries can be heavy. Custom filtering with a proper facet works 2–3 times faster. A complex case is simultaneous filtering by product and offer properties: the standard facet does not support cross-iblock. The component needs modification, e.g., a custom filter with preliminary aggregation.

For large catalogs (hundreds of thousands of SKU), we use a faceted index with preliminary aggregation. This gives a 40% speed increase compared to the standard solution. Our experience confirms: competent filter design pays off under load. Budget savings on revisions can reach up to 30%.

How to avoid SKU duplication during exchange with 1C?

In CommerceML, offers are transmitted in ЗначенияРеквизитов. Critical: the XML-ID must be unique and stable. According to the 1C-Bitrix documentation, even a one-time change of the identifier leads to duplication. Agree on the format with the 1C team before starting.

Case study: furniture store with 14,000 SKU

We configured a catalog for a soft furniture store: 1,200 models, each in 8–20 fabric variants — total 14,000 offers. After initial setup, the color filter showed products where color was in the parent product property, not the offer. The sofa "Marco" with color "beige" appeared even if all beige variants were sold out. Solution:

1. Moved color and material to the offer infoblock.
2. Set up the faceted index on the offer infoblock.
3. Added a check in the section component: a product is displayed only if an offer with stock > 0 and the required color exists.
4. Variant images in the offer property, model images in the product.

After the modification, filtering worked correctly, and "out of stock" is shown for specific variants without hiding the product. Time savings on query processing — 40%. We guarantee your catalog will work without failures. Catalog ownership cost is reduced by 20% due to proper architecture.

What is included in SKU design work