Developing a product configurator on 1C-Bitrix

Development of Product Configurator for 1C-Bitrix

A product configurator is needed where there are no fixed SKUs — computers, windows, furniture, industrial equipment. The customer chooses parameters step by step, price and availability recalculate in real time, and a specific build goes into the cart. Built-in product offers (b_catalog_product_offer) handle a few dimensions, but with 5+ interdependent parameters — they break.

How the Configurator Works

The configurator is a client-server solution on top of Bitrix catalog. Frontend displays steps and updates interface; backend checks compatibility, calculates price, returns JSON.

Data storage. Two options:

• Use iblock with product offers and multidimensional properties. Works with up to ~10,000 combinations — b_iblock_element_property grows quadratically.
• Create custom compatibility tables. Suitable for complex matrices: each rule is written as separate record, indexes on parameter fields give fast lookup.

In practice: main product data — in iblock, compatibility rules — in separate table. Core class CIBlockElement is used for reading basic properties, REST handler — for checking configuration.

Configurator Steps and Dependencies

Each step is a set of options. Selection at step N limits available options at step N+1. Implemented via compatibility table:

CREATE TABLE custom_configurator_rules (
    id          SERIAL PRIMARY KEY,
    product_id  INT NOT NULL,
    param_key   VARCHAR(100) NOT NULL,
    param_value VARCHAR(255) NOT NULL,
    depends_key VARCHAR(100) NOT NULL,
    depends_val VARCHAR(255) NOT NULL,
    available   TINYINT DEFAULT 1
);
CREATE INDEX idx_rules_product ON custom_configurator_rules (product_id, param_key, param_value);

When user selects parameter value, AJAX request goes to /bitrix/services/main/ajax.php with configurator handler action. Handler reads rules table, returns available options for next step and current price.

Price Calculation

Configuration price is base product price plus markups for selected options. Stored in b_catalog_price (base prices) and separate markups table:

CREATE TABLE custom_configurator_price_mod (
    id          SERIAL PRIMARY KEY,
    product_id  INT NOT NULL,
    param_key   VARCHAR(100) NOT NULL,
    param_value VARCHAR(255) NOT NULL,
    price_mod   DECIMAL(12,2) NOT NULL,  -- absolute markup
    price_pct   DECIMAL(5,2)  DEFAULT 0  -- or percentage
);

Handler collects all selected options, sums markups, applies discounts via \Bitrix\Catalog\Discount\DiscountManager — and returns total to client.

Adding to Cart

When configuration is complete, a regular product offer (or product without offers) is added to cart, but JSON of selected configuration is attached to it as basket item custom property:

\Bitrix\Sale\Basket::create(SITE_ID);
$basketItem = $basket->createItem('catalog', $productId);
$basketItem->setFields([
    'QUANTITY' => 1,
    'PROPS'    => [
        ['NAME' => 'Configuration', 'CODE' => 'CONFIGURATION', 'VALUE' => json_encode($config)],
    ],
]);

Configuration is displayed in order card in admin area and goes into confirmation email via order_new template.

Integration with Stock

Configuration availability is checked via \Bitrix\Catalog\ProductTable and \Bitrix\Catalog\StoreProductTable. If one component is in stock, another is on order, configurator shows actual timeframe. Logic: take minimum balance among all configuration components.

Administrative Panel

A management interface is developed in /bitrix/admin/ for managing compatibility rules and markups. Use CAdminList, CAdminForm — standard Bitrix admin interface classes. This allows content managers to independently add new options without code changes.

Timeline

Total: 2.5–4 weeks depending on number of parameters and complexity of compatibility matrix.

What Affects Complexity

• Number of configurator dimensions (3 parameters vs 10).
• Presence of graphical preview (3D model, result image).
• Integration with 1C for actual stock.
• Mobile adaptation of multi-step UI.
• Need to save incomplete configurations for authorized users — via b_user_options or separate drafts table.