Обмен Битрикс с 1С через штатный модуль 1С-Битрикс: Управление сайтом закрывает большую часть типовых задач - синхронизацию каталога, остатков, цен и заказов между интернет-магазином и учётной системой. Настраивал этот обмен на десятках проектов, от магазинов на 300 товаров до каталогов в 40 000+ SKU с несколькими складами, и почти в каждом втором случае натыкался на одни и те же грабли: неверные права доступа, забытые лимиты PHP на хостинге или кривые настройки CommerceML. В статье разберу, как модуль устроен изнутри, какие есть варианты настройки и на чём обмен обычно ломается.
Как устроен обмен Битрикс с 1С: протокол CommerceML
Обмен работает по протоколу CommerceML 2 - это XML-формат, который 1С и Битрикс понимают одинаково. С обеих сторон стоит одноимённый модуль: в 1С это внешняя обработка или встроенный механизм обмена с сайтом, в Битриксе - модуль «Интернет-магазин» (sale) с разделом «Обмен данными» в административной панели.
Данные идут в двух направлениях. Из 1С на сайт выгружается каталог: товары, разделы, свойства, цены, остатки по складам. С сайта в 1С уходят заказы, оформленные покупателями. У каждого направления свой набор XML-файлов и свой цикл обмена, их удобно настраивать раздельно, особенно если каталог большой и меняется редко, а заказы приходят каждые несколько минут.
Ключевой момент, который упускают на старте: обмен - это не разовая выгрузка, а регулярный процесс с состоянием. Если один цикл прервался на середине (оборвалось соединение, кончился лимит времени), при следующем запуске система должна понять, с какого места продолжать, а не начинать заново. Именно на этом чаще всего спотыкаются самодельные скрипты обмена, написанные без учёта протокола.
Настройка модуля 1С-Битрикс для обмена
Профиль обмена и права доступа
В административной панели Битрикса профиль обмена создаётся в разделе «Магазин» - «Настройки» - «Обмен данными». Для каждого профиля нужно завести отдельного пользователя с правами на обмен (не администратора сайта целиком, а именно роль для CommerceML), задать логин и пароль, которые потом пропишете в настройках 1С.
Частая ошибка на этом шаге - использовать для обмена основного администратора и потом сменить ему пароль в рамках плановой ротации доступов. Обмен молча падает с ошибкой авторизации, а разбираются с этим обычно через пару недель, когда на сайте перестают появляться заказы из 1С или каталог не обновляется.
Ограничения хостинга: timeout и объём памяти
Обмен большого каталога, особенно первая полная выгрузка, упирается в лимиты PHP: max_execution_time, memory_limit, post_max_size. На shared-хостинге с дефолтным execution_time в 30 секунд обмен каталога на 10 000+ товаров не успевает отработать за один запрос и обрывается без внятной ошибки в интерфейсе - только в логах.
Для сайтов с каталогом от нескольких тысяч позиций сразу закладываю отдельные лимиты для скрипта обмена (через .htaccess или php.ini конкретного пути), подбираю размер пачки обмена в настройках модуля так, чтобы одна итерация гарантированно укладывалась в отведённое время, и проверяю, что хостинг вообще позволяет менять эти параметры - на части бюджетных тарифов это заблокировано на уровне провайдера.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Прямой обмен по расписанию или обмен через файлы
Есть два принципиально разных способа гонять данные между 1С и сайтом.
Прямой обмен - 1С сама стучится на сайт по HTTP, забирает и отправляет данные в реальном времени или по расписанию из самой 1С. Файловый обмен - 1С выгружает XML-файлы на диск (локально или по FTP), а дальше их забирает cron-задача на сервере сайта и обрабатывает независимо от того, работает ли в этот момент 1С.
| Критерий | Прямой обмен | Обмен через файлы |
|---|---|---|
| Скорость появления изменений на сайте | Минуты, зависит от расписания в 1С | Зависит от cron, обычно 5-15 минут |
| Что происходит при обрыве интернета у 1С | Обмен не запускается, ошибка видна сразу | Файлы обработаются, когда связь восстановится |
| Нагрузка на сервер сайта | Пиковая, в момент обмена | Можно растянуть обработку по времени |
| Нужен ли сайту открытый доступ для 1С | Да, отдельный URL и учётка обмена | Не обязательно, если файлы кладутся по FTP |
Для магазинов с одним постоянным менеджером 1С и стабильным интернет-каналом обычно ставлю прямой обмен, он проще в диагностике: все ошибки видно сразу в логе обмена. Для розницы с несколькими торговыми точками и нестабильной связью на местах файловый вариант через промежуточный FTP или папку обмена выручает, он терпимее к обрывам, но держать его как постоянный боевой режим я не советую. В самой 1С выгрузка в каталог на диске идёт как вспомогательная: она нужна, когда прямого доступа к сайту нет, и удобна, чтобы посмотреть, что именно 1С отправляет. Штатный протокол обмена описан как обмен по HTTP, поэтому боевую схему строю на прямом обмене, а файлы держу для диагностики и как временный обход, пока не решён вопрос со связью.
Отдельно предупреждаю про cron на стороне сайта: повесить обмен на него в лоб не получится. Обработчик /bitrix/admin/1c_exchange.php рассчитан на то, что сеанс начинает 1С, он принимает type=catalog для каталога и type=sale для заказов, а шаги сеанса задаются параметром mode (для каталога это checkauth, init, file, import), и всё это внутри авторизованной сессии обмена. Поэтому расписание задаётся в самой 1С, а на стороне сервера остаётся следить за логами обмена и лимитами PHP.
Частые ошибки синхронизации каталога, цен и остатков
Собрал список того, что встречается регулярно на реальных проектах.
- Товары дублируются после каждого обмена. Обычно причина в том, что внешний код элемента (XML_ID) в 1С меняется при переформировании справочника номенклатуры, и Битрикс воспринимает это как новый товар, а не обновление старого.
- Остатки не совпадают с 1С. Часто на сайте настроен обмен только по одному складу, а в 1С отгрузки идут с нескольких, либо в Битриксе не включён учёт по складам в настройках каталога.
- Цены обновляются с задержкой в сутки. Типовая история для магазинов, где обмен ценами повесили на то же расписание, что и полную выгрузку каталога раз в ночь, хотя цены логичнее гонять отдельным быстрым циклом каждый час.
- Пропадают свойства товаров или характеристики. Проверяю в первую очередь сопоставление типов свойств между 1С и Битриксом, при первой настройке обмена это делается вручную, и часть полей легко забыть смэппить.
- Обмен зависает без ошибки в интерфейсе. Смотрю логи обмена с включённым debug-режимом и системный лог PHP, там обычно видна реальная причина: нехватка памяти или таймаут.
Обмен заказами: статусы и задвоение
С заказами обмен идёт в обратную сторону: сайт формирует XML с новыми и изменёнными заказами, 1С их забирает и присваивает свой номер и статус. На сайте настраивается сопоставление статусов заказа Битрикса со статусами документов в 1С, это делается один раз в интерфейсе обмена, но именно тут чаще всего расходятся ожидания заказчика с тем, что реально происходит.
Задвоение заказов почти всегда связано с тем, что 1С не получила подтверждение об успешной обработке своего запроса (например, оборвалось соединение уже после того, как заказ выгрузился) и на следующей итерации запрашивает тот же заказ снова. Решается корректной настройкой квитирования в протоколе обмена и, если позволяет объём заказов, переходом на более частый, но лёгкий цикл обмена вместо редкого и тяжёлого.
Отдельно слежу за тем, что при обмене заказов синхронизируются статусы оплаты и доставки, а не только сам факт заказа, иначе бухгалтерия видит в 1С заказ, но не видит, что он уже оплачен через эквайринг на сайте, и это создаёт лишнюю ручную работу.
Когда обмен нужно дорабатывать и сколько это стоит
Штатный обмен CommerceML закрывает базовый сценарий «каталог туда, заказы обратно». Но как только в проекте появляются нетиповые требования - синхронизация с несколькими 1С-базами, обмен с внешним складским WMS, автоматическая передача данных в CRM или мессенджер при смене статуса заказа, готовые настройки модуля перестают справляться, и нужна доработка.
| Задача | Цена |
|---|---|
| Аудит и консультация по текущей настройке обмена | от 3 000 ₽ |
| Техподдержка с регулярным контролем логов обмена и перезапуском при сбоях | от 15 000 ₽/мес |
| Интернет-магазин на Битрикс под ключ с настройкой обмена с 1С | от 80 000 ₽ |
| Кастомная автоматизация вокруг обмена (доп. интеграции через n8n, вебхуки в CRM) | от 25 000 ₽ |
На рынке разработчики и студии часто закладывают на настройку обмена под ключ 40 000-100 000 ₽ в зависимости от сложности каталога и числа складов - это не мои цены, а ориентир по рынку, стоит держать его в голове при сравнении предложений.
Если после запуска обмен нужно не только настроить, но и держать под присмотром - смотреть логи, вовремя ловить сбои после обновлений Битрикса или 1С, чинить задвоения - обычно оформляю это как техподдержку сайта с регулярным контролем обмена и логов, а не разовую настройку, потому что сама конфигурация 1С и сайта со временем меняется и требует пересмотра.
Частые вопросы
Как часто должен запускаться обмен Битрикс с 1С?
Для остатков и цен обычно ставлю цикл раз в 15-60 минут, зависит от того, насколько быстро на складе меняются остатки. Для заказов беру более частый цикл, каждые 5-15 минут, чтобы менеджер видел новый заказ в 1С почти сразу после оформления на сайте. Полную выгрузку каталога с проверкой всех разделов и свойств обычно ставлю на ночь, раз в сутки, потому что это самая тяжёлая операция для сервера.
Можно ли настроить обмен без модуля 1С-Битрикс: Управление сайтом?
Формально да, через отдельные скрипты на PHP, которые читают и пишут XML в формате CommerceML или обмениваются данными через REST API 1С, если он включён. Но штатный модуль уже реализует протокол, квитирование и обработку ошибок, поэтому переписывать это с нуля имеет смысл только под очень нетиповые сценарии, например обмен сразу с несколькими базами 1С или системами вне линейки 1С-Битрикс.
Почему после обмена задваиваются заказы или товары?
Для заказов почти всегда причина в потере подтверждения между сайтом и 1С при обрыве связи. Для товаров - в том, что внешний код (XML_ID) элемента в 1С не постоянный и меняется при переносе номенклатуры между базами или после реструктуризации справочников. Проверяю оба сценария в первую очередь, когда вижу задвоение.
Что делать, если обмен зависает на большом каталоге?
Сначала смотрю логи обмена с включённым debug-режимом и системный лог PHP, чтобы понять, упирается процесс в память или в таймаут. Дальше подбираю размер пачки обмена в настройках модуля так, чтобы один шаг укладывался в лимиты, вместо выгрузки всего каталога одним запросом и отдельно поднимаю лимиты max_execution_time и memory_limit для скрипта обмена на хостинге.