В мире e-commerce есть негласное правило: если вы продаёте товары с вариациями (размер, цвет, материал и т.д.), вы должны использовать торговые предложения. Это считается правильным, архитектурно верным, даже красивым решением. В Битриксе для этого есть мощный функционал SKU, в 1С — соответствующие механизмы выгрузки. Всё работает «из коробки». Всё должно быть хорошо... На словах...
Но так ли это на самом деле?
Когда мы взялись за реализацию на первый взгляд стандартной и простой задачи, о которой пойдёт речь, клиент уже прошёл через «стандартный» путь. И этот путь привёл его в тупик. Торговые предложения, вместо того чтобы упростить жизнь покупателям и менеджерам, создали хаос. Поиск не находил товары, фильтр выдавал пустые страницы, а 90% ассортимента просто не доходило до покупателя. Да, вы можете сказать, что Битрикс все предусмотрел, и это вопрос к разработчикам. Но! Не спешите делать выводы.
Мы решили пойти против течения и отказались от торговых предложений, переделали логику обмена с 1С и получили рост заказов в 1,3 раза. Вот как это было по этапам.
Часть 1. Торговые предложения - зло, о котором принято молчать
Что такое торговые предложения и зачем они нужны
Торговые предложения (SKU) в Битриксе - это типовой механизм, позволяющий группировать товары с общими характеристиками. Например, у вас есть определенная модель кроссовок. Она продаётся в пяти размерах и трёх цветах. Вместо того чтобы создавать 15 отдельных карточек товара, вы создаёте один родительский товар и 15 торговых предложений к нему. На словах звучит идеально и технически это красивое решение. База данных не захламляется, структура каталога остаётся стройной, а в админке товар выглядит компактно.
Почему это не работает на практике: три фатальных недостатка
Проблема первая: поиск слепнет
Это самая частая жалоба, которую можно встретить на форумах разработчиков Битрикса. Компонент «Поиск по каталогу» (bitrix:catalog.search) по умолчанию ищет только по родительским товарам, игнорируя торговые предложения. Покупатель вводит артикул конкретного размера — поиск выдаёт «ничего не найдено», хотя товар есть в базе.
Один из разработчиков так описывал ситуацию: «Поиск ищет не все товары... Ввожу в поиск артикул торгового предложения и 0 результатов». И это не единичный случай - проблема массовая, и штатными средствами она не решается. Приходится или переписывать логику поиска, или использовать сторонние модули.
Представьте себе магазин обуви, где покупатель ищет «кеды белые 42 размер». Поиск выдаёт «кеды» - и всё. А дальше нужно кликать на карточку, разворачивать список размеров, искать свой. Это минимум три лишних действия. Каждое лишнее действие — это потеря конверсии. Да еще все сейчас разбалованы ВБшкой и озоном и не хотят даже думать, а не то, чтобы клики лишние делать.
Да, вы сейчас скажете, что можно добавить поиск по торговым предложениям и будете правы. Но посмотрите на результат выдачи! Это же ужасно непонятно для пользователя, и очень часто всё равно отрабатывает криво.
Проблема вторая: фильтр врёт
Умный фильтр Битрикса - реально мощный инструмент. Но с торговыми предложениями он работает непредсказуемо. Покупатель ставит фильтр «размер 42» и «цвет белый». Система должна показать все подходящие товары. Вместо этого она часто показывает пустую выдачу или, наоборот, все товары без учёта фильтра.
Почему так происходит? Потому что фильтр работает с родительским элементом, а не с торговыми предложениями. Чтобы он «видел» размеры и цвета, нужно писать сложные подзапросы к инфоблоку предложений, использовать CIBlockElement::SubQuery . Это возможно, но требует квалифицированной доработки. Да и в этом случае при вводе, например "красного" цвета, покажется в каталоге главная карточка товара, где цвет может быть, к примеру, белым! И вы думаете, что это будет понятно человеку? Да никогда!
Проблема третья: пользовательский опыт страдает
Покупатель приходит на сайт не за изящными архитектурными решениями. Он приходит за товаром, который ему прямо сейчас необходим. И когда вместо чёткой карточки с конкретным размером и ценой он видит конструктор «выберите цвет, размер, материал», это вызывает раздражение, требует лишних действий на пустом месте.
Особенно если сайт -не гигантский маркетплейс, а магазин с относительно небольшим ассортиментом. Люди привыкли видеть конкретные товары, сравнивать их, добавлять в корзину одним кликом. Торговые предложения усложняют этот путь. И каждый шаг усложнения - это прощай, продажа.
Часть 2. История одного провала: как мы потеряли 12 000 товаров
Исходные данные: 12 000 позиций в 1С, а на сайте всего 1 000
Клиент пришёл к нам с типичной для производителей и дистрибьюторов проблемой. В 1С у него было более 12 000 единиц номенклатуры. Это была однотипная продукция - к примеру, расходные материалы для офисной техники. Много позиций, различающихся характеристиками: напряжение, мощность, совместимость с моделями принтеров и так далее. На сайте же отображалось только около 1 000 позиций. Остальные были «в 1С» — то есть существовали в учётной системе, но покупатели их не видели.
Почему стандартная выгрузка провалилась
При настройке обмена 1С → Битрикс мы пошли по стандартному пути. Создали торговые предложения, настроили выгрузку. Всё как в документации. И получили катастрофу из-за особенностей 1С и бизнес-процессов клиента.
Во-первых, многие товары не выгрузились вовсе. Списочные свойства (а это именно они — те самые значения, по которым потом должен работать фильтр) 1С передавала в формате, который Битрикс отказывался понимать. Во время импорта система либо пропускала эти свойства, либо записывала только первое значение из списка.
Во-вторых, из-за ошибок в интерпретации данных Битрикс создавал не те товары, которые были в 1С. Происходило «склеивание» или, наоборот, дублирование. Вместо 12 000 уникальных карточек появлялось 1 000 некорректных.
Часть 3. Как мы боролись и почему стандартные методы проиграли
Попытка №1: доработать 1С
Первая очевидная мысль - доработать обработку обмена на стороне 1С, чтобы она передавала данные в нужном формате. Технически это возможно: 1С использует CommerceML, структуру XML-файла можно расширять пользовательскими реквизитами.
Мы оценили этот вариант и отвергли его. Почему? Потому что:
- Это дорого. Правка обработки 1С требует специалиста по 1С, а это отдельный бюджет.
- Это долго. Каждая доработка тестируется, согласовывается с бухгалтерией и логистикой.
- Это негибко. Если формат выгрузки поменяется (а это происходит при обновлении конфигурации), всю работу придётся делать заново.
Мы сразу поняли: идти по пути доработки 1С - это кабала на годы вперёд. Клиент бы это не одобрил.
Попытка №2: подбирать типы свойств в Битриксе
Второй подход - «подогнать» Битрикс под 1С. Мы перебирали типы свойств в инфоблоке, пытаясь найти тот, в который 1С «впишется». Использовали строки, списки, справочники. Ничего не работало. 1С упорно передавала данные в своём формате, а Битрикс упорно их не понимал.
Эта борьба в целом длилась несколько недель. Мы пробовали даже создавать множественные свойства типа «список» — но и здесь нас ждал облом. Оказалось, что в ядре Битрикса есть баг: для множественных списочных свойств импорт корректно обрабатывает только первое значение из XML. Остальные просто отбрасываются.
Попытка №3: ловить события обновления
Следующий шаг - попытаться перехватить данные через штатные события Битрикса: OnAfterIBlockElementUpdate, OnAfterIBlockElementAdd и подобные. Идея была простой: после того как Битрикс загрузил товар из 1С, мы срабатываем на событие обновления и «дописываем» нужные нам свойства.
Увы, не сработало.
Оказалось, что при импорте через /bitrix/admin/1c_exchange.php многие события либо не вызываются вовсе, либо вызываются до того, как все данные записаны в базу. Особенно это стало заметно на новом ядре и при использовании новых методов обновления. Мы попадали в ситуацию, когда событие уже сработало, а свойства ещё не загрузились. Или наоборот — свойства загрузились, но событие не вызвалось.
Часть 4. Там, где родился план Б: как мы нашли «золотой ключик»
Почему мы решили работать с XML-файлом напрямую
Когда все стандартные методы провалились, мы сели и подумали: а что, если пойти в обход всей этой сложной машинерии? Наверняка же должен быть простой и логичный путь. 1С выгружает данные в XML-файл. Битрикс этот файл принимает и обрабатывает. В этом процессе есть момент, когда файл уже на сервере, но ещё не обработан. Это идеальная точка для вмешательства. Мы нашли событие, которое вызывается в момент получения XML-файла из обмена. Название события вы можете найти в документации. Оно гарантированно срабатывает и даёт нам доступ к исходному файлу с данными из 1С.
В этом обработчике мы:
- Получаем путь к XML-файлу (он передаётся в параметрах события).
- Парсим файл — читаем структуру, находим нужные узлы с характеристиками.
- Строим массивы данных — товары, свойства, значения. Проводим необходимые нам обработки
- Записываем эти массивы напрямую в инфоблок через CIBlockElement::SetPropertyValues.
Всё это происходит за один проход, без всяких костылей и обходных путей.
Что сделали (для технарей — кратко)
Мы создали массив "связок", в котором по определенному значению свойства объединялись товары. Далее определили товары по их кодам и обновили значение служебного свойства, которое не участвует в 1С обмене. При этом алгоритм учитывает, что файлов обмена может быть много, но все они - import.xml (в offers или rests мы не лезем, так как там нет нужных нам данных). Такой подход работает быстро, надёжно и не зависит от версии ядра Битрикса — мы работаем напрямую с данными.
Почему этот подход — самый правильный (наверное)
- Не зависит от версий. Нам не нужно переписывать код при обновлении Битрикса или 1С, потому что мы не цепляемся за их внутренние механизмы.
- Не требует правки 1С. Клиент сэкономил бюджет и время.
- Работает для любых свойств. Списочные, множественные, привязки — всё можно обработать.
- Прозрачно для пользователя. Мы не ломаем интерфейс, не создаём лишних сущностей.
Часть 5. Итоги: что мы получили и что значит рост в 1,3 раза
Цифры, которые говорят сами за себя
После внедрения новой логики:
- Каталог расширился с 1 000 до 12 000 позиций. На сайте появились все товары, которые было необходимо выгрузить из 1С. Ничего не потерялось, ничего не дублировалось.
- Фильтрация заработала как часы. Покупатели могут выбирать по любым характеристикам: от простых (цвет, размер) до сложных (мощность, материал, совместимость).
- Поиск перестал терять товары. Артикулы, названия, характеристики — всё индексируется и находится.
- Через месяц после запуска, когда вся база проиндексировалась, количество заказов выросло в 1,3 раза.
Последняя цифра — самая важная. Рост в 1,3 раза — это не случайность и не сезонный всплеск. Это прямое следствие того, что ассортимент стал видимым, а покупатели перестали натыкаться на пустые страницы и отсутствие нужного размера.
Что это значит для бизнеса в деньгах
Допустим, до внедрения магазин делал 50 заказов в сутки со средним чеком 3 000 рублей. Это 150 000 рублей выручки. После внедрения нашего решения стало приходить в среднем по 65 заказов в день. Это уже 195 000 рублей выручки. Плюс 45 000 рублей ежедневно. За месяц +1,3 млн За год - больше 15 миллионов дополнительной выручки. При этом затраты на доработку - разовые. Окупаемость такого проекта — обычно 1-2 недели на таком объеме.
Дополнительный бонус: команда выдохнула
Мы забыли упомянуть важный момент. До внедрения менеджеры клиента тратили часы на ручную правку каталога. Товары не выгружались — нужно было заходить в админку, искать, исправлять, дописывать свойства. После того как мы наладили автоматическую выгрузку через обработку XML, эта работа ушла. Менеджеры перестали править каталог и занялись продажами. А это — ещё один фактор роста.
Часть 6. Почему не стоит бояться нестандартных решений
Когда стандарт работает против бизнеса
В Битриксе и 1С заложено много действительно правильных архитектурных решений. Торговые предложения — одно из них. Но это решение подходит не всем.
Если у вас:
- небольшой ассортимент с простыми характеристиками,
- или, наоборот, огромный однотипный каталог,
- если ваши покупатели привыкли видеть конкретные товары, а не конструкторы,
то стандартный подход может навредить.
В нашем случае мы осознанно отказались от торговых предложений. Да, это было нестандартно. Да, это потребовало дополнительной разработки. Но это принесло результат.
Главный урок: слушаем бизнес, а не документацию
Когда мы начинали решать задачу, мы тоже попытались сделать «как правильно». И провалились. Мы потратили недели на то, чтобы подогнать 1С под Битрикс, перебирали типы свойств, ловили события — и ничего не работало. Только когда мы отбросили документацию и посмотрели на проблему с точки зрения бизнеса («нам нужно, чтобы все товары были на сайте, и покупатели их находили»), мы нашли правильное решение. Этот опыт — главное, что мы вынесли из проекта. Документация — это хорошо. Но бизнес клиента и его конечная цель куда важнее.
Как повторить этот успех у себя
Если вы узнали свою ситуацию:
- огромный каталог в 1С,
- проблемы с фильтрацией и поиском,
- потеря ассортимента при выгрузке,
- ручная правка товаров менеджерами,
то наш опыт — это готовая дорожная карта.
Мы не чиним 1С. Мы не ломаем Битрикс. Мы находим точку, где данные ещё не испорчены, и обрабатываем их так, как нужно бизнесу. Свяжитесь с нами. Мы покажем, как ваш каталог может приносить на 30% больше заказов уже через месяц после доработки.
P.S. В статье мы намеренно опустили технические детали реализации, потому что они не важны для принятия бизнес-решения. Если вам интересен технический разбор - мы можем провести отдельную консультацию для вашего технического директора или команды разработки.
