Online store development using 1C-Bitrix

E-Commerce Development with 1C-Bitrix

An e-commerce store on 1C-Bitrix is not a template assembly, but an engineering task where the sale, catalog, iblock modules and the exchange mechanism with 1C must work as a unified system. Mistakes at the catalog design stage or trade offer configuration stage lead to the store needing a rebuild after six months. Below is a breakdown of architecture that scales with growing assortment and load.

catalog Module: Products, SKU and Price Types

The catalog in Bitrix is built on top of iblocks. A product is an iblock element, and trade offers (SKU) are elements of an attached child iblock. The "product → SKU" relationship is implemented via SKU type property (CML2_LINK). This is the foundation on which everything else depends.

Catalog architecture with trade offers deserves separate analysis because most mistakes happen here.

A trade offer is an independent iblock element with its own properties, prices, stock levels, and barcodes. One product can have 5 offers (color × size) or 500 (like electronic components with different parameters). The SKU iblock structure determines:

• Set of characteristic properties — properties by which offers differ (color, size, volume). Property type is either directory or string, but for faceted search, a directory is preferable (highload-block).
• Prices — stored in b_catalog_price table bound to specific SKU, not product. There can be several price types: retail, wholesale, promotional. Each type is a record in b_catalog_group.
• Stock management — stock is kept in b_catalog_store_product per warehouse for each SKU. For multi-warehouse stores, shipment priority configuration is needed.
• Barcodes — b_catalog_store_barcode table, bound to SKU.

Key rule: all commercial data (price, stock, unit of measure) belongs to the trade offer, not the product. The product is a container for description, photos, and SEO data.

When designing a catalog with more than 10,000 SKUs, you must:

1. Move property directories to highload-blocks instead of string values
2. Enable faceted indexing (catalog.facet) for fast filtering
3. Use composite components (bitrix:catalog.section, bitrix:catalog.element) with component-level caching and tagged cache

Exchange with 1C via CommerceML

Exchange is implemented by catalog module via CommerceML 2 protocol (XML format). The procedure is standard: 1C initiates HTTP requests to /bitrix/admin/1c_exchange.php script, passing a ZIP archive with XML files.

Exchange stages:

1. Authorization (mode=checkauth) — 1C receives session cookies
2. Initialization (mode=init) — Bitrix reports file size limit and upload directory
3. File upload (mode=file) — ZIP archive transmission in parts
4. Catalog import (mode=import) — parsing import.xml (catalog structure, properties, groups) and offers.xml (trade offers, prices, stock)
5. Order export (mode=query) — Bitrix returns XML with new orders in CommerceML format

Problems that arise in nearly every other project:

• Timeouts on large catalogs. offers.xml file weighs 200 MB, PHP crashes on max_execution_time. Solution — step-by-step import: Bitrix processes file in portions, returning progress instead of success, and 1C repeats the request.
• Duplicate products. If XML_ID group changes in 1C, Bitrix creates new section instead of updating. Strict XML_ID binding needed at iblock level.
• Price conflict. 1C exports all price types, but mapping 1C price type → Bitrix price type is set in exchange settings. If mapping breaks — prices are overwritten incorrectly.
• Image encoding. File path in XML contains Cyrillic, archiver breaks names. Solution — transliteration of filenames on 1C side before export.

For projects with exchange more than once a day, consider abandoning standard exchange in favor of direct interaction via 1C REST API or intermediate queue (RabbitMQ) where changes are processed incrementally.

sale Module: Cart, Checkout, Payment, Delivery

The sale module manages business logic. Key entities:

• Cart (Bitrix\Sale\Basket) — collection of BasketItem objects. Each element contains product reference, quantity, price, and property set (size, color — taken from SKU).
• Order (Bitrix\Sale\Order) — container: cart + buyer data + payments + shipments.
• Payment (Bitrix\Sale\Payment) — bound to payment system. One order can contain multiple payments (partial payment with bonuses + remainder by card).
• Shipment (Bitrix\Sale\Shipment) — bound to delivery service. Multiple shipments if products ship from different warehouses.

Payment gateways are connected as handlers (sale_payment). For each gateway, a class inheriting Bitrix\Sale\PaymentSystem\BaseServiceHandler is written with initiatePay and processRequest methods (callback processing). Standard distribution includes handlers for YooKassa, CloudPayments, Sber. Non-standard gateways (ERIP for Belarus, for example) require custom handler implementation according to bank protocol.

Delivery services likewise: class inheriting Bitrix\Sale\Delivery\Services\Base. Cost calculation depends on weight, dimensions, delivery zone. Ready modules exist for SDEK and Boxberry from Marketplace, but often need refinement — adding pickup point selection on map, adjusting calculation for non-standard cargo.

Faceted Search and Catalog Performance

Faceted index is pre-calculated tables storing "property value → product count" relationships. Without it, filtering by properties on 50,000 product catalog takes seconds. With facet — milliseconds.

Faceted index needs to be recreated after bulk catalog changes (import from 1C, mass property updates). This is done via agent or manually from admin panel in iblock settings section.

Additional performance measures:

• Composite cache — catalog pages for anonymous users served from HTML cache
• Tagged cache — invalidate cache when specific product changes, not entire catalog
• CDN for images — Bitrix supports offloading static to external storage via clouds module

SEO for Product Pages

The iblock module supports SEO template fields: #ELEMENT_NAME#, #SECTION_NAME#, #PROPERTY_*#. Templates are set at iblock or section level and automatically generate <title>, <meta description>, <h1> for products without these fields filled manually.

For e-commerce, critical:

• URLs — configuration via iblock properties and URL template in component settings
• canonical — so filter parameter pages don't duplicate main page
• Microdata — Schema.org Product with price, availability, rating
• sitemap — generation via seo module with sections and products included

A well-designed e-commerce store on Bitrix is not just "installed the box and uploaded products". It's a thoughtful catalog architecture, reliable exchange with accounting system, and business logic accounting for business specifics.