Обмен заказами Битрикс 1С - это не разовая настройка, а процесс, который либо работает годами без сбоев, либо превращается в постоянный источник тикетов в духе «заказ есть на сайте, а в 1С его нет». Я настраивал и чинил такие связки на интернет-магазинах с нагрузкой от десятка до нескольких сотен заказов в день, и в этой статье разберу механику: как заказ из корзины на сайте превращается в документ учётной системы, что делает штатный модуль обмена, а что придётся дорабатывать руками.
Как обмен заказами между Битрикс и 1С устроен на уровне архитектуры
Схема всегда одна и та же, меняются только детали реализации. Сайт на 1С-Битрикс формирует заказы в своей базе, 1С хранит справочник товаров, цены, остатки и в итоге создаёт из заказа сайта документ учёта - «Заказ покупателя» или сразу «Реализацию товаров и услуг». Между этими двумя базами нет прямого доступа друг к другу - они обмениваются файлами или HTTP-запросами по расписанию.
Обмен всегда двусторонний. В одну сторону идёт каталог: товары, цены, остатки, характеристики - из 1С на сайт. В обратную сторону - заказы: из Битрикс в 1С летят новые заказы, а из 1С на сайт возвращаются обновлённые статусы, номера отгрузок и данные по оплате. Если настроена доставка через СДЭК, туда же добавляется синхронизация трек-номеров: 1С получает номер заказа, оформляет отгрузку, а трек-номер СДЭК возвращается на сайт и попадает в личный кабинет покупателя.
Запускается обмен по расписанию - обычно раз в 10-15 минут через cron на сервере 1С или через встроенный планировщик Битрикс. На высоконагруженных проектах интервал сокращают до 2-5 минут, но здесь важно смотреть на объём: чем больше заказов и товаров в выгрузке, тем дольше идёт обработка файла, и слишком частый запуск может привести к тому, что предыдущий сеанс обмена ещё не завершился, а новый уже стартовал.
CommerceML: протокол, на котором держится вся синхронизация заказов
В основе штатного обмена лежит CommerceML - XML-формат, который 1С и Битрикс понимают одинаково без написания интеграционного кода с нуля. У протокола две части: обмен каталогом (импорт товаров, цен, остатков) и обмен заказами (документ CommerceML с типом «Заказ», где перечислены позиции, цены, скидки, реквизиты покупателя и способ доставки).
Есть два режима обмена: файловый и через прямой обмен по HTTP. Файловый - это когда 1С выгружает XML-файлы во временную папку на сервере, Битрикс их забирает и обрабатывает, а результат кладёт обратно в ту же папку. Работает надёжно, но требует доступа по FTP или общей файловой системы. Прямой обмен идёт через HTTP-запросы напрямую к обработчику Битрикс - быстрее, но чувствительнее к таймаутам, особенно если хостинг сайта ограничивает время выполнения PHP-скрипта.
На практике для магазинов с каталогом до 5-10 тысяч товаров и потоком до 100-150 заказов в день хватает файлового обмена по расписанию. Когда объём выше - например, маркетплейс с несколькими поставщиками - переходят на прямой обмен или вообще уходят от штатного модуля в сторону кастомной интеграции через REST API 1С.
| Способ обмена | Когда подходит | Слабое место |
|---|---|---|
| Файловый CommerceML | Магазин до 100-150 заказов/день | Задержка между циклами обмена |
| Прямой обмен по HTTP | Нужна почти мгновенная синхронизация | Таймауты при большом каталоге |
| REST API 1С + кастомный обработчик | Нестандартные поля, несколько систем на входе | Требует разработки и поддержки |
| n8n как прослойка | Нет штатного модуля обмена или нужна доп. логика (уведомления, СДЭК, CRM) | Дополнительный сервис в инфраструктуре |
Путь заказа: от корзины на сайте до документа в 1С
Покупатель оформил заказ на сайте - в базе Битрикс появилась запись в таблице заказов со статусом «Принят». Дальше в дело вступает модуль обмена: при следующем запуске по расписанию он формирует CommerceML-документ с этим заказом и всеми его позициями, и передаёт файл в 1С (или отправляет через HTTP-запрос, если настроен прямой обмен).
1С получает документ и создаёт «Заказ покупателя» - это ещё не отгрузка, а резервирование товара под конкретного клиента. Дальше менеджер или автоматический бизнес-процесс в 1С проводит документ, резервирует остатки, и если оплата уже прошла (например, через приём платежей на сайте по T‑Bank или другой эквайринг), статус в 1С меняется на «Оплачен» и запускается формирование «Реализации».
Обратно на сайт летит статус: 1С через тот же обмен сообщает Битрикс, что заказ подтверждён, зарезервирован или отгружен. На стороне сайта это меняет статус в личном кабинете покупателя и, если настроены уведомления, триггерит письмо или сообщение в Telegram-бот на aiogram, который у части моих клиентов используется как канал уведомлений менеджеров о новых и проблемных заказах - быстрее, чем проверять почту.
Весь цикл - от нажатия кнопки «Оформить заказ» до появления документа в 1С - занимает от одного до двух циклов обмена, то есть 10-30 минут при стандартной настройке. Это нормально для интернет-магазина, но плохо подходит для сценариев, где нужна мгновенная проверка остатка перед подтверждением оплаты - тогда обмен переводят в режим прямого HTTP-запроса именно для критичных операций, оставляя файловый обмен для каталога.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Частые проблемы синхронизации заказов Битрикс и 1С и как я их закрываю
Первая и самая частая проблема - дубли заказов. Возникает, когда обмен запускается повторно до завершения предыдущего сеанса или когда меняли идентификатор заказа в базе Битрикс вручную. Решение - проверка на стороне обработчика по внешнему идентификатору CommerceML, а не по внутреннему ID сайта, и жёсткая блокировка параллельного запуска обмена через lock-файл.
Вторая - расхождение статусов. В Битрикс есть свой список статусов заказа, в 1С свой набор состояний документа, и штатное сопоставление один-к-одному не всегда покрывает реальный бизнес-процесс. Например, заказ «частично оплачен» или «ожидает подтверждения по телефону» штатная схема не всегда умеет передать корректно. Здесь помогает только явная таблица соответствия статусов, прописанная в коде обработчика, а не в настройках интерфейса.
Третья - таймауты на больших выгрузках. Если каталог перевалил за 20-30 тысяч товаров с характеристиками, файл CommerceML может весить десятки мегабайт, и хостинг с ограничением в 30-60 секунд на выполнение скрипта просто обрывает обработку на середине. Лечится либо разбиением выгрузки на части (штатная опция CommerceML это поддерживает), либо переносом обмена на выделенный сервер без жёстких лимитов.
Четвёртая, менее очевидная - кастомные поля заказа. Если на сайте добавлены нестандартные свойства (способ доставки СДЭК с расчётом по ПВЗ, комментарий к заказу, промокод), штатный модуль обмена их просто не увидит - он знает только базовый набор полей CommerceML. Приходится дорабатывать обработчик обмена на стороне Битрикс, чтобы он допаковывал эти поля в дополнительные реквизиты документа, и на стороне 1С писать обработку этих реквизитов при создании документа.
Когда штатного обмена мало: доработка обработчиков и REST API
Штатный CommerceML закрывает типовой сценарий: простой каталог, простой заказ, один склад. Как только появляется что-то нестандартное - обмен приходится дорабатывать, и тут есть два пути.
Первый - доработка самого обработчика обмена (файл в модуле catalog или отдельный обработчик 1С-Битрикс), куда добавляют обработку кастомных полей, логику мультискладов, специфичные правила резервирования. Это классическая программная доработка на стороне PHP и 1С:Предприятие, и она требует понимания структуры CommerceML-документа на уровне тегов, а не только интерфейса настройки.
Второй путь - уйти от файлового обмена в сторону REST API 1С и построить интеграцию через промежуточный сервис. Это оправдано, когда заказы должны попадать не только в 1С, но параллельно в CRM, в Telegram-бота для склада или в систему аналитики. В таких случаях я собираю связку через n8n или пишу отдельный Python-скрипт-прослойку: он читает новые заказы из Битрикс через встроенный REST API сайта, приводит их к нужному формату и параллельно отправляет в 1С и в другие системы. Готовые сценарии для похожих интеграций я собираю в библиотеке готовых скриптов - часть логики сопоставления полей и обработки ошибок обмена можно переиспользовать, не собирая всё с нуля.
Есть и третий вариант, который часто недооценивают - событийный обмен вместо обмена по расписанию. Вместо того чтобы ждать следующего цикла cron, сайт при оформлении заказа сразу дёргает вебхук, который инициирует отправку конкретного заказа в 1С немедленно. Это не отменяет плановый обмен (он всё равно нужен для каталога и статусов), но убирает задержку именно на критичном участке - подтверждении заказа.
Сколько стоит настроить или доработать обмен заказами
Цены сильно зависят от того, чинится штатный обмен или строится нестандартная логика с нуля. На рынке за настройку типового CommerceML-обмена между Битрикс и 1С студии и фрилансеры обычно просят от 15 000 до 50 000 ₽ - разброс большой, потому что многие даже не разбирают, что уже настроено, а что нет, и закладывают время на изучение проекта в стоимость.
У меня консультация с разбором текущей настройки обмена и поиском причины конкретной проблемы - от 3 000 ₽, этого обычно достаточно, чтобы понять, дублируются заказы из-за гонки процессов или из-за ошибки сопоставления статусов. Доработка обработчика под нестандартные поля заказа или кастомную логику резервирования - от 40 000 ₽, сопоставимо по сложности с комплексной интеграцией CRM или эквайринга, которую я делаю для сайтов на Tilda и WordPress. Если нужна полноценная прослойка на n8n или отдельный скрипт-синхронизатор с несколькими системами на выходе - это отдельная автоматизация от 25 000 ₽ в зависимости от числа систем и правил маршрутизации заказов.
Постоянное сопровождение обмена - мониторинг логов, реакция на сбои синхронизации, поддержание совместимости при обновлениях 1С или Битрикс - я веду в рамках техподдержки от 15 000 ₽/мес. Для магазинов с ежедневным потоком заказов это обычно выгоднее разовых вызовов «когда сломалось», потому что проблему в логе обмена ловят раньше, чем она превращается в потерянный заказ.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Почему заказ появился на сайте, но не дошёл до 1С?
Чаще всего дело в трёх вещах: обмен ещё не отработал очередной цикл по расписанию, обработчик упал с ошибкой из-за нестандартного поля в заказе (например, незнакомого способа доставки), или файл обмена завис из-за таймаута на большом каталоге. Первым делом смотрю лог обмена в административной панели Битрикс - там обычно видно точку, на которой процесс остановился.
Можно ли настроить обмен заказами без штатного модуля 1С-Битрикс?
Можно, через REST API сайта и API 1С, но это уже не CommerceML, а отдельная интеграция, которую пишут под конкретный проект. Такой подход оправдан, если заказы нужно параллельно направлять в несколько систем или логика сопоставления полей слишком нестандартная для штатного протокола.
Как часто должен запускаться обмен, чтобы заказы не терялись?
Для большинства интернет-магазинов достаточно интервала в 10-15 минут - это баланс между нагрузкой на сервер и скоростью появления заказа в 1С. Если критична мгновенная проверка остатка перед подтверждением оплаты, для этого конкретного шага делают отдельный вебхук, а не сокращают интервал всего обмена.
Что делать, если после обновления 1С обмен с Битрикс перестал работать?
Обычно ломается формат CommerceML-документа или меняются названия полей в выгрузке - обработчик на стороне сайта не узнаёт новую структуру. Нужно свериться с логом обмена, найти на каком теге или реквизите падает разбор, и обновить обработчик под новую версию выгрузки 1С.