Trade Offer (SKU) Design for 1C-Bitrix
Trade offers in Bitrix are a mechanism that allows a single product to have multiple variants with different prices, stock levels, and attributes. It sounds straightforward, but implementing this mechanism raises more practical questions than any other part of the catalog. How do you split properties between the product and the offer? How do you correctly configure filtering by SKU attributes? Why do offers get duplicated after setting up the 1C sync? The answers lie in the architectural decisions made during design.
Technical SKU Schema in Bitrix
A trade offer in Bitrix is an element in a separate iblock, linked to the parent product in the main catalog iblock. In the database:
-
b_iblock_element— product in the main iblock (parent, typeTYPE_PRODUCT) -
b_iblock_element— offer in the offers iblock (typeTYPE_OFFER) -
b_catalog_product.OWNER_ID— link from the offer to the parent product -
b_catalog_price— price at the offer level -
b_catalog_store_amount— warehouse stock at the offer level
Configuring the link: Content → Catalog → [iblock] → Settings → Trade offers. Here you specify the offers iblock and the linking property (CML2_LINK or a custom "Element link" type property).
Splitting Properties: Product vs. Offer
The most critical design task. The rule: a property belongs to the offer if its value affects the price or stock, or if it is unique to a specific variant.
Examples:
- Product properties: name, description, brand, category, images, technical specifications (non-variable)
- Offer properties: color, size, volume, configuration, SKU code, barcode, variant image
The mistake — placing color and size in parent product properties: this makes it impossible to filter "blue dresses in size M," because those attributes are not linked to the stock and price of a specific variant.
The bitrix:catalog.element Component and SKU Display
The standard product card component bitrix:catalog.element supports trade offer display: switching variants, and dynamically updating price and image via AJAX request to CatalogElementComponent.getProductData. During design, it is important to understand that this component makes a separate request for offer data — so offers must be correctly structured and cached.
If a product has many offers (50+), the standard component can generate heavy queries. Solution: lazy loading of variants via REST, or enforcing a display limit with "show more."
Filtering by Offer Properties
The standard bitrix:catalog.smart.filter component can filter by offers iblock properties — the OFFER_IBLOCK_ID must be specified in the component settings. But the facet index is built separately for the offers iblock and the main iblock. For a color filter to show only products that have a variant in the required color, the facet must be enabled on the offers iblock specifically.
A complex case: filtering by a product property AND an offer property simultaneously. The standard facet does not support cross-iblock filtering out of the box — a custom filter component is required.
1C Sync and Trade Offers
In CommerceML 2, trade offers are transmitted in the ЗначенияРеквизитов section with a characteristic attribute. The standard Bitrix exchange can create and update offers from a 1C export. Critical points:
- The offer's XML-ID must be unique and stable between sync cycles
- If 1C changes characteristic identifiers, offers get duplicated instead of updated
- Offer images are transmitted separately from product images
During design, the XML-ID format for offers must be agreed with the 1C team before development begins.
Case Study: Furniture Store with 14,000 SKUs
A soft furniture store. 1,200 models, each in 8–20 fabric/color variants. 14,000 trade offers in total.
The problem after initial setup: the color filter worked incorrectly — it showed products with a color in the parent product property rather than in offers. The sofa "Marco" had the color "beige" in the product property, but the specific variants with that color were sold out.
Correct solution:
- Color and material moved to offers iblock properties
- Facet index configured on the offers iblock
- A check added to the section component: a product appears in filter results only if it has an offer with stock > 0 AND the required color
- Variant images in the offer property; model image in the parent product
After the migration: correct filtering, "out of stock" by specific variant without hiding the product entirely.
What SKU Design Work Includes
- Analyzing product variability: which attributes vary
- Designing the product/offer property split
- Configuring the iblock relationship (main + offers)
- Planning the facet index for the offers iblock
- CommerceML field mapping for correct 1C sync
- SKU display schema on the product card
- Testing filtering scenarios after setup
Timeline: 3–8 working days depending on variability complexity and filtering requirements.