Обмен через план обмена и узлы

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

Что такое план обмена и узел

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

Когда вы настраиваете обмен каталогом и заказами, типовые конфигурации («Управление торговлей», «Комплексная автоматизация», «1С:УНФ») используют для этого специальный план обмена — например, ОбменССайтом или узел вида «Обмен с сайтом (CommerceML)». Именно этот узел хранит адрес сайта, логин, тип цен, склад и настройки выгрузки.

Регистрация изменений и почему это важно

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

Практические следствия, которые важно держать в голове:

• если объект не входит в состав плана обмена, его изменения не регистрируются и он никогда не уедет на сайт, сколько бы вы ни жали «Выгрузить»;
• если регистрация по объекту уже снята (передана), повторно он выгрузится только после нового изменения или после ручной регистрации;
• изменения, сделанные до создания узла или загрузки конфигурации с новым составом плана, не попадают в очередь автоматически.

Посмотреть и вручную поправить очередь можно через типовую обработку Регистрация изменений для обмена данными (доступна в режиме «Все функции» или в разделе администрирования) — там видно, сколько объектов «висит» к отправке по узлу.

Номера сообщений и квитирование

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

Механизм защищает от потери данных: пока квитанция не пришла, изменения остаются в очереди и уйдут повторно. Обратная сторона — если счётчики «разъехались» (например, базу разворачивали из копии, а сайт остался со старым номером), обмен может либо гнать одни и те же данные по кругу, либо, наоборот, считать изменения переданными и молчать.

Первоначальная и полная выгрузка

При первом обмене или после серьёзных сбоев используют полную выгрузку: в настройках узла обмена с сайтом снимают признак выгрузки только изменений (в CommerceML это флаг вида «Выгружать только изменения» / выгрузка изменённых объектов). Тогда 1С заново регистрирует все объекты состава плана и отправляет каталог целиком.

Типовой сценарий безопасного перезапуска обмена «с нуля»:

1. остановить расписание автоматического обмена, чтобы сеансы не наложились;
2. в карточке узла временно включить полную выгрузку;
3. при необходимости через обработку регистрации изменений принудительно зарегистрировать всю номенклатуру для узла;
4. провести один полный сеанс и убедиться, что сайт корректно принял import.xml и offers.xml;
5. вернуть режим «только изменения» и включить расписание.

РИБ, узлы и место сайта в схеме

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

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

• Узел = сайт (витрина). Один адрес, один логин, один тип цен/склад по умолчанию.
• Свой состав данных. В разных узлах можно отдавать разные группы номенклатуры и типы цен.
• Свои счётчики. Сброс одного узла не задевает остальные.

Диагностика проблем на уровне узла

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

1. Открыть карточку узла обмена с сайтом и сверить адрес, логин, тип цен и склад — банальная ошибка настройки маскируется под «обмен не работает».
2. Посмотреть очередь регистрации для узла: если она пустая, значит изменения не регистрируются (объект вне состава плана или обмен велся другим узлом).
3. Сверить номера сообщений отправленного и принятого — резкое расхождение указывает на восстановление из копии или ручное вмешательство.
4. Проверить состав плана обмена в конфигурации: входят ли нужные справочники и документы, включена ли авторегистрация.

Если после этих шагов картина не сходится, дальше уже смотрят логи и XML-выгрузку на стороне Битрикса — но в большинстве случаев корень в узле и его очереди.

Итог

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

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