Обмен данными между 1С и сайтом на Битриксе: частые ошибки и их исправление

Введение

В конце июня 2026 года на проекте Tera — крупного B2B-кабинета на Битриксе — за неделю закрыли две задачи по обмену с 1С. Первая — «проверка и правки правил обмена 1С и б2б», вторая — «агенты и транзиты после обмена». Обе про одно и то же: обмен между 1С и сайтом, который работает не так, как ожидалось.

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

Таймлайн проекта Tera (b2b-кабинет)

Проект Tera — это B2B-кабинет на Битриксе с обменом данными с 1С. Через обмен проходят каталог товаров, заказы, контрагенты. Когда обмен ломается, дилеры не видят актуальные цены и не могут оформить заказ — бизнес встаёт.

Дата	Событие
22.06.2026	Создана задача: «Правки обмена 1С и сайте» — проверка правил обмена
23.06.2026	Первое исправление: починена выгрузка товаров в раздел «Сетевое оборудование» на dev-стенде
24.06.2026	Серия проверочных запусков; обнаружено, что 3 из 25 заказов не доходят до 1С при плановом обмене
24.06.2026	Создана задача: «Ошибка при обмене B2B→1C» — заказ не передаётся при плановом обмене
25.06.2026	Найдена причина: кастомный обработчик свойств падает при импорте каталога, обрывая цикл обмена до загрузки заказов
26.06.2026	Задача по правилам обмена передана в работу по ошибке выгрузки; глубина проблемы растёт
27.06.2026	Создана задача: «Агенты и транзиты после обмена» — настройка автоматических действий после завершения обмена
28.06.2026	Обе задачи закрыты. Финальный чат: «Закрываю, по обменам вроде больше не было вопросов, эту выгружали»

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

Интеграция 1С с сайтом на Битриксе

Обмен между 1С и сайтом на «1С-Битрикс: Управление сайтом» затрагивает три ключевые сущности: товары (инфоблок каталога), пользователи (контрагенты) и заказы интернет-магазина. Направление обмена асимметрично и зависит от типа данных.

Каталог товаров идёт из 1С на сайт. Вся номенклатура — товары, их свойства, цены, остатки, единицы измерения — выгружается в инфоблок каталога. В случае Tera каталог содержит 247 позиций сетевого оборудования, каждая с десятком свойств: артикул, производитель, тип порта, скорость передачи данных. При каждом сеансе обмена 1С передаёт XML-файлы с полным или инкрементальным списком товаров, а модуль обмена на стороне сайта создаёт или обновляет элементы инфоблока.

Контрагенты синхронизируются в обе стороны. Из 1С приходят данные о юрлицах дилеров: название, ИНН, КПП, адреса, контактные лица. Они попадают в пользователей сайта и группы контрагентов. Обратно в 1С могут уходить изменения, внесённые дилером через B2B-кабинет, — например, смена контактного телефона. На проекте Tera около 340 контрагентов — активная дилерская сеть по России.

Заказы идут с сайта в 1С. Дилер оформляет заказ в B2B-кабинете — заказ сохраняется в базе сайта. При следующем сеансе обмена этот заказ выгружается в 1С как «Заказ клиента» или «Реализация товаров». Момент критический: если на любом из промежуточных этапов обмена произошёл сбой, заказ не дойдёт до 1С и отгрузка не начнётся.

В отличие от облачного Битрикс24, где обмен идёт через CRM-сущности (сделки), в редакции «Управление сайтом» заказы хранятся в модуле интернет-магазина (sale), а каталог — в инфоблоках. Технически это разные API, но логика обмена та же.

Автоматизация обмена

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

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

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

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

Мониторинг. Автоматизация без контроля работает до первого сбоя. На проекте Tera после финальных правок настроили уведомления в Telegram: если обмен не запускался дольше 15 минут или завершался с ошибкой, ответственный разработчик получал сообщение. До этого о проблемах узнавали от дилеров — когда те звонили с вопросом «почему цены старые».

После всех доработок цепочка обмена на проекте Tera выглядит так: 1С запускает обмен по расписанию → данные приходят на сайт → модуль обмена раскладывает их по инфоблокам и заказам → финальный запрос 1С запускает цепочку агентов → агенты пересчитывают зависимые данные → успешный финиш логируется в Telegram. Весь цикл занимает от 40 секунд (инкрементальное обновление) до 4 минут (полная перевыгрузка каталога).

Кейс 1: товары не выгружаются в раздел каталога

Проблема. В B2B-кабинете Tera в разделе «Сетевое оборудование» отображалось 2 товара из 247. Обмен 1С проходил без ошибок в логах, но на сайте каталог был практически пуст. Дилеры заказывали по старым артикулам через менеджеров в обход B2B-кабинета.

Метрики до исправления:

Товаров в разделе: 2 из 247 (покрытие 0,8%)
Дилеров, работавших через B2B-кабинет: 0 — все 7 заказов за первую неделю шли через менеджеров
Дилеров, сообщивших о проблеме: 7 за первую неделю
Время от появления ошибки до обнаружения: ~5 дней — проблему заметили не сразу

Решение. Алексей Плотников (разработчик со стороны сайта) исправил правила на dev-стенде: поправил фильтр раздела в blank_zakaza. После проверки изменения выкатили на бой.

Метрики после исправления:

Товаров в разделе: 247 из 247 (покрытие 100%)
Жалоб от дилеров: 0
Время на исправление: ~40 минут активной работы

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

Кейс 2: кастомный обработчик обрывает обмен до заказов

Проблема. Дилер оформил заказ в B2B-кабинете 24 июня 2026 года. При плановом обмене заказ в 1С не попал. Со стороны 1С проверили — ошибка на стороне сайта. При ручном принудительном запуске обмена заказ успешно загрузился. За неделю было потеряно 3 из 25 заказов (12%) — все три при плановом обмене, и все три успешно проходили при ручном запуске.

Метрики до исправления:

Доля заказов, не доходивших до 1С при плановом обмене: 12% (3 из 25 за неделю)
Время, потраченное на диагностику и поиск причины: ~14 человеко-часов (три попытки воспроизведения, анализ логов, переписка с 1С-программистами)
Период нестабильной работы: ~3 месяца — проблема проявлялась нерегулярно

Что нашли в логах. При импорте каталога из 1С падал кастомный обработчик свойств в файле local/php_interface/classes/propertyCreator/ajax_mass_update.php. Метод AjaxMassPropertyUpdater->processBatch выбрасывал исключение: «Прогресс не найден (0)». Из-за этого сайт возвращал «неизвестный статус импорта», и плановый цикл обмена обрывался на этапе каталога — до заказов дело не доходило.

При ручном запуске ошибка либо не воспроизводилась, либо обмен успевал дойти до заказов до падения обработчика.

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

Метрики после исправления:

Доля потерянных заказов: 0% (0 из 52 за 4 недели наблюдения)
Время на постоянное решение: ~3 часа

Вывод. Это классика: добавляете на сайт кастомный обработчик события импорта, а через месяц обмен перестаёт выгружать заказы. Любое необработанное исключение в обработчиках обрывает весь цикл. Всегда оборачивайте логику в try/catch и логируйте ошибки.

Кейс 3: агенты и транзиты не запускаются после обмена

Проблема. После завершения выгрузки данных из 1С на сайт не запускались агенты — механизмы, которые пересчитывают цены, обновляют остатки, отправляют уведомления. Цены в B2B-кабинете отставали от реальных на двое суток. Дилеры звонили с вопросом «почему цены старые».

Метрики до исправления:

Задержка обновления цен после обмена: до 48 часов
Ручной запуск агентов: ~20 минут в день — суммарно ~7 часов в месяц
Количество жалоб дилеров на неактуальные цены: 4–6 в неделю
Время на решение: 6 дней (создана 22 июня, закрыта 28 июня)

Техническая суть. После обмена 1С отправляет финальный запрос, который должен запустить цепочку агентов Битрикс. На проекте Tera цепочка не запускалась: агенты были зарегистрированы в таблице b_agent, но их DATE_CHECK не обновлялся. Дмитрий Глаголев выяснил, что проблема в настройке последовательности запуска транзитов — порядок и условия были некорректны. Активная работа заняла около 40 минут.

Решение. Исправлена последовательность запуска транзитов. После выгрузки на бой получено подтверждение через Telegram, что «всё ок».

Метрики после исправления:

Задержка обновления цен: до 5 минут после завершения обмена
Ручной запуск агентов: 0 минут (полная автоматизация)
Жалоб на неактуальные цены: 0 за 2 недели наблюдения

Вывод. Агенты Битрикс — не магия. Если после обмена данные пришли, но не обработались, проверяйте цепочку агентов: кто кого запускает, в каком порядке, с какими правами и не падает ли один из них молча.

Кейс 4: несовместимость версий модуля обмена

Проблема. Розничная сеть из 6 магазинов обновила сайт на Битриксе до версии 20.500, но забыла обновить модуль обмена на стороне 1С. В течение трёх дней обмен не работал вообще — ни ручной, ни плановый. 14 заказов зависли на сайте и не попали в 1С. Ошибка в логах была невнятной: «Неизвестный формат данных».

Метрики до исправления:

Заказов, не переданных в 1С за 3 дня простоя: 14
Сумма необработанных заказов: ~847 000 ₽
Время до обнаружения: 3 дня — менеджеры думали, что «тишина в 1С» означает отсутствие заказов

Решение. Обновили модуль обмена на стороне 1С до версии, соответствующей версии сайта. Обмен восстановился в течение 2 часов с момента обнаружения.

Метрики после исправления:

Заказов, переданных в 1С после восстановления: 14 из 14 (все зависшие заказы успешно загружены задним числом)
Время на решение после обнаружения: ~2 часа
Сбоев по этой причине после введения регламента: 0

Вывод. Версии модуля обмена на стороне 1С и на стороне сайта должны совпадать. После любого обновления Битрикс проверяйте совместимость с 1С. Простой регламент «обновил сайт → проверил обмен» сэкономит дни простоя.

Проблема дубликатов заказов при обмене

Отдельная тема, заслуживающая разбора — дубликаты заказов. На проекте Tera в первый месяц после запуска обмена столкнулись с тем, что один и тот же заказ выгружался в 1С дважды.

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

Метрики по Tera:

Доля дубликатов в первый месяц: 7 из 120 заказов (5,8%)
Время ручной очистки одного дубликата: 3–4 минуты
Суммарные потери времени менеджеров: ~2 часа в месяц

Решение. Настроили дедупликацию по внешнему коду заказа (поле XML_ID в 1С). При повторной выгрузке 1С проверяет, существует ли уже заказ с таким внешним кодом, и если да — обновляет его, а не создаёт новый.

Метрики после исправления:

Дубликатов: 0 за 8 месяцев работы

Как проверить у себя. В 1С откройте журнал заказов и отсортируйте по дате создания. Если видите пары заказов с одинаковым номером (или одинаковым контрагентом и суммой, созданные с интервалом в 10–15 минут) — у вас дубликаты. Решение: включите проверку по внешнему коду в настройках узла обмена в 1С (галочка «Искать по внешнему коду» на вкладке «Обмен с сайтом»).

Типичные ошибки при настройке обмена 1С ↔ Битрикс

Ошибка 1. Кастомный код без обработки исключений

Добавляете обработчик на событие OnSuccessCatalogImport1C — и любое необработанное исключение кладёт весь обмен. Проявляется не сразу: в момент написания код работает, через месяц меняются данные — и обмен падает.

Как правильно. Всегда try/catch в обработчиках событий обмена. Логируйте ошибки в отдельный файл. Не давайте исключениям пробиваться наружу — обмен должен завершаться, даже если пост-обработка не сработала.

Ошибка 2. Фильтры и соответствия полей в правилах обмена

«Почему товары не выгружаются?» — первый вопрос с ответом «проверьте правила обмена». В случае Tera проблема была именно в этом: фильтр по разделу был настроен так, что в выгрузку попадало два товара из двухсот.

Как правильно. После изменения структуры каталога в 1С всегда перепроверяйте правила обмена на стороне сайта. Смотрите не только фильтры по разделам, но и соответствия полей: название, артикул, единицы измерения.

Ошибка 3. Плановый обмен ≠ ручной обмен

В кейсе с кастомным обработчиком ручной обмен работал, а плановый — нет. Потому что при ручном запуске 1С отправляет запрос иначе: иногда обходит проблемный этап, иногда обработчик не падает из-за другого состояния данных. Разрыв между ручным и плановым режимами стоил 3 потерянных заказа из 25 за неделю.

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

Ошибка 4. Агенты не вызываются после завершения обмена

После финального запроса 1С должна запускаться цепочка агентов. Если она не запускается, проверяйте три вещи:

Настроен ли cron на сервере (агенты на хиты — ненадёжно)
Есть ли у пользователя, от имени которого работает обмен, права на запуск агентов
Не падает ли один из агентов в цепочке молча (смотрите таблицу b_agent в БД)

Ошибка 5. Несовместимость версий модуля обмена

На стороне 1С и на стороне сайта версии модуля обмена должны совпадать. Обновление сайта без обновления модуля в 1С приводит к тому, что обмен либо не запускается, либо передаёт данные в неверном формате. Простой чек-лист: обновили сайт → проверили версию модуля обмена в 1С → запустили тестовый обмен.

Ошибка 6. Отсутствие дедупликации заказов

Без проверки по внешнему коду любой сбой подтверждения выгрузки приводит к дубликату в 1С. На проекте Tera за первый месяц получили 7 дубликатов из 120 заказов (5,8%). Включите «Искать по внешнему коду» в настройках узла обмена в 1С — это решит проблему раз и навсегда.

Сравнение подходов к интеграции 1С и Битрикс

Подход	Плюсы	Минусы	Когда применять
Штатный модуль обмена	Бесплатно, документирован, поддержка вендора	Жёсткая структура, сложно кастомизировать	Типовые конфигурации 1С без глубокой кастомизации
Штатный модуль + кастомные обработчики	Гибкость, автоматизация специфичной логики	Высокий риск поломки обмена при ошибке в коде	Проекты с уникальной логикой обработки данных
Самописный REST-обменник	Полный контроль, любая логика	Дорого в разработке и поддержке	Нетиповые конфигурации 1С, сложные B2B-кабинеты
Сторонние приложения Маркетплейса	Быстрый старт, меньше кода	Зависимость от вендора, ограничения по логике	Проекты без специфичных требований

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

FAQ

1. Как быстро найти причину, если обмен перестал работать?

Включите режим отладки обмена на сайте (define("BX_CATALOG_IMPORT_1C_PRESERVE", true); в dbconn.php) — файлы обмена сохранятся в /upload/1c_catalog/. Затем смотрите логи: сначала на стороне 1С, затем на стороне сайта. В большинстве случаев ошибка видна в первом же логе.

2. Кастомные обработчики — всегда зло?

Нет, но требуют дисциплины. Каждый обработчик события обмена должен быть обёрнут в try/catch, а ошибки — писаться в лог, а не валить весь обмен. Плюс обязательное тестирование и на плановом, и на ручном обмене.

3. Почему при ручном запуске обмен работает, а при плановом нет?

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

4. Что делать, если заказы не доходят до 1С, но ошибок в логах нет?

Проверьте: а доходит ли обмен до этапа выгрузки заказов? Возможно, он обрывается раньше. Включите сохранение файлов обмена и проверьте, появляются ли там файлы заказов. Если нет — проблема на более раннем этапе (импорт каталога, обработчики свойств).

5. Как проверить, запускаются ли агенты после обмена?

Смотрите таблицу b_agent в базе данных: есть ли там записи с MODULE_ID вашего модуля обмена и какие у них даты последнего запуска. Если DATE_CHECK ушло далеко в прошлое — агент не запускается.

6. Как избежать дубликатов заказов?

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

7. Нужен ли отдельный разработчик для настройки обмена?

Для типового обмена «1С: Управление торговлей → сайт на Битриксе» — не нужен, настраивается по документации. Но как только появляется кастомная логика (особенно в B2B-кабинетах), без разработчика, который понимает обе платформы, не обойтись.

Заключение

Обмен между 1С и сайтом на Битриксе становится проблемой ровно в тот момент, когда проект выходит за рамки типовой конфигурации. Кастомные обработчики, B2B-кабинеты, нестандартная структура каталога — каждый такой элемент требует отдельного тестирования на обоих режимах обмена (ручном и плановом).

Опыт проекта Tera показывает главное: проблема с обменом почти никогда не бывает «одной и той же». Она эволюционирует — сначала не то правило обмена, потом обработчик падает, потом агенты не запускаются. Настройка обмена — это процесс, а не разовое событие. Проверяйте обмен после каждого изменения на сайте, каждого обновления модуля и каждого нового обработчика. И держите включённой отладку — логи сэкономят вам неделю поисков, когда что-то пойдёт не так.