Узел плана обмена в 1С:Предприятии 8.3 — как устроен и как им управлять

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

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

Какую роль узел играет в обмене данными 1С

План обмена — объект конфигурации в ветке Планы обмена. Он описывает правила: какие объекты участвуют в обмене и регистрируются ли их изменения автоматически. Узлы — это его данные, конкретные участники.

Через узел платформа решает три задачи:

• 📝 учёт изменений. Когда вы записываете документ, платформа ставит в таблицу изменений отметку «этот объект надо отправить узлу N»;
• 📨 нумерация сообщений. У узла хранятся номер последнего отправленного и последнего принятого сообщения. По ним база понимает, что корреспондент уже получил;
• 🔁 адресация. Выгрузка всегда идёт «для узла»: берутся только изменения, зарегистрированные для него.

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

Чем «этот узел» отличается от остальных

Код «этого узла» должен совпадать с кодом, под которым вашу базу знает корреспондент. Расхождение кодов — частая причина того, что обмен «не видит» входящие пакеты.

Виды узлов: распределённая база и универсальный обмен

Узлы бывают двух принципиально разных типов. Тип задаёт не сам узел, а план обмена, которому он принадлежит.

Узлы распределённой информационной базы (РИБ)

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

Узлы РИБ выстраиваются деревом:

• 🏢 главный узел — центральная база, в ней дорабатывают конфигурацию;
• 🏬 подчинённые узлы — базы филиалов или магазинов. В подчинённом узле конфигурацию менять нельзя, она приходит из главного.

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

Узлы универсального обмена

Флажок РИБ выключен. Конфигурации участников могут быть разными: Бухгалтерия и Управление торговлей, ЗУП и Бухгалтерия, ваша база и сайт. Состав и преобразование данных задают правила конвертации, обычно в формате EnterpriseData.

Здесь нет главного и подчинённого. Узлы равноправны, каждый отвечает за свою часть данных.

Как выбрать схему

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

Набор полей узла частично стандартный, частично задаётся разработчиком.

Стандартные реквизиты

• 🔑 Код — уникальный идентификатор участника. Длину задают в свойствах плана обмена;
• 🏷️ Наименование — понятное имя для людей, например «Магазин на Ленина»;
• 📤 НомерОтправленного — номер последнего сообщения, которое база отправила этому узлу;
• 📥 НомерПринятого — номер последнего сообщения, принятого от этого узла;
• 🗑️ ПометкаУдаления — как у справочника.

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

Реквизиты разработчика и отборы

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

В интерфейсе БСП эти отборы настраивают в форме синхронизации: Администрирование → Синхронизация данных → Настройки синхронизации данных, далее открыть нужную настройку и перейти к составу отправляемых данных.

Состав плана обмена и авторегистрация

В Конфигураторе у плана обмена есть кнопка Состав. Для каждого объекта метаданных указано:

1. Входит ли он в обмен вообще.
2. Включена ли авторегистрация (Разрешить или Запретить).

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

Как создать узел и подключить нового участника

Узел-корреспондент почти никогда не заводят руками в списке плана обмена. В типовых конфигурациях его создаёт помощник настройки синхронизации, который заодно заполняет отборы и настраивает транспорт.

Порядок для универсального обмена между двумя базами на БСП:

1. В первой базе откройте Администрирование → Синхронизация данных и включите флажок синхронизации, если он снят.
2. Задайте префикс этой базы. Он попадёт в номера документов, чтобы документы разных баз не путались.
3. Перейдите в настройки синхронизации и создайте новую, выбрав программу-корреспондент из списка.
4. Укажите способ связи: общий сетевой каталог, FTP, электронная почта или прямое подключение через интернет .
5. Настройте отборы: организации, склады, дату начала выгрузки.
6. Помощник сохранит файл настроек или передаст их по прямому подключению. Во второй базе продолжите настройку с этими параметрами.

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

Первая синхронизация

Первый обмен самый тяжёлый: помощник регистрирует к отправке все подходящие объекты, а затем сопоставляет одинаковые справочники по ИНН, кодам и наименованиям. Запускайте его вне рабочего времени и проверьте сопоставление номенклатуры и контрагентов до загрузки документов. Ошибка на этом шаге даёт задвоенные элементы, которые потом придётся объединять.

Как через узел идут регистрация и выгрузка данных

Цикл обмена с одним узлом выглядит так:

1. Пользователь записывает объект. Платформа (или подписка) добавляет запись в таблицу изменений: объект + узел, номер сообщения пока пустой.
2. При выгрузке база увеличивает НомерОтправленного на единицу и проставляет этот номер всем выгружаемым записям регистрации.
3. В сообщение кладутся данные и НомерПринятого — подтверждение того, что база уже получила от корреспондента.
4. Корреспондент загружает пакет и запоминает его номер у себя как принятый.
5. В следующем ответном сообщении корреспондент возвращает этот номер. Тогда исходная база удаляет записи регистрации с номером не больше подтверждённого.

Как посмотреть зарегистрированные изменения

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

ВЫБРАТЬ
    Изменения.Ссылка,
    Изменения.Узел,
    Изменения.НомерСообщения
ИЗ
    Справочник.Номенклатура.Изменения КАК Изменения
ГДЕ
    Изменения.Узел = &Узел

Пустой НомерСообщения означает, что объект ещё ни разу не выгружался. Заполненный — выгружен, но подтверждения пока не было.

Ручная регистрация и снятие регистрации

В коде используют методы менеджера ПланыОбмена:

// зарегистрировать объект к отправке узлу
ПланыОбмена.ЗарегистрироватьИзменения(Узел, Объект);

// снять всю регистрацию для узла
ПланыОбмена.УдалитьРегистрациюИзменений(Узел);

Без кода удобнее обработка регистрации изменений для обмена из набора инструментов разработчика: она показывает, сколько объектов каждого типа ждёт отправки, и позволяет добавить или снять регистрацию выборочно.

Ошибки узлов обмена и как их диагностировать

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

Восстановление обмена после отката базы

Самый неприятный случай: одну из баз восстановили из копии недельной давности. Номера сообщений сторон разъехались.

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

1. Остановите автоматический обмен по расписанию в обеих базах.
2. Сравните поля НомерОтправленного и НомерПринятого у соответствующих узлов в обеих базах.
3. В восстановленной базе зарегистрируйте к отправке всё, что изменилось после даты копии.
4. В базе-корреспонденте сделайте то же для объектов, которые восстановленная база потеряла.
5. Выполните обмен вручную и проверьте журнал регистрации.

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

Как ускорить обмен в распределённой системе

Главный враг скорости — разросшиеся таблицы изменений. Каждая запись регистрации — строка в таблице СУБД, и выгрузка их перебирает.

Что реально помогает:

• 🧹 удалить мёртвые узлы. Филиал закрылся, а узел остался, и на него регистрируется каждое изменение базы. Сначала снимите регистрацию методом УдалитьРегистрациюИзменений, затем удалите узел;
• 🎯 сузить отборы. Узлу магазина не нужны документы других складов и прошлых лет. Дата начала выгрузки и фильтр по организации сокращают объём в разы;
• ⏱️ подобрать частоту. Обмен раз в 5 минут для 20 узлов нагружает сервер больше, чем раз в 30 минут. Для большинства розничных сетей хватает 15–30 минут;
• 📦 не регистрировать лишнее. Регистры, которые корреспондент может пересчитать сам, лучше не гонять через обмен;
• 🔄 следить за подтверждениями. Если корреспондент не возвращает ответные пакеты, регистрация не очищается и растёт бесконечно. Обмен должен идти в обе стороны.

Для проверки соберите запросом количество записей в таблицах изменений по узлам. Узел с сотнями тысяч незакрытых записей сразу виден.

Когда отделить подчинённый узел

Бывает, что филиал продали или он ушёл на отдельную базу. Подчинённый узел РИБ можно превратить в самостоятельную базу: в нём выполняют ПланыОбмена.УстановитьГлавныйУзел(Неопределено). После этого конфигурацию можно менять, а приём изменений от бывшего главного узла прекращается.

Частые вопросы