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

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

Введение

В конце июня 2026 года на проекте Tera — крупного B2B-кабинета на Битриксе — за неделю закрыли две задачи по обмену с 1С. Первая — «проверка и правки правил обмена между 1С и «1С-Битрикс: Управление сайтом», вторая — «агенты и транзиты после обмена». Обе про одно и то же: обмен между 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	Создана задача: «Ошибка при обмене Битрикс→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С-Битрикс поддерживает два режима: ручной и плановый. Но «плановый» не означает «полностью автоматический». После завершения выгрузки данных нужна постобработка. И если она не настроена, автоматизацию нельзя считать полной.

Плановый обмен по расписанию. На стороне 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 дней (проблему заметили не сразу)

Решение. Разработчик со стороны сайта исправил правила на тестовом стенде: поправил фильтр раздела в 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 показывает главное: проблема с обменом почти никогда не бывает «одной и той же». Она эволюционирует: сначала - не то правило обмена, потом - обработчик падает, потом - агенты не запускаются.

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