Как мы перехитрили 1С и Битрикс и подняли продажи в 1,3 раза? Секрет в обычных товарах — узнайте и примените сейчас.

Кейс: 12 000 товаров в 1С, а на сайте — только 1 000. Торговые предложения убивали поиск и фильтр. Мы переписали логику обмена, и заказы выросли в 1,3 раза.

В e-commerce существует архитектурный шаблон: если вы продаёте товары с вариациями (размер, цвет, материал), логично использовать торговые предложения. В связке 1С и «1С-Битрикс» для этого есть готовые механизмы. На первый взгляд, это правильное и красивое решение. Но так ли оно эффективно на практике?

Мы столкнулись с кейсом, который заставил нас пересмотреть этот подход. Клиент — производитель с каталогом более 12 000 позиций в 1С. На сайте отображалось лишь около 1 000. Остальные позиции были «в учётке», но покупатели их не видели.

Стандартный путь — настройка выгрузки через торговые предложения — привёл к коллапсу. Поиск перестал находить товары, фильтр выдавал пустые страницы, менеджеры тратили часы на ручную правку каталога.

Мы отказались от торговых предложений, пересобрали логику обмена и получили рост заказов в 1,3 раза спустя месяц после индексации. Рассказываю по шагам, как это было.

Торговые предложения (SKU) — механизм группировки товаров с общими характеристиками. Например, модель кроссовок в пяти размерах и трёх цветах вместо 15 отдельных карточек получает одного родителя и 15 вариаций. Технически — элегантно. База не захламляется, структура стройная.

Но есть нюансы, о которых принято умалчивать.

1. Поиск теряет товары

Компонент bitrix:catalog.search по умолчанию ищет только по родительским элементам. Покупатель вводит артикул конкретного размера — поиск выдаёт «ничего не найдено», хотя товар есть в базе.

Форумы разработчиков пестрят жалобами. Проблема массовая, и штатными средствами не решается. Можно переписать логику поиска или использовать сторонние модули, но это дополнительные затраты.

Представьте: покупатель ищет «кеды белые 42 размер». Поиск выдаёт просто «кеды». Дальше — клик на карточку, разворот списка размеров, поиск своего. Минимум три лишних действия. Каждое — потеря конверсии. Особенно в эпоху Wildberries и Ozon, где пользователь привык получать конкретный товар в один клик.

Даже если доработать поиск под торговые предложения, выдача часто остаётся неудобной и запутанной.

2. Фильтр работает непредсказуемо

«Умный фильтр» Битрикса — мощный инструмент. Но с торговыми предложениями он часто даёт сбои. Покупатель ставит фильтр «размер 42» и «цвет белый» — система показывает пустую страницу или все товары без учёта фильтра.

Причина: фильтр оперирует родительским элементом, а не торговыми предложениями. Чтобы он «видел» размеры и цвета, требуются сложные подзапросы с CIBlockElement::SubQuery.

И даже после доработок остаются артефакты. Например, при выборе «красного» цвета в выдаче появляется карточка товара, где на главном изображении — белый цвет. Пользователь дезориентирован.

3. Продажи падают

Покупатель приходит за конкретным товаром. Когда вместо чёткой карточки с ценой и размером он видит конструктор «выберите цвет, размер, материал» — это вызывает раздражение.

Для небольших и средних магазинов это критично. Покупатели привыкли видеть конкретные товары, сравнивать их, добавлять в корзину в один клик. Торговые предложения усложняют путь. Каждый лишний шаг — потерянная продажа.

К нам в Брейнфорс пришел клиент — производитель расходных материалов для офисной техники. В 1С — более 12 000 единиц номенклатуры. Однотипные товары, различающиеся характеристиками: напряжение, мощность, совместимость с моделями принтеров.

На сайте отображалось около 1 000 позиций. Остальные существовали в учётной системе, но покупатели их не видели.

Мы настроили обмен по стандартному сценарию: создали торговые предложения, выгрузили данные. Получили две проблемы:

Мы перепробовали три стандартных подхода. Ни один не сработал.

Изменить обработку обмена на стороне 1С, чтобы передавать данные в нужном формате. Технически возможно через расширение CommerceML.

Отказались по трём причинам:

Перебирали типы свойств в инфоблоке: строки, списки, справочники. Ничего не работало. 1С упорно передавала данные в своём формате, Битрикс — не понимал.

Обнаружился баг ядра: для множественных списочных свойств импорт обрабатывает только первое значение из XML. Остальные отбрасываются.

Пытались «дописать» свойства через OnAfterIBlockElementUpdate и OnAfterIBlockElementAdd.

Не сработало. При импорте через 1c_exchange.php многие события либо не вызываются, либо срабатывают до полной записи данных.

Когда стандартные методы провалились, мы пошли в обход.

1С выгружает данные в XML. Битрикс принимает и обрабатывает. Есть момент, когда XML уже на сервере, но ещё не обработан. Идеальная точка для вмешательства.

В дебрях документации мы нашли событие, вызываемое при получении XML-файла из обмена. Оно гарантированно срабатывает и даёт доступ к исходным данным.

Алгоритм:

Технический нюанс: мы создали массив связок, по определённому значению свойства объединяли товары и обновляли служебное свойство, не участвующее в обмене. Работаем только с import.xml — в offers и rests не лезем.

Почему это эффективно:

Исходные данные: 50 заказов в день, средний чек — 3 000 руб. = 150 000 руб. выручки в день.

После внедрения: ~65 заказов в день = ~195 000 руб.

Прирост: ~45 000 руб. в день = ~1,35 млн руб. в месяц = ~16,2 млн руб. в год.

Затраты на доработку — разовые. Окупаемость решения — 1–2 недели.

Менеджеры перестали тратить часы на ручную правку каталога. Освобождённое время ушло на продажи. Это ещё один фактор роста.

Торговые предложения — правильное архитектурное решение. Но далеко не для всех сценариев.

Если у вас:

то стандартный подход может навредить.

Когда мы начинали, мы тоже пытались сделать «как правильно». Потратили недели, перебирали свойства, ловили события. Ничего не работало.

Только когда мы отбросили документацию и посмотрели на проблему с точки зрения бизнеса («нам нужно, чтобы все товары были на сайте, и покупатели их находили»), мы нашли решение.

Документация — это хорошо. Но бизнес-цели клиента важнее архитектурной красоты.

Если у вас похожая ситуация:

то наш опыт — готовая дорожная карта.

Мы не чиним 1С и не ломаем Битрикс. Мы находим точку, где данные ещё не испорчены, и обрабатываем их так, как нужно бизнесу.

P.S. В статье опущены технические детали реализации, поскольку они не являются определяющими для бизнес-решения. Если вам интересен технический разбор — мы готовы провести отдельную консультацию.

Было полезно? Напишите в комментариях, сталкивались ли вы с похожей проблемой. Подпишитесь, чтобы не пропустить новые кейсы и лайфхаки по автоматизации e-commerce. Ну и можете подписаться на мой Телеграм канал, а можете и не подписываться, не обижусь! Честно :)