Обмен Битрикс24 и 1С: настройка синхронизации

Что реально синхронизируется между 1С и Битрикс24

Когда к нам приходят с задачей «связать 1С и Битрикс24», почти всегда за ней стоит одна и та же картина: каталог, цены и остатки живут в 1С, а сделки, заказы и общение с клиентами — в CRM. Менеджер в Битрикс24 не видит актуальный остаток и продаёт то, чего на складе нет. Бухгалтер в 1С не видит оплату, которую клиент внёс через личный кабинет. Контент-менеджер правит описание товара в Битрикс24, а через час импорт затирает правку. Это не одна проблема, а несколько независимых потоков данных, которые разъезжаются каждый по своему сценарию.

Штатный модуль обмена закрывает базовый сценарий: тянет номенклатуру, цены и остатки из 1С в Битрикс24, отправляет обратно заказы и оплаты. Для типовой «1С:Розница» ред. 2.3 или «1С:Бухгалтерии 8» ред. 3.0 этого часто хватает. Но появляется нетиповая конфигурация, дополнительные реквизиты, свои правила расчёта цен или несколько юрлиц — и штатный обмен упирается в границу. Дальше нужен REST.

Где именно проходит эта граница, мы выясняем на старте проекта. От этого зависит вся архитектура интеграции.

Что реально ходит между системами в обе стороны:

• Номенклатура — товары, услуги, характеристики, привязка к разделам каталога.
• Цены — базовые и типы цен, скидки, наценки по правилам из 1С.
• Остатки — по складам и в целом, с учётом резервов.
• Контрагенты — компании и контакты, синхронизируются с сущностями CRM.
• Заказы — из Битрикс24 в 1С, каждый заказ превращается в отдельный документ.
• Оплаты и отгрузки — включая частичные, поддерживаются с модуля sale 16.0.13 и 1С версии 6+.
• Статусы сделок — обратный поток, чтобы менеджер видел движение заказа в CRM.

Ниже — матрица по каждой сущности: где она «главная», куда течёт и каким механизмом это делается штатно.

Подробнее: кастомная иерархия каталога битрикс.

Как устроена синхронизация 1С с Битрикс24: два канала и когда какой брать

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

В интеграции 1С и Битрикс24 исторически живут два независимых транспорта. CommerceML — это XML-обмен файлами по протоколу, который 1С и Битрикс понимают «из коробки»: каталог, цены, остатки, заказы, документы оплат и отгрузок. REST API — это HTTP-методы Битрикс24 к сущностям CRM, задачам, лидам, контактам, компаниям и всему, что живёт в Битрикс24, а не в каталоге.

Оба канала закрывают разные половины задачи, и выбрать один на всё не получится по трём причинам:

• Разные типы сущностей. Товары, разделы, цены и остатки — это CommerceML. Сделки, лиды, задачи, смарт-процессы — это REST API Битрикс24.
• Разная пропускная способность. CommerceML гоняет пакетные XML-файлы и рассчитан на десятки тысяч позиций за сессию. REST работает поштучно и на объёме каталога упирается в лимиты и таймауты.
• Разная логика авторизации. CommerceML использует сессионную схему checkauth → init → file → import со специальным пользователем обмена. REST — OAuth 2.0 или вебхук.

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

Канал CommerceML: что тянет на себе

CommerceML — это единый стандарт обмена в формате XML, и в версии 3.1 в один контейнер упакованы все документы конкретного заказа: сам заказ, оплаты, отгрузки. Именно поэтому CommerceML остаётся основным транспортом для товарной части.

На CommerceML лежит:

• выгрузка каталога — товары, торговые предложения, свойства, разделы;
• цены и типы цен — закупочная, розничная, скидочная;
• остатки по складам;
• заказы из Битрикс24 обратно в 1С — при экспорте из БУС в 1С для каждого заказа создаётся отдельный документ;
• документы частичных оплат и частичных отгрузок — функционал появился в модуле sale версии 16.0.13 и работает с 1С версии 6 и выше.

Ключевая механика: 1С выгружает XML-файл на сайт, Битрикс его разбирает пакетами и пишет в инфоблок. Сессия обмена состоит из четырёх шагов — checkauth, init, file, import. Между шагами можно вешать обработчики событий и вмешиваться в данные.

Главный плюс — пакетность и «родная» поддержка. Модуль обмена уже умеет разбирать XML, вести журнал, импортировать настройки и обновлять версии. Главный минус — жёсткая привязка к структуре XML: если в 1С нетиповая конфигурация или кастомные свойства, придётся либо дописывать выгрузку на стороне 1С, либо ловить события импорта на стороне Битрикса.

Канал REST API: где он выручает

REST API Битрикс24 — это HTTP-методы к сущностям, которых в CommerceML просто нет. Он поддерживает создание и модификацию объектов CRM, задач, публикацию сообщений в Живую ленту и встройку виджетов в карточку CRM.

Типовые задачи, где REST незаменим:

• Контрагенты. Синхронизация контрагентов из 1С идёт с сущностями «Контакты» и «Компании» в Битрикс24 — в CommerceML такого маппинга нет.
• Сделки и лиды. Сделка из 1С уходит в CRM через crm.deal.add, а не через XML-контейнер заказа.
• Задачи и уведомления. Менеджеру после отгрузки — задача в Битрикс24. Это только REST.
• Кастомные поля и смарт-процессы. Если у клиента сделки живут в смарт-процессе или есть свои поля, CommerceML про них не знает.

Авторизация — OAuth 2.0 или вебхук на портале. По опыту подрядчиков, для внутренней интеграции «1С → портал» чаще берут вебхук: он проще в настройке и не требует хранить refresh-токены. OAuth нужен, когда приложение ставится на порталы клиентов и должно работать от имени пользователя.

Слабое место REST — объём. Поштучные вызовы на каталоге в десятки тысяч SKU упираются в лимиты запросов и таймауты на стороне 1С. Гнать через REST то, что прекрасно едет одним XML-пакетом, — самая частая ошибка в самодельных интеграциях.

Настройка обмена 1С Битрикс24: пошагово от проверки версии до первого импорта

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

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

Дальше разберём каждый шаг.

1. Проверить версию модуля обмена в 1С через меню «Битрикс24» и наличие обновлений. В интерфейсе 1С есть отдельный пункт меню «Битрикс24» — там лежит «Информация о версии модуля обмена». Смотрим, что установлено, и сразу проверяем, нет ли обновлений. Если версия старая — не двигаемся дальше, пока не поймём, с чем имеем дело.
2. Если модуль 4.x — сначала обновить до последней 4.x, затем ставить 5.x/6.x/7.x. Прямой прыжок через мажорные версии не поддерживается: при переходе с 4.x нужно сначала поднять модуль до последней версии внутри ветки 4.x, и только после этого устанавливать 5.x, 6.x или 7.x. Пропустить этот шаг — значит получить нерабочий обмен и непонятные ошибки на ровном месте.
3. Настроить узел обмена на стороне сайта: тип цен, склады, соответствие свойств. Здесь задаётся, какие типы цен и склады участвуют в обмене и как свойства товаров из 1С ложатся на свойства инфоблока. Это самая кропотливая часть: ошибка в сопоставлении свойств потом вылезает как «цена не та» или «характеристика пропала».
4. Импорт/экспорт настроек обмена — сохранить профиль, чтобы переносить между средами. В модуле есть функция «Импорт/экспорт настроек обмена». Сохраняем профиль в файл — это ваш переносимый конфиг. Пригодится, когда нужно повторить те же настройки на dev, stage или у клиента.
5. Пробный прогон и проверка лога через «Открыть лог». Запускаем обмен на маленькой выгрузке — несколько десятков позиций, а не весь каталог. Смотрим результат в интерфейсе и открываем лог через «Открыть лог» (файл с логами за дату). Если в логе чисто — можно расширять выборку.

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

Интеграция 1С и Битрикс24 через REST API: что покрывает, а что нет

REST API становится единственным рабочим путём, когда штатный CommerceML-обмен упирается в границы своей модели. Классический сценарий: у клиента нетиповая конфигурация 1С, где часть сущностей живёт вне справочников «Товары» и «Контрагенты» — например, собственные регистры заявок, проектные сделки, сервисные обращения. Или задача не про каталог, а про CRM: нужно, чтобы менеджер в карточке сделки видел данные из учётной системы, а не ждал ночного обмена. Третий частый случай — встройка виджета в карточку CRM, чтобы прямо из Битрикс24 дёргать методы 1С.

Во всех этих случаях XML-выгрузка через CommerceML не подходит: она заточена под каталог, цены, остатки и заказы, а не под произвольные сущности. REST API Битрикс24 работает через HTTP-методы и OAuth 2.0, поэтому с ним можно ходить из 1С напрямую — из встроенного языка или через внешнюю обработку. Ниже разберём, что API закрывает из коробки, а где придётся строить обмен самим и считать запросы.

Что умеет REST API Битрикс24 из коробки

Методы REST API Битрикс24 сгруппированы по разделам, и для интеграции с 1С практически всегда нужны четыре группы:

• CRM — создание и модификация сделок, контактов, компаний, привязка товарных позиций к сделке через crm.deal.add, crm.contact.update, crm.company.list.
• Задачи — постановка и обновление задач, если 1С должна инициировать действия менеджеров (например, «позвонить по заявке»).
• Живая лента — публикация сообщений через log.blogpost.add, чтобы события из учётной системы попадали в ленту сотрудников.
• Встройка виджетов — регистрация приложения в интерфейсе карточки CRM, чтобы менеджер видел данные из 1С без переключения окон.

Этого набора хватает, чтобы закрыть CRM-часть интеграции: контрагенты и сделки синхронизируются в обе стороны, а не только выгружаются из 1С. Методы работают поверх стандартных HTTP-запросов, авторизация — через OAuth 2.0, об этом отдельно ниже.

Что REST API не заменяет

REST API — не замена CommerceML, а дополнение к нему. Массовый обмен каталогом, ценами и остатками остаётся за XML-выгрузкой: она передаёт данные пакетами, а REST — по одной сущности за запрос. Если попытаться гонять каталог через API, вы получите десятки тысяч HTTP-запросов на один прогон, каждый со своей авторизацией и задержкой сети.

То же с заказами и документами. Частичные оплаты и отгрузки, которые CommerceML 3.1 упаковывает в один контейнер на заказ, через REST придётся собирать вручную — отдельными вызовами на каждый документ. И с иерархией каталога: сопоставление разделов Битрикс и групп 1С в API не автоматизировано, логику маппинга пишете сами.

CommerceML Битрикс24: как читать XML и что изменилось в 3.1

CommerceML — единый стандарт обмена в XML, на котором держится вся штатная интеграция 1С с Битрикс24. Без понимания его структуры отладка превращается в гадание: лог показывает «ошибка импорта», а что именно пришло в файле — непонятно. У нас на проектах половина обращений по обмену решается на этапе «открой XML и посмотри, что там реально лежит». Сделать это можно, только если знаешь, где в контейнере искать нужный узел.

Когда читаешь файл глазами, картина становится очевидной: видно, пришёл ли заказ целиком, есть ли в нём оплата и отгрузка, не потерялись ли реквизиты контрагента по пути. Это тот же файл, который модуль обмена разбирает построчно, — просто вы смотрите на него раньше, чем парсер. Дальше разберём структуру контейнера заказа в 3.1, покажем, чем версия отличается от 2.10 и 1.0, и на что ориентироваться, когда официальные источники противоречат друг другу.

Структура контейнера CommerceML 3.1

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

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

Упрощённый фрагмент контейнера заказа

<?xml version="1.0" encoding="UTF-8"?>
<КоммерческаяИнформация ВерсияСхемы="3.1" ДатаФормирования="2025-01-15">
    <Документ>
        <Ид>ORDER-10482</Ид>
        <Номер>10482</Номер>
        <Дата>2025-01-15</Дата>
        <ХозОперация>Заказ товара</ХозОперация>
        <Роль>Продавец</Роль>
        <Валюта>RUB</Валюта>
        <Контрагенты>
            <Контрагент>
                <Ид>CONTR-501</Ид>
                <Наименование>ООО «Ромашка»</Наименование>
                <ИНН>7701234567</ИНН>
            </Контрагент>
        </Контрагенты>
        <Оплаты>
            <Оплата>
                <Ид>PAY-10482-1</Ид>
                <Сумма>15000.00</Сумма>
                <Дата>2025-01-15</Дата>
            </Оплата>
        </Оплаты>
        <Отгрузки>
            <Отгрузка>
                <Ид>SHIP-10482-1</Ид>
                <Дата>2025-01-16</Дата>
            </Отгрузка>
        </Отгрузки>
    </Документ>
</КоммерческаяИнформация>

Чем 3.1 отличается от 2.10 и 1.0

Версии CommerceML отличаются не косметикой, а моделью данных. В 1.0 речь шла в основном о ручном импорте — файл описывал каталог, и на этом его роль заканчивалась. 2.10 добавила нормальную работу с заказами и документами, но заказ, оплаты и отгрузки могли идти отдельными сущностями. 3.1 собрала всё в единый контейнер заказа — и именно эту схему использует обновлённый модуль обмена (в частности, поддержка обмена с 1С 6+ реализована в модуле sale 16.0.13).

Для практики это означает простую вещь: если у вас старый модуль, вы можете годами видеть 2.10 и не подозревать, что часть данных о частичных оплатах и отгрузках просто не доезжает. Обмен с частичными оплатами и отгрузками появился именно с версией 3.1 и модулем sale 16.0.13 — до этого сценарий «клиент оплатил половину» отрабатывал криво.

Как обмениваться заказами, счетами и сделками между CRM и 1С

Самый частый запрос на эту тему звучит так: «менеджер оформил сделку и выставил счёт в CRM, а бухгалтерия не видит документа в 1С». Логика простая — продажи живут в Битрикс24, а учёт, оплаты и отгрузки обязаны попадать в учётную систему, иначе бухгалтер вбивает всё руками. Штатный обмен закрывает эту связку без кастомного кода: сделка и счёт из CRM уезжают в 1С как документы, а обратно приходят статусы оплаты и отгрузки.

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

Цепочка выглядит так:

• менеджер создаёт сделку в CRM и привязывает к ней контрагента;
• из сделки выставляется счёт — он же будущий документ в 1С;
• модуль обмена выгружает заказ в 1С отдельным документом;
• в 1С заказ превращается в документ реализации/счёта и обрастает оплатами;
• обратно в CRM прилетают статус оплаты и отгрузки — менеджер видит актуальное состояние.

При экспорте из БУС в 1С для каждого заказа создаётся отдельный документ

Ключевая деталь, которую часто упускают при планировании структуры: при экспорте из БУС в 1С для каждого заказа создаётся отдельный документ. На «один сводный акт за день» рассчитывать не приходится — каждый заказ живёт своей жизнью, со своими оплатами и отгрузками.

Что это значит для проекта: поток из десятков заказов в день даст ровно столько же документов в 1С. Так задумано, но влияет на построение отчётов и на настройку обрезки журнала обмена (про неё — в отдельной секции). При обратном импорте статусов модуль ищет документ по идентификатору заказа, поэтому сопоставление должно быть стабильным: если заказ в CRM пересоздали с новым ID, связь с документом в 1С потеряется.

Частичные оплаты и частичные отгрузки: что появилось в sale 16.0.13

Долгое время обмен знал только про «оплачено целиком» и «отгружено целиком». Реальность сложнее: клиент вносит предоплату 30%, потом доплачивает остаток, отгрузка идёт двумя партиями. В обновлении модуля sale версии 16.0.13 реализован функционал обмена с 1С версии 6 и выше, включающий работу с документами частичных оплат и частичных отгрузок.

В одном контейнере заказа теперь может лежать несколько платёжных документов и несколько документов отгрузки, а не один флаг «оплачено». Модуль на стороне Битрикс раскладывает их по соответствующим оплатам и отгрузкам заказа. При типовом сценарии «одна оплата — одна отгрузка» разницы не заметите. А вот с предоплатами и поэтапной отгрузкой без этой версии модуля статусы просто не доедут.

Проверка версии перед включением обмена

В интерфейсе 1С версия модуля и наличие обновлений проверяются через меню «Битрикс24». Там же доступны функции «Информация о версии модуля обмена», «Открыть лог» и «Импорт/экспорт настроек обмена» — последнее удобно, когда переносите настройки между базами. И отдельно держите в голове правило перехода: при апгрейде с модуля версии 4.x сначала обновляете его до последней, и только затем ставите 5.x, 6.x или 7.x.

Синхронизация контрагентов: компании и контакты из 1С в CRM

Распространённая жалоба от отдела продаж звучит так: «мы завели клиента в CRM, а бухгалтерия всё равно просит реквизиты по телефону». Или наоборот — менеджер видит в сделке пустую карточку компании, хотя контрагент в 1С заведён ещё год назад. Третья типичная картина: одна и та же организация лежит в Битрикс24 три раза — «ООО Ромашка», «Ромашка ООО» и «ООО "Ромашка"» — потому что каждый менеджер заводил её руками. Дубли ломают воронку, аналитику по клиентам и историю сделок, а расхождение реквизитов приводит к счетам с неверным КПП.

Синхронизация контрагентов закрывает именно этот класс задач: справочник компаний и контактных лиц 1С становится источником истины, CRM — рабочим интерфейсом продаж. Задача идёт в связке с обменом заказами и сделками (об этом говорили выше) — без синхронных контрагентов сделка уезжает в 1С «в воздух», без привязки к реальному контрагенту. Настраивают её либо штатным модулем обмена, либо через REST API, если конфигурация нетиповая.

Ниже — что именно мапится.

• Контрагент 1С → Компания Битрикс24 — основная сущность с реквизитами, названием и привязкой к сделкам.
• Контактное лицо 1С → Контакт Битрикс24 — сотрудник контрагента, привязывается к компании как ответственное лицо.
• Реквизиты — ИНН, КПП, юридический и фактический адрес, ОГРН — переносятся в реквизиты компании.
• Договоры — переносятся как привязка сделки к конкретному договору контрагента.

Дальше — соответствие полей и то, на чём чаще всего рвётся маппинг:

REST API и OAuth 2.0: как авторизоваться из 1С

REST API Битрикс24 работает поверх обычного HTTP: методы вызываются POST-запросами к эндпоинтам вида /rest/<метод>.json, а авторизация строится на стандартных протоколах — входящем вебхуке или OAuth 2.0. Для 1С это означает, что специальный «мост» не нужен. Достаточно штатного объекта HTTPСоединение из платформы 1С:Предприятие 8.3 — он умеет и GET, и POST, и работу с заголовками, и разбор JSON-ответа.

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

Задача, которую приходится решать в первую очередь, — где взять и как безопасно хранить токен доступа. Вебхук даёт статичный токен, который живёт, пока его не отзовут вручную. OAuth 2.0 работает иначе: выдаёт пару access_token + refresh_token, причём первый живёт ограниченное время, а второй нужен для его продления. Если токен просрочен, Битрикс24 вернёт 401 Unauthorized — и обмен встанет до следующего ручного вмешательства. Поэтому в 1С обязательно нужен слой работы с токенами: место хранения, проверка срока жизни и автоматическое обновление. Ниже разберём схему авторизации, пример запроса и то, как организовать хранение в самой 1С.

Схема OAuth 2.0 для входящего вебхука и приложения

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

Приложение с OAuth 2.0 — путь для сценариев, где нужна долговременная стабильность и работа от имени портала, а не конкретного сотрудника. Схема такая:

• Приложение регистрируется в Битрикс24 и получает client_id и client_secret.
• Пользователь один раз проходит авторизацию — портал возвращает code на redirect-URI.
• 1С обменивает code на пару access_token и refresh_token методом oauth.token.
• Дальше все запросы идут с access_token, а по истечении срока жизни токен продлевается через refresh_token.

При смене области видимости или прав приложение придётся авторизовать заново — refresh_token не расширяет доступ. Для e-commerce-сценариев (сделки, счета, товары) обычно хватает базового набора crm, sale, catalog. Точный список зависит от того, какие методы вы вызываете.

Где хранить токены в 1С и как их обновлять

В 1С нет встроенного секретного хранилища уровня «ключница», поэтому токены обычно кладут в регистр сведений с ограниченным доступом. Мы используем отдельный регистр с измерениями «Портал» и «Тип токена» и ресурсами «Значение» и «ДатаИстечения». Читается из любого модуля, а защитить ролями просто: доступ только у администраторов и у служебного пользователя, под которым работает регламентное задание обмена.

Срок жизни токена проверяем перед каждым обращением к API, а не по расписанию. Логика простая: если ДатаИстечения меньше текущей даты плюс небольшой запас (например, пять минут на сетевые задержки) — сначала обновляем токен, потом выполняем основной запрос. Если API всё-таки вернул 401, повторяем один раз после принудительного обновления. Больше одной повторной попытки делать не стоит, иначе при неверных client_id/client_secret получите бесконечный цикл.

Обновление refresh_token в Битрикс24 одноразовое. Каждый вызов oauth.token возвращает новую пару, и старый refresh_token становится недействительным. Значит, запись в регистр нужно делать атомарно: сначала получить ответ, потом записать оба токена в одной транзакции. Если записать только access_token и упасть до записи refresh_token, интеграция потеряет возможность продления.

Где смотреть логи обмена и как их читать

Обмен «молча падает» — это когда в админке Битрикс24 последний импорт прошёл без красных ошибок, а на стороне 1С в это же время висит незакрытая сессия, и половина товаров не доехала. Первое, что мы делаем на проекте в такой ситуации: открываем лог за дату и ищем последний успешный шаг. Не гадаем, не перезапускаем обмен «на удачу» — сначала фиксируем, на каком именно этапе цепочка оборвалась. Это экономит часы: по логу сразу видно, был ли это отвал авторизации, ошибка разбора XML или таймаут на выгрузке картинок.

Логи — первое место, куда смотрит любой, кто чинит обмен. И одновременно то, что чаще всего игнорируют при настройке. Пока всё работает, о них не вспоминают; когда ломается — без них отладка превращается в перебор гипотез. Ниже разберём, что доступно прямо в модуле обмена и где физически лежат данные.

В модуле обмена на стороне Битрикс24 доступны три функции, с которых стоит начать диагностику:

• «Информация о версии модуля обмена» — покажет текущую версию; если она старая, часть проблем может быть уже починена в обновлении.
• «Открыть лог» — открывает файл с логами за конкретную дату; это основной инструмент, когда нужно понять, что произошло в момент сбоя.
• «Импорт/экспорт настроек обмена» — пригодится, чтобы сравнить рабочий конфиг с проблемным или перенести настройки на стенд.

Первые два пункта закрывают 80% задач по разбору падений. К третьему обычно возвращаются, когда нужно воспроизвести чужую конфигурацию у себя.

Файл лога vs регистры 1С: где что лежит

Здесь важный нюанс, на котором спотыкаются почти все. Лог обмена в Битрикс24 и журнал обмена в 1С — это два разных места, и лежат они по-разному.

На стороне Битрикс24 лог — это файл за дату: именно его открывает пункт «Открыть лог» в модуле. Он содержит пошаговую картину сессии обмена, от авторизации до финального импорта. Именно сюда мы смотрим, когда нужно понять, на каком шаге цепочка оборвалась.

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

Если обмен упал, не ограничивайтесь одной стороной. Файл в Битрикс24 покажет, что увидел приёмник, а регистры 1С — что отправитель считал нужным передать. Расхождение между ними и есть источник проблемы.

Обрезка журнала обмена в 1С: когда без неё база распухает

Типичный сценарий: обмен настроен, заказы ходят, контрагенты синхронизируются — и вдруг через несколько месяцев работы сеансы обмена начинают занимать всё больше времени, а размер базы 1С растёт, хотя номенклатура не менялась. Смотришь в регистры и находишь журнал обмена, который копится с самого первого запуска и никто его никогда не чистил. Журнал модуля интеграции хранится в регистрах базы 1С, и при активном обмене (а в e-commerce он идёт каждые 15–30 минут) записи о каждой сессии, каждом пакете, каждом изменении накапливаются быстрее, чем вы успеваете о них вспоминать. По опыту подрядчиков и обсуждениям на Infostart, именно этот журнал — первая причина деградации обмена на проектах, где каталог перевалил за 20 000 SKU и обмен работает в постоянном режиме.

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

Что имеет смысл чистить в первую очередь:

• Регистры журнала обмена — основной источник роста: записи о сессиях, пакетах, статусах и ошибках.
• Старые сессии обмена — завершённые и аварийно прерванные, которые уже никто не будет разбирать.
• Вложения в сообщениях — файлы, приложенные к документам обмена, если они больше не нужны для аудита.

Как настроить обрезку по расписанию в 1С

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

Разумный срок хранения зависит от того, как вы разбираете инциденты. Если ошибки обмена вы смотрите в течение дня — хватит 7–14 дней. Если журнал нужен для аудита или разбора старых расхождений — ставьте 30–60 дней, но не больше: дальше это уже архив, а не рабочий инструмент. Регламентное задание лучше ставить на ночь, когда обмен не идёт, иначе удаление может пересечься с активной сессией и заблокировать таблицы.

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

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

Представим каталог на 30 000 SKU. Полная выгрузка из 1С в Битрикс — это часы работы: XML собирается целиком, передаётся целиком, разбирается целиком. При этом реально изменилось за ночь, скажем, 40 позиций: поменялась цена, пришёл новый остаток, кто-то поправил название. Гонять весь каталог ради сорока записей — это и время, и нагрузка на обе системы, и риск, что на середине обмена что-то упадёт и вы получите наполовину обновлённый каталог. В проектах с активным импортом, где цены и остатки меняются несколько раз в день, полная выгрузка вообще становится узким горлышком: обмен не успевает завершиться до следующего запуска.

Механизм регистрации изменений решает именно эту задачу: 1С запоминает, что менялось с момента последнего сеанса, и передаёт только дельту.

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

Механизм регистрации изменений в линейке 2-й версии модуля

В линейке 2-й версии модуля интеграции (по опыту подрядчиков, работающих с ней) реализован штатный механизм регистрации изменений: платформа сама отслеживает, какие объекты правились после последнего обмена, и формирует выгрузку только по ним. На стороне Битрикс это выглядит так же, как обычный обмен — те же шаги checkauth, init, file, import, — но в XML приходит не весь каталог, а только изменившиеся узлы.

Что это меняет на практике:

• выгрузка сокращается до реального объёма правок, а не до размера каталога;
• сеанс обмена укладывается в окно между запусками, даже если расписание частое;
• снижается нагрузка на базу 1С и на приёмник — меньше парсинга, меньше транзакций;
• уменьшается риск, что обмен оборвётся на середине и оставит каталог в половинчатом состоянии.

Регистрация изменений — не «магическая кнопка», а часть линейки 2-й версии модуля. Если у вас стоит старый модуль обмена, никакие настройки узла его не включат: сначала нужно перейти на актуальную линейку, а уже потом рассчитывать на дельту.

Что нужно, чтобы он заработал: платформа 1С 8.3.12+ и правильные настройки узла

Первое и главное требование — платформа 1С версии не ниже 8.3.12. Ниже этой версии механизм регистрации изменений в линейке 2-й версии модуля недоступен в принципе, и никакая настройка узла обмена этого не обойдёт.

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

• версию платформы 1С на соответствие требованию 8.3.12+;
• актуальность линейки модуля обмена (без перехода на 2-ю версию дельты не будет);
• корректность настроек узла — что точка отсчёта обновляется после каждого успешного сеанса;
• логи обмена — не было ли ошибок, из-за которых точка отсчёта могла «застрять».

И ещё про журнал обмена: чем чаще идут сеансы, тем быстрее он растёт. Обрезку стоит настроить заранее, а не когда база начнёт пухнуть.

Кастомная иерархия каталога: как сопоставить разделы Битрикс и 1С

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

Типичный сценарий: в 1С группы лежат по учётному признаку — «Продукция», «Сырьё», «Полуфабрикаты», а на сайте нужно «Готовые блюда», «Наборы для дома», «Подарочные боксы». Или наоборот — в 1С плоская выгрузка на сотни групп, а на витрине пять верхнеуровневых категорий с вложенностью. Прямое сопоставление по имени раздела здесь не работает: имена не совпадают, вложенность разная, а часть групп 1С вообще не должна попадать в публичный каталог. Когда к нам приходят с такой задачей, мы почти всегда делаем кастомный маппинг — таблицу соответствия «группа 1С → раздел Битрикс», по которой обработчик обмена перевешивает раздел в нужного родителя сразу после создания. Это комбинируется с фильтрацией выгрузки (об этом ниже по статье) и с ручной сортировкой разделов: маппинг задаёт родителя, а порядок и SEO-поля менеджер правит в админке как обычно.

Работаем в четыре шага:

1. Выгрузить из 1С полный список групп с их GUID — это будущие ключи маппинга, привязываться к именам нельзя, они меняются.
2. Сопоставить каждую группу с целевым разделом Битрикс: либо с существующим (по ID), либо с новым, который создаст обмен.
3. Зафиксировать маппинг в конфиге модуля или отдельной таблице — не в коде обработчика, иначе при каждом обновлении модуля придётся править заново.
4. Обработать новые группы: всё, чего нет в маппинге, складывать в раздел-заглушку и логировать — чтобы менеджер видел, что появилось в 1С и не попало на витрину.

Технически перевешивание делается на событии OnAfterIBlockSectionAdd — раздел уже создан обменом, у нас есть его ID и XML_ID (это GUID группы 1С). Остаётся найти нужного родителя по маппингу и обновить раздел:

Ключевое здесь — проверка на уже установленного родителя: без неё каждый повторный импорт будет дёргать SectionTable::update и плодить лишние записи в истории изменений. Маппинг вынесен в отдельный массив, который в реальном проекте подтягивается из опций модуля или из своей таблицы — так менеджер может править соответствия без правки кода. Если групп 1С много и они часто меняются, тот же обработчик стоит дополнить записью в лог непокрытых GUID — получится рабочий список для донастройки.

Самые частые ошибки, которые ломают обмен 1С и Битрикс24

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

Ниже пять сценариев, которые мы встречаем чаще всего. Мы сводим их в одну таблицу «грабля → причина → решение»: удобно использовать как чеклист при разборе инцидента. Если обмен падает прямо сейчас, начните с той строки, чей симптом совпадает с вашим.

Платежи, ФФД 1.2 и связка с T-Bank в обмене

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

В проектах с активными онлайн-продажами мы почти всегда сталкиваемся с одной и той же картиной: платежи на сайте работают, обмен заказами работает, а вот оплаты в 1С не долетают. Причина обычно не в самой интеграции, а в версии платёжного модуля и в том, как он передаёт данные о чеках. Когда к нам приходят с задачей «настроить интеграцию платежного модуля T-Bank с 1С-Битрикс», разбираться приходится сразу на трёх уровнях: сам платёжный модуль, механизм обмена и формат фискальных документов.

Ниже — что важно проверить до начала отладки обмена, и как оплата из T-Bank физически попадает в 1С.

• Версия 1С-Битрикс — поддерживаются релизы 16–25; на более старых сборках модуль просто не установится.
• Файл платёжного модуля — актуальная версия v3.0.1; с ней приходит поддержка ФФД 1.2.
• Формат фискальных документов ФФД 1.2 — обязателен для маркированных товаров и для передачи кодов маркировки в чеке.
• Модуль обмена на стороне 1С — для работы с частичными оплатами и отгрузками нужна версия 6 и выше (функционал появился в обновлении модуля sale 16.0.13).

Как оплата из T-Bank попадает в 1С через CommerceML 3.1

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

Поток данных выглядит так: платёжный модуль T-Bank ловит callback от банка, помечает заказ оплаченным и записывает в него данные транзакции. Дальше в дело вступает модуль обмена — он собирает CommerceML-пакет, куда попадает и информация об оплате, и передаёт его в 1С. На стороне 1С документ раскладывается на заказ и связанные с ним платёжные документы.

Если у вас частичные оплаты — предоплата, доплата, оплата бонусами — именно CommerceML 3.1 и модуль обмена версии 6+ позволяют провести их корректно, отдельными документами. Для магазинов, где оплата всегда одна и полная, этот механизм не критичен, но закладывать его стоит сразу: переделывать обмен под частичные оплаты постфактум заметно дороже.

Что делать, если у вас нетиповая конфигурация 1С

Штатный модуль обмена из коробки рассчитан на две конфигурации: «1С:Розница» ред. 2.3 и «1С:Бухгалтерия 8» ред. 3.0. Это официально поддерживаемые связки — под них написаны обработчики выгрузки, для них же проверяются совместимые версии модуля. Пока проект живёт на одной из этих конфигураций, вопросов не возникает: ставим модуль, настраиваем узел, гоняем обмен.

Другое дело — нетиповая конфигурация. Управление торговлей, ERP, отраслевые решения, доработанные бухгалтерии с собственными регистрами, самописные базы на платформе 8.3. Здесь штатный путь обрывается. Модуль формально можно установить, но он не найдёт в базе привычных объектов: справочники называются иначе, реквизиты лежат в других местах, а часть сущностей вообще не имеет аналога в типовой модели.

Обмен либо падает на этапе выгрузки, либо выгружает пустоту, либо работает частично. Последнее самое неприятное, потому что молча.

В нашей практике проекты с нетиповыми конфигурациями встречаются регулярно: клиенты уходят с «Розницы» на «УТ 11», доращивают бухгалтерию под свои процессы, держат отраслевые решения. И каждый раз встаёт один и тот же вопрос — как связать эту базу с Битрикс24, не переписывая конфигурацию под типовую. Универсального ответа «поставь галочку» здесь нет, но есть три рабочих подхода, из которых мы выбираем под конкретный проект.

• Адаптировать типовой модуль обмена — переписать обработчики выгрузки под объекты вашей конфигурации: плюс в том, что остаётся штатный протокол CommerceML и весь его инструментарий, минус — работы много и при каждом обновлении модуля правки нужно переносить заново.
• Написать свой обмен на REST API — отказаться от CommerceML и работать напрямую с методами Битрикс24: плюс в полной свободе и независимости от версий модуля, минус — нужно самим реализовать сопоставление сущностей, очереди и обработку ошибок.
• Использовать промежуточную базу — выгружать данные из нетиповой 1С в типовую (например, в «Бухгалтерию 8»), а уже оттуда гнать штатным обменом: плюс в минимуме правок на стороне Битрикс24, минус — появляется лишнее звено, которое нужно поддерживать и синхронизировать.

Когда мы идём в свой модуль, а не в штатный обмен

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

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

Промежуточная база — компромисс для случаев, когда на стороне Битрикс24 менять ничего не хочется, а нетиповая 1С умеет выгружать данные в понятном формате. Мы поднимаем типовую базу как буфер, настраиваем выгрузку из нетиповой в неё, а дальше работает штатный обмен. Минус очевиден: появляется ещё одна база, которую нужно обновлять и держать в консистентном состоянии.