Product Configurator: Eliminate Thousands of SKUs in 1C-Bitrix
We often encounter the situation: a client sells custom furniture, and each sofa can be assembled from dozens of fabric options, legs, and fillings. The standard Bitrix trade offers (SKUs) — see SKU on Wikipedia — force you to create all combinations manually. 5 materials × 8 colors × 3 sizes = 120 SKUs. And if you add a dependency: a leather sofa cannot be combined with velour pillows — SKUs explode into thousands. The configurator solves this problem fundamentally differently, saving up to 80% of time on catalog administration.
Why a configurator module if trade offers exist?
SKUs are fine for simple combinations of 2–3 characteristics. When the number of options exceeds 4 or dependencies appear, it's better to use a custom configurator. It stores options independently and calculates the final price and composition dynamically, as described in Bitrix documentation for information blocks. Our vendor.configurator module implements a full-fledged data model with support for dependencies and formula-based price modifiers.
How a configurator differs from SKU
With SKUs, all possible combinations are pre-listed. If a laptop has 3 processor options, 4 RAM options, and 3 SSD options — you need 36 SKUs, all of which must be created and maintained. In a configurator, options are set independently, and the final price and composition are calculated dynamically. This is a fundamentally different data model, saving up to 80% of time on catalog maintenance.
How option dependencies work
The most complex part of a configurator is dependencies. When selecting "High-power power supply," more powerful graphics cards become automatically available. Here's an implementation example in PHP using Bitrix ORM:
class DependencyResolver { public function resolve(int $productId, array $selectedOptions): DependencyResult { $dependencies = DependencyTable::getList([ 'filter' => ['OPTION_ID' => $selectedOptions], ])->fetchAll(); $visible = []; $hidden = []; $required = []; $disabled = []; foreach ($dependencies as $dep) { match ($dep['ACTION']) { 'show' => $visible[] = $dep['DEPENDENT_OPTION_ID'], 'hide' => $hidden[] = $dep['DEPENDENT_OPTION_ID'], 'require' => $required[] = $dep['DEPENDENT_OPTION_ID'], 'disable' => $disabled[] = $dep['DEPENDENT_OPTION_ID'], }; } return new DependencyResult($visible, $hidden, $required, $disabled); } } The result is passed to the frontend via AJAX with each selection change. Thanks to tagged caching, the price is recalculated instantly without a full page reload.
Why a configurator saves time
The vendor.configurator module includes ORM tables: b_vendor_cfg_product, b_vendor_cfg_group, b_vendor_cfg_option, b_vendor_cfg_dependency, b_vendor_cfg_configuration, b_vendor_cfg_order_item. The administrator only needs to set groups and options once, rather than creating thousands of SKUs. Dependencies are configured visually in the constructor.
How dynamic price calculation works
Base price + option modifiers. Fixed surcharges, percentages, and arbitrary formulas are supported:
class PriceCalculator { public function calculate(int $productId, array $selectedOptionIds): float { $product = ProductTable::getById($productId)->fetch(); $price = (float)$product['BASE_PRICE']; $options = OptionTable::getList([ 'filter' => ['ID' => $selectedOptionIds], ])->fetchAll(); foreach ($options as $option) { $price = match ($option['PRICE_MOD_TYPE']) { 'fixed' => $price + (float)$option['PRICE_MOD_VALUE'], 'percent' => $price * (1 + (float)$option['PRICE_MOD_VALUE'] / 100), 'formula' => $this->evalFormula($option['PRICE_MOD_VALUE'], $price), default => $price, }; } return round($price, 2); } } The formula modifier allows non-linear dependencies: for example, the price of a custom size is calculated by area (width × height × base rate per sq.m.). This is especially relevant for window structures or custom furniture.
Configurator frontend
The configurator interface is a React/Vue component attached to the product page. Logic:
- Loads the structure of groups and options via a REST endpoint.
- On selection change — AJAX to
DependencyResolver, updates option visibility. - Simultaneous AJAX to
PriceCalculator, updates the total price. - Visual options (color, material) — a grid of previews with click.
Configuration state is synchronized with the URL hash — the configuration can be copied and shared as a link. Clients can save multiple configurations and compare them.
Adding to cart
The saved configuration is added to the cart as a single item. Configuration details are stored in b_vendor_cfg_configuration.options, linked to the cart item via b_vendor_cfg_order_item. When viewing an order, the user and manager see the details: which options were chosen. This simplifies order processing and eliminates picking errors.
Admin interface
- Configurator constructor: drag-and-drop groups and options.
- Dependency setup via visual editor (list of rules).
- Preview of the configurator directly in the admin panel.
- List of user-saved configurations.
- Statistics: popular configurations, average check for configurator (increase up to 40%).
Our certified specialists with 10+ years of experience implement such modules "turnkey." We guarantee stable operation under high loads — up to 10,000 concurrent configuration sessions. Order a configurator module development and get a flexible tool for your business.
What's included in the work
As part of the project, we provide:
- Technical specification and API documentation.
- Database migrations for existing products.
- Deployment on the production server.
- Code with comments and unit test coverage.
- Administrator training on the constructor.
- 3-month warranty support.
Contact us for a project evaluation — just describe your products and their characteristics. We will estimate within 1 day.
Comparison of SKU and Configurator
| Criteria | Trade Offers (SKU) | Custom Configurator |
|---|---|---|
| Number of combinations | N×M (created manually) | Arbitrary (dynamic calculation) |
| Option dependencies | Not supported | Supported (show/hide/require/disable) |
| Price modifiers | Only fixed surcharge | Fixed, percentages, formulas |
| Administration time | High (thousands of SKUs) | Low (dozens of options) |
| Customer flexibility | Low | High (customization) |
Development timeline
| Stage | Timeline |
|---|---|
| ORM tables, product and option model | 1 day |
| Dependency resolver, API | 2 days |
| Price calculator, formula modifiers | 2 days |
| Frontend component (React/Vue) | 3 days |
| Adding to cart, order details | 2 days |
| Admin constructor | 2 days |
| Testing | 1 day |
Total: 13 working days. 3D visualization of the configuration (WebGL) is a separate project. Get a consultation on the configurator — we will help choose the optimal solution for your catalog.

