Как настроить интеграцию 1С с сайтом на Битрикс

Обмен всегда запускает 1С, а не сайт: она стучится на служебную страницу Битрикса, авторизуется и пошагово отдает данные. Технический директор Design Lab разбирает настройку по шагам с обеих сторон: что подготовить в 1С, как устроен сеанс обмена, что ломается чаще всего и когда штатного CommerceML перестает хватать.

Обмен всегда начинает 1С, сайт только отвечает

Короткий ответ для тех, кто пришел за инструкцией. Интеграция настраивается в 2 местах: на сайте это раздел «Магазин → Настройки → Интеграция с 1С», в 1С — узел обмена в плане «Узлы обмена с сайтами». Инициатором всегда выступает 1С: она обращается к служебной странице /bitrix/admin/1c_exchange.php, авторизуется под отдельным пользователем сайта и пошагово передает данные. Сайт сам в 1С не стучится и ничего не запрашивает.

Понимание этой асимметрии экономит недели споров. Когда товар не появился на сайте, причина почти всегда в выгрузке: она до сайта не доехала или доехала пустой. Сайт в этот момент вообще ничего не знал о том, что должен был получить новые данные.

Механизм под капотом называется CommerceML — открытый стандарт обмена коммерческой информацией в формате XML, разработанный 1С. Сам протокол взаимодействия с сайтом, поверх которого работает CommerceML, 1С делала совместно с 1С-Битриксом, и он тоже открытый: описание опубликовано на сайте 1С. Именно поэтому по этому протоколу с 1С умеют обмениваться не только продукты Битрикса.

Что и куда передается

Прежде чем что-то настраивать, полезно понять состав обмена. Обмен состоит из нескольких независимых потоков, и каждый включается отдельно.

Из этой таблицы следует практический вывод. Фраза «нам нужна интеграция с 1С» ничего не значит до тех пор, пока вы не назвали конкретные потоки. Магазину техники нужны все 6 строк, а корпоративному сайту с прайсом хватает первых 2 — и это 2 совершенно разных проекта по срокам.

Что проверить до того, как что-то настраивать

3 вещи, без которых дальше идти бессмысленно.

• Редакция «1С-Битрикс: Управление сайтом». Штатный обмен по CommerceML живет в модулях торгового каталога и интернет-магазина, а они входят в редакции начиная с «Малого бизнеса». Документация 1С-Битрикса помечает уроки по интеграции как недоступные в «Старте» и «Стандарте». Посмотреть свою редакцию можно на странице Marketplace → «Обновление платформы», а различия лицензий мы разбирали в материале про выбор редакции 1С-Битрикс.
• Версия модуля обмена. Она привязана к редакции конфигурации 1С: модуль 8.1.х работает с «1С:УТ» 11.5, модуль 7.х — с более ранними редакциями и требует модуль «Интернет-магазин» на сайте не ниже 17.0.1. Для «1С:Розница» и «1С:УНФ» свои сборки модуля. Ставить «какую-нибудь свежую» версию нельзя: несовместимость проявится уже на середине первого большого обмена.
• Отдельный пользователь сайта под обмен. Заведите специальную учетную запись и включите ее в группу, которой разрешена загрузка каталога и выгрузка заказов. Логин администратора тоже сработает, если группа «Администраторы» отмечена в этих настройках, но это плохая практика: пароль от админки уедет в настройки 1С на компьютере бухгалтера, а оттуда — в бэкапы базы 1С и в переписку с подрядчиком.

Еще до настройки решите, что считается источником истины. Если цены и остатки ведутся в 1С, менеджер не должен править их в админке сайта: следующая выгрузка все перезапишет. Договоритесь об этом на берегу и запишите в регламент, иначе получите вечный конфликт 2 систем и регулярные вопросы «кто опять поменял цену».

Подготовка данных в 1С: скучный этап, который решает все

Обмен не чинит бардак в учете, он его публикует. Поэтому до первой выгрузки проверьте в 1С 4 вещи.

1. Виды номенклатуры. В базе должны существовать виды «Товар» и «Услуга». Для обмена они критичны: без них 1С не сможет ни выгрузить номенклатуру, ни принять заказ, и вы получите ошибку «Не удалось найти вид номенклатуры».
2. Единицы измерения. У каждой позиции должна быть базовая единица с корректным кодом. Именно она уезжает в XML и на сайте определяет, как считается количество в корзине.
3. Соглашения и типы цен. В настройках выгрузки указывается конкретное соглашение, по которому берутся цены. Если этого не сделать, наверх летят все типы цен разом, и на редакции «Малый бизнес» это заканчивается ошибкой импорта метаданных: больше 1 типа цены она не поддерживает.
4. Названия свойств. Первым знаком в названии свойства должна быть буква. Свойство вроде «2-й размер» ломает импорт метаданных целиком, а сообщение об ошибке при этом никак не указывает на виновника.

Отдельный вопрос — структура каталога. В 1С номенклатура почти всегда сгруппирована так, как удобно бухгалтерии; покупателю эта раскладка ничего не объясняет. Тащить эту структуру на витрину не нужно, для расхождения есть 2 штатных пути, и оба описаны ниже, в разделе про частые вопросы.

В Design Lab ревизия справочников — обязательный первый этап любого проекта интеграции, и не потому, что так красивее: без нее нельзя оценить сроки. Пройти этот этап дешевле до старта. Расчистка справочников в работающей базе — это согласования с бухгалтерией и остановка выгрузок, а расчистка до первого обмена — просто задача на несколько дней.

Шаг 1. Настройки на стороне сайта

Идем в «Магазин → Настройки → Интеграция с 1С». Форма разбита на закладки, и у каждой своя зона ответственности: «Каталог» — прием товаров, «Экспорт каталога» — выгрузка товаров с сайта в 1С, «Заказы» — обмен документами, «Профили обмена» — соответствие полей заказа.

Закладка «Каталог»

Значения по умолчанию подходят большинству магазинов, но 4 пункта нужно осмыслить.

1. Тип инфоблока. Указываете, куда выгружать товары. Если на сайте уже есть инфоблок с совпадающим идентификатором, товары могут уехать не туда. Чтобы этого не случилось, включите «При выгрузке учитывать тип инфоблока» в расширенных настройках.
2. Разрешить загрузку группам пользователей. Здесь отмечается группа технического пользователя. Та же логика на закладке «Заказы», в поле «Группы, пользователям которых разрешена выгрузка». Если пользователь не входит ни в одну отмеченную группу, обмен упрется в отказ авторизации, хотя логин и пароль верные.
3. Торговые предложения в отдельный инфоблок. Если у товаров есть характеристики (размер, цвет, объем), опцию нужно включить обязательно, иначе предложения просто не выгрузятся. Если характеристик нет, включать не надо.
4. Что делать с товарами, отсутствующими в файле импорта. Здесь подвох: если обмен идет через модуль обмена 1С-Битрикса, настройка игнорируется. Работает только флаг «Деактивировать товары и разделы, не попавшие в полную выгрузку» на стороне 1С, и удалять товары в таком режиме система не умеет — только деактивировать.

Про последний пункт стоит сказать отдельно, потому что на нем горят каталоги. Связка «полная выгрузка + деактивация непопавших» означает: все, что по любой причине не попало в файл обмена, на сайте гаснет. Один неверно настроенный отбор в 1С — и витрина пустеет за один сеанс. Поэтому первые полные выгрузки делают с выключенной деактивацией, а включают ее только когда отборы проверены.

Расширенные настройки

Здесь живут 2 переключателя, которые сильнее всего влияют на скорость.

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

Второй — тегированный кеш инфоблока. Сброс «после каждой операции» самый честный и самый тяжелый: кеш слетает после каждого измененного товара, сайт в момент обмена заметно тормозит. Вариант «не сбрасывать» опасен по-другому: информация на витрине просто не обновится, хотя обмен отчитается об успехе. Для большинства проектов разумный компромисс — сброс после окончания импорта.

Тут же настраивается генерация картинки анонса и детальной картинки. Смысл в том, чтобы сайт сам приводил изображения к нужным размерам. Без этого из 1С приезжают неподготовленные фотографии по несколько мегабайт, и дальше они грузятся у каждого посетителя витрины.

Закладка «Заказы»

Здесь задается, какие заказы уходят в 1С и что происходит с ними дальше. Полезные параметры:

• Отбор заказов. Можно выгружать только оплаченные, только с разрешенной доставкой или начиная с определенного статуса. Удобно, когда в 1С не нужны корзины-полуфабрикаты и брошенные заказы.
• Менять статусы заказов по информации из 1С. Включает автоматическую смену статуса на сайте, когда из учета пришли данные об оплате или отгрузке.
• Создавать новые заказы и контрагентов из 1С. Обратный сценарий: заказ оформлен по телефону, заведен в 1С и приезжает на сайт, чтобы клиент видел его в личном кабинете.
• Многосайтовость. Заказы можно собирать со всех сайтов в одну базу 1С или, наоборот, разводить заказы разных сайтов по разным учетным системам.

На закладке «Профили обмена» для каждого типа плательщика настраивается соответствие полей: что на сайте считается фамилией, названием компании, ИНН, адресом. Это место выглядит формальностью ровно до первого обмена заказами. Если поля «Наименование» и «Полное наименование» не заполнены, 1С не сможет идентифицировать контрагента и отвалится с ошибкой «Поле объекта не обнаружено».

Шаг 2. Узел обмена в 1С

На стороне 1С создается узел обмена с сайтом. В нем задаются:

• Адрес сайта. Полный путь до /bitrix/admin/1c_exchange.php. Если обменов несколько и с разными настройками, вместо штатной страницы указывают собственные страницы с компонентом catalog.import.1c.
• Имя пользователя и пароль. Учетные данные технического пользователя. Рядом есть кнопка «Проверить соединение» — нажмите ее до первого обмена.
• Режим обмена данных. 4 независимых блока: выгрузка номенклатуры, выгрузка справочников в highload-блоки, обмен документами и выгрузка контрагентов. Каждый включается своим флажком.
• Контроль изменений. «Полная выгрузка» отдает все, что проходит по отбору, «Только изменения» — то, что поменялось с прошлого раза. Второй режим существенно быстрее и в рабочем режиме используется почти всегда.
• Расписание. Опция «Использовать периодический обмен данными» открывает форму с временем начала, окончания и периодичностью. Для файловой и клиент-серверной базы настройка немного отличается.
• Поведение при сбоях. Задается число повторов при неудачно отправленных пакетах и тайм-аут между попытками. На нестабильном канале это спасает обмен от падения из-за одного потерянного пакета.
• Каталог логов. Путь к папке, куда складываются файлы обмена и отчеты по дням, в подпапку reports.

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

Обратите внимание на кнопку «Принудительная выгрузка картинок». Изображения уезжают из 1С только при первой полной выгрузке, дальше — лишь новые и измененные. Если в первый раз картинки не доехали, обычным обменом вы их не догоните, и на витрине останутся товары без фотографий.

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

Как выглядит один сеанс обмена изнутри

Знать последовательность полезно: по тому, на каком шаге все встало, видно, куда смотреть.

Пара деталей, которые объясняют половину странного поведения. Cookie, выданная на первом шаге, дальше передается во всех запросах: если сессия на сервере протухла или сменила идентификатор, 1С об этом не узнает и начнет импорт заново. А размер файла из второго шага не рекомендация: если выгрузка больше лимита, 1С сама режет ее на куски, и на сайт приезжает несколько фрагментов вместо одного файла.

Заказы ходят в обратную сторону тем же механизмом с параметром type=sale: 1С запрашивает у сайта накопленные заказы, забирает их и подтверждает получение. Если на любом шаге что-то пошло не так, первой строкой ответа приходит слово failure и описание ошибки. А вот когда вместо текста прилетает HTML-код, значит, упало ядро или SQL-запрос, и разбираться нужно в логах сервера: настройки обмена тут уже ни при чем.

Что ломается чаще всего

По оценке самого 1С-Битрикса, около 70% обращений в техподдержку по обмену закрываются одним чек-листом настроек. Вот ошибки, которые встречаются постоянно.

Отдельная история, которая выглядит мистикой. Развернули копию базы 1С, обмен идет, но изменения с сайта в основную базу не приходят. Заказы уезжают в копию: она авторизуется теми же учетными данными и забирает их первой, а сайт честно отдает данные тому, кто пришел. Лечится сменой пароля у пользователя обмена, после чего копия отваливается. Правило на будущее: у тестового контура должны быть свои учетные данные и свой сайт, иначе тест будет воровать боевые заказы.

Скажу как технический директор: почти все перечисленные проблемы находятся не в коде, а в настройках и в дисциплине. Когда мы в Design Lab берем на поддержку магазин со сломанным обменом, разбор чаще всего сводится к внимательному чтению лога 1С и настроек узла. Разработка требуется редко.

Как не уронить сайт обменом

Полная выгрузка каталога на десятки тысяч позиций способна положить сайт в разгар рабочего дня. Что помогает:

• Ночное расписание для полных выгрузок. Днем гоняйте только цены и остатки — это отдельный, гораздо более легкий тип выгрузки, его можно запускать хоть каждые полчаса.
• Режим «Только изменения» и контрольные суммы. Первое сокращает объем передаваемых данных, второе — число операций записи в базу сайта.
• Отключение индексации инфоблока. Индексация элементов, разделов и свойств заметно замедляет импорт. На время большой выгрузки ее выключают, потом переиндексируют разом.
• Разумный сброс тегированного кеша. Сброс после каждой операции во время большого обмена означает, что сайт все это время работает без кеша.
• Логи обмена. В узле обмена задается каталог лога, файлы складываются по дням в подпапку reports. Без них разбор аварии превращается в гадание.
• Проверка витрины после обмена. Обмен может отработать «успешно» и ничего не обновить, например при выключенном сбросе тегированного кеша. Смотреть надо на сайт: строчка в журнале ничего не гарантирует.

И про обновления. Модуль обмена и модуль интернет-магазина связаны версиями, поэтому обмен ломается после обновлений чаще, чем в любой другой день. Разумный порядок такой: сначала обновление на копии, потом проверка тестового обмена, и только потом боевой контур. У нас есть отдельный разбор про обновление 1С-Битрикс и материал о поддержке сайта на 1С-Битрикс.

Безопасность обмена

Служебная страница обмена — это точка входа в сайт с правами на изменение каталога и чтение заказов. К ней стоит относиться соответственно.

• Только HTTPS. Логин и пароль передаются в заголовке каждого запроса. По HTTP это открытый текст в канале между офисом и сервером.
• Минимальные права. Технический пользователь должен уметь ровно 2 вещи: принимать каталог и отдавать заказы. Ни доступа в админку, ни прав на пользователей и настройки.
• Свой пароль на каждый контур. Боевая база, тестовая база и база подрядчика не должны ходить на сайт под одной учетной записью.
• Ограничение по IP, если офис статичный. Доступ к странице обмена закрывается на уровне веб-сервера, и это самая дешевая защита из возможных.
• Смена пароля при смене подрядчика. Пароль обмена хранится в настройках 1С в открытом виде и уходит вместе с копией базы.

Еще один аргумент за отдельного пользователя: в логах видно, кто и когда выполнял обмен. Когда все ходит под администратором, разобраться, что именно сломало каталог во вторник вечером, невозможно.

Когда штатного обмена не хватает

Штатный CommerceML закрывает типовой сценарий: каталог из учета, заказы обратно. Дальше начинаются задачи, где механизм нужно расширять. 3 уровня по возрастанию стоимости.

Уровень первый: несколько страниц обмена. Если каталоги нужно разложить по разным типам инфоблоков, создаются отдельные страницы с компонентом catalog.import.1c, каждая со своими параметрами, а в 1С заводится несколько узлов обмена с разными адресами. Это настройка, программировать ничего не нужно.

Уровень второй: обработчики событий. У импорта есть события до и после обработки файла обмена. В них удобно навешивать логику, которой в стандарте нет: проставить признак, пересчитать поле, дописать свойство, уведомить менеджера о новых позициях. Код небольшой, но это уже сопровождаемая доработка.

Уровень третий: собственная страница обмена или REST. Штатную страницу копируют и правят под проект, когда нужно вмешаться в сам разбор данных. А если бизнесу нужна не пакетная выгрузка по расписанию, а обмен по событию (списали остаток — обновили карточку через секунду), CommerceML для этого просто не предназначен: тут делают интеграцию поверх REST, и это отдельный проект со своими сроками и бюджетом.

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

С чего начать

Начните не с настроек, а с ревизии данных в 1С: виды номенклатуры, единицы измерения, соглашения с ценами, названия свойств. При чистых данных настройка обеих сторон — работа на день. При грязных это месяц переписки между бухгалтером и разработчиком, где каждый уверен, что проблема на другой стороне.

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

Если обмен уже настроен и периодически отваливается, соберите 3 вещи перед разговором с подрядчиком: лог обмена из 1С за день аварии, скриншот настроек узла и точный текст ошибки. С этим набором причина находится в разы быстрее, чем по описанию «у нас не грузятся товары».