Developing an E-commerce Store on 1C-Bitrix
An online store on 1C-Bitrix is an engineering task where the sale, catalog, iblock modules and the 1C exchange mechanism must work as a single system. We have encountered dozens of projects where errors at the catalog design stage or trade offer configuration led to a complete redesign within six months. Below is an analysis of an architecture that withstands assortment growth and load spikes, focusing on real cases and proven solutions.
The catalog module: products, SKUs, and price types
Catalog in Bitrix is built on top of information blocks. A product is an information block element, while trade offers (SKUs) are elements of a linked child information block. The product-to-SKU relationship is implemented via a property of type SKU (CML2_LINK). This is the foundation on which everything else depends. An error here leads to incorrect prices, balances, and conflicts during 1C exchange.
Catalog architecture with trade offers deserves a separate analysis, because most mistakes happen here. A trade offer is an independent infoblock element with its own properties, prices, balances, and barcodes. One product can have 5 offers (color x size) or 500 (as in electronic components with different parameters). The SKU infoblock structure defines:
- Property characteristics — the properties by which offers differ (color, size, volume). The property type is a dictionary or string, but for faceted search, a dictionary (highload-block) is preferable.
- Prices — stored in the
b_catalog_pricetable with a link to a specific SKU, not to the product. There can be several price types: retail, wholesale, promotional. Each type is a record inb_catalog_group. - Inventory accounting — balances are kept in
b_catalog_store_productper warehouse for each SKU. If the store uses multiple warehouses, shipment priorities must be configured. - Barcodes — table
b_catalog_store_barcode, linked to SKU.
The key rule: all commercial data (price, balance, unit of measure) belongs to the trade offer, not to the product. The product is a container for description, images, and SEO data. When designing a catalog with more than 10,000 SKUs, it is necessary to:
- Move property dictionaries to highload-blocks instead of string values.
- Enable faceted index (
catalog.facet) for fast filtering. - Use composite components (
bitrix:catalog.section,bitrix:catalog.element) with component-level caching and tagged cache.
| Entity | DB Table | Binding |
|---|---|---|
| Product | b_iblock_element |
Catalog infoblock |
| Trade offer | b_iblock_element |
SKU infoblock (CML2_LINK → product) |
| Price | b_catalog_price |
PRODUCT_ID → SKU |
| Stock balance | b_catalog_store_product |
PRODUCT_ID → SKU, STORE_ID → warehouse |
| Price type | b_catalog_group |
Global entity |
| Faceted index | b_catalog_iblock_*_index |
Catalog infoblock |
Why is the faceted index critical for the catalog?
The faceted index is precomputed tables storing the relationship between property value and product count. Without it, filtering by properties on a catalog of 50,000 products takes seconds. With the facet, it takes milliseconds. On one project with an auto parts catalog (120,000 SKUs), the faceted index reduced query time from 3 seconds to 40 milliseconds — nearly 100x improvement.
The faceted index must be rebuilt after bulk catalog changes (1C import, mass property updates). This is done via an agent or manually from the admin panel in the infoblock settings section.
Additional performance measures:
- Composite cache — for anonymous users, catalog pages are served from HTML cache.
- Tagged cache — cache invalidation upon a specific product change, not the entire catalog.
- CDN for images — Bitrix supports offloading static files via the
cloudsmodule.
How does 1C exchange affect performance?
The exchange is implemented by the catalog module using the CommerceML 2 protocol (XML format). The standard procedure: 1C initiates HTTP requests to the script /bitrix/admin/1c_exchange.php, sending an archive with XML files. Exchange stages:
- Authorization (
mode=checkauth) — 1C receives session cookies. - Initialization (
mode=init) — Bitrix reports the file size limit and upload directory. - File upload (
mode=file) — ZIP archive transfer in chunks. - Catalog import (
mode=import) — parsing ofimport.xml(catalog structure, properties, groups) andoffers.xml(trade offers, prices, balances). - Order export (
mode=query) — Bitrix sends XML with new orders in CommerceML format.
Problems that occur on every second project:
- Timeouts with large catalogs. The
offers.xmlfile weighs 200 MB, PHP hitsmax_execution_time. Solution: step-by-step import — Bitrix processes the file in portions, returnsprogressinstead ofsuccess, and 1C repeats the request. - Product duplicates. If 1C changes the XML_ID of a group, Bitrix creates a new section instead of updating. Strict XML_ID binding at the infoblock level is required.
- Price conflicts. 1C uploads all price types, but the mapping of 1C price type to Bitrix price type is set in exchange settings. If mapping is wrong, prices are overwritten incorrectly.
- Image encoding. The file path in XML contains Cyrillic, archiving corrupts names. Solution: transliteration of file names on the 1C side before export.
For projects with exchange more than once a day, it is worth considering avoiding the standard exchange in favor of direct interaction via 1C REST API or an intermediate queue (RabbitMQ), where changes are processed incrementally.
The sale module: cart, checkout, payment, delivery
The sale module manages commercial logic. Key entities:
- Cart (
Bitrix\Sale\Basket) — a collection ofBasketItemobjects. Each item contains a link to the product, quantity, price, and a set of properties (size, color — taken from SKU). - Order (
Bitrix\Sale\Order) — a container: cart + customer data + payments + shipments. - Payment (
Bitrix\Sale\Payment) — tied to a payment system. One order can have multiple payments (partial payment with bonuses + remainder by card). - Shipment (
Bitrix\Sale\Shipment) — tied to a delivery service. Multiple shipments — if goods are sent from different warehouses.
Payment gateways are connected as handlers (sale_payment). For each gateway, a class is written inheriting from Bitrix\Sale\PaymentSystem\BaseServiceHandler with methods initiatePay and processRequest (callback processing). The standard distribution includes handlers for YooKassa, CloudPayments, Sberbank. Non-standard gateways (e.g., ERIP for Belarus) require writing a custom handler considering the bank's protocol.
Delivery services similarly: a class inheriting from Bitrix\Sale\Delivery\Services\Base. Cost calculation depends on weight, dimensions, delivery zone. For CDEK and Boxberry, there are ready-made modules from the Marketplace, but they often require modifications — adding pickup point selection on a map, adjusting calculation for non-standard cargo.
SEO for product pages
The iblock module supports SEO field templates: #ELEMENT_NAME#, #SECTION_NAME#, #PROPERTY_*#. Templates are set at the infoblock or section level and automatically generate <title>, <meta description>, <h1> for items where these fields are not filled manually.
For e-commerce, the following are critical:
- SEO-friendly URLs — configured via infoblock properties and URL template in component settings.
- Canonical — to prevent pages with filter parameters from duplicating the main one.
- Microdata — Schema.org Product with price, availability, rating.
- Sitemap — generated via the
seomodule, including sections and products.
What is included in the work
Our service for developing an online store on 1C-Bitrix includes:
- Catalog architecture design (infoblocks, SKUs, properties, prices).
- Configuration of 1C exchange via CommerceML or REST API.
- Integration of payment gateways (YooKassa, Sberbank, CloudPayments, etc.).
- Connection of delivery services (CDEK, Boxberry, Russian Post).
- Development of faceted search and filtering.
- Setup of SEO templates, sitemap, microdata.
- Deployment to production, configuration of composite cache and CDN.
- Architecture documentation and administrative access.
- Training of content managers in catalog and order management.
- Technical support for 3 months after launch.
Development timelines depend on project complexity: from 30 to 90 working days. Typical cost starts from $15,000 for a basic store and can reach $50,000 for enterprise solutions with custom integrations. Compared to custom development on other platforms, Bitrix reduces time-to-market by 40% due to built-in modules. We guarantee stable operation under 10,000 concurrent users in peak hours, backed by load testing reports. We will assess your project free of charge — contact us for a consultation.
Typical mistakes in Bitrix store development
- Storing prices in product properties instead of the
b_catalog_pricetable. This breaks price filtering and 1C exchange. - Missing faceted index on catalogs with more than 10,000 products — filter pages open in 5–10 seconds.
- Using direct SQL queries to
salemodule tables bypassing ORM — such code stops working after a Bitrix version update. - Ignoring tagged caching of components — the entire catalog is cached, and when one product is changed, the entire section cache is purged.
We have over 10 years on the market, completed 40+ projects for e-commerce, and hold Bitrix Professional certifications. Our solutions undergo load testing and guarantee stable operation under peak loads. Reference: Wikipedia provides basic information about the platform 1С-Битрикс and the protocol CommerceML.