Обмен данными между базами 1С: что происходит внутри и как этим управлять

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

В типовых конфигурациях (БП 3.0, УТ 11, ЗУП 3.1, КА, ERP) всё это скрыто за помощником: Администрирование → Синхронизация данных. Флажок «Синхронизация данных» включает механизм, а настройки создаются кнопкой «Новая синхронизация данных». Каждый слой этой схемы ломается по-своему, и чинить его нужно в своём месте.

Каналы связи и виды обмена в 1С

Сначала решают, как базы будут «видеть» друг друга. От канала зависит скорость, надёжность и то, кто запускает обмен.

Через каталог, FTP и почту передаётся файл-сообщение. Его забирает другая сторона по своему расписанию. Прямое подключение и веб-сервис позволяют выполнить выгрузку и загрузку за один сеанс с одной стороны.

Какие бывают схемы обмена

• 🔁 Распределённая информационная база (РИБ). Одна конфигурация, главный узел и подчинённые. Передаются данные и изменения конфигурации. Типично для филиалов.
• 🔄 Универсальный обмен через формат EnterpriseData. Разные конфигурации: БП ↔ УТ, БП ↔ ЗУП, УТ ↔ Розница. Данные переводятся в общий XML-формат и обратно.
• 📤 Обмен по правилам конвертации. Классический вариант для доработанных и нетиповых конфигураций. Правила готовят в конфигурации «Конвертация данных ».
• 📥 Односторонняя выгрузка. Например, из ЗУП в БП уходят начисления и проводки, обратно идёт минимум справочников.

Как планы обмена отслеживают изменения

План обмена — объект метаданных. Его элементы — узлы: «эта база» и каждая база-партнёр. Для каждого объекта из состава плана платформа ведёт служебную таблицу изменений.

Что хранится в таблице изменений

Запись в ней — это пара «объект + узел» и номер сообщения, с которым объект ушёл. Пока номер пустой, объект ждёт отправки. После выгрузки туда пишется номер сообщения, но запись остаётся до подтверждения.

У узла есть два счётчика:

• 📨 номер отправленного — последний пакет, который ушёл из этой базы;
• 📬 номер принятого — последний пакет, загруженный от партнёра.

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

Авторегистрация и программная регистрация

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

Программно это делают так:

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

// Выбрать изменения для выгрузки в сообщение с номером НомерСообщения
Выборка = ПланыОбмена.ВыбратьИзменения(Узел, НомерСообщения);

// Снять регистрацию после подтверждения приёма
ПланыОбмена.УдалитьРегистрациюИзменений(Узел, НомерСообщения);

При загрузке пакета объекты пишутся с флагом ОбменДанными.Загрузка = Истина. В этом режиме не срабатывают проверки заполнения и часть обработчиков, а записанный объект не регистрируется обратно на узел-отправитель. Поэтому изменения не гоняются по кругу.

Коллизии: что будет, если объект изменили в двух базах

Коллизия возникает, когда один и тот же объект поменяли в обеих базах между сеансами обмена. Например, в УТ поправили адрес контрагента, а в БП — его КПП. Пришедший пакет перезапишет одно из изменений.

Правило по умолчанию в РИБ

В распределённой базе приоритет у главного узла. Платформа вызывает в модуле плана обмена обработчики ПриПолученииДанныхОтГлавного и ПриПолученииДанныхОтПодчиненного. В них параметр ПолучениеЭлемента решает судьбу объекта:

• ✅ ПолучениеЭлементаДанных.Принять — записать пришедшую версию;
• ⛔ ПолучениеЭлементаДанных.Игнорировать — оставить свою;
• ⚙️ ПолучениеЭлементаДанных.Авто — поведение платформы: изменения от главного узла принимаются, конфликтующие изменения от подчинённого отклоняются.

Параметр ОтправкаНазад позволяет снова зарегистрировать свою версию и отправить партнёру. Так база «настаивает» на своём варианте.

Коллизии в типовых синхронизациях

В типовых конфигурациях на БСП конфликт не теряется молча. Отклонённые версии и проблемы загрузки попадают в список предупреждений синхронизации. Его открывают по ссылке на форме Администрирование → Синхронизация данных, рядом с настройкой обмена. Там видно объект, версию и причину, а нужный вариант можно принять вручную.

Ещё один механизм — даты запрета загрузки. В настройке синхронизации можно запретить загрузку изменений за закрытый период. Пакет с правкой документа из закрытого квартала не перепишет проведённые данные, а уйдёт в предупреждения.

Чтобы коллизий было меньше, договоритесь о «владельце» данных:

1. Справочник номенклатуры ведут в одной базе, во второй его только читают.
2. Контрагентов создают в учётной базе, торговая база их получает.
3. Документы одного типа вводят только в одной базе. Например, реализации — в УТ, а в БП они приходят по обмену.

Правила регистрации и конвертации: что уходит в другую базу

За состав и форму передаваемых данных отвечают два набора правил.

Правила регистрации объектов (ПРО)

Они отвечают на вопрос «что и когда отправлять». Например: регистрировать документ реализации только если он проведён и организация входит в список отбора узла. Или не отправлять номенклатуру, пока не заполнен вид номенклатуры.

В типовых синхронизациях эти правила частично выведены в настройки помощника:

• 📅 дата начала выгрузки документов;
• 🏢 отбор по организациям;
• 📦 отбор по складам или видам документов;
• 🔀 способ выгрузки — все документы или только используемые справочники.

Поменять отбор задним числом недостаточно. Уже зарегистрированные объекты останутся в таблице изменений до отправки.

Правила конвертации объектов (ПКО)

Они отвечают на вопрос «как превратить объект базы А в объект базы Б». Свойство-источник сопоставляется со свойством-приёмником, а для ссылок задаётся поиск: по уникальному идентификатору, коду, ИНН или наименованию.

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

Типичная схема сопоставления реквизитов при обмене БП и торговой базы:

Первый запуск синхронизации в типовой конфигурации

Порядок для пары баз, например БП 3.0 и УТ 11:

1. Сделайте резервную копию обеих баз (выгрузку .dt или копию на SQL-сервере).
2. Задайте разные префиксы информационных баз.
3. В каждой базе включите флажок «Синхронизация данных» в разделе Администрирование → Синхронизация данных.
4. В одной из баз нажмите «Новая синхронизация данных» и выберите конфигурацию-партнёра.
5. Укажите канал связи, параметры подключения и пользователя, от имени которого пойдёт обмен.
6. Задайте правила отправки: дату начала, организации, состав документов.
7. Сопоставьте уже существующие справочники.
8. Выполните первый обмен вручную и проверьте предупреждения.
9. Настройте расписание автоматической синхронизации.

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

Ошибки синхронизации: где смотреть и что делать

Все сбои обмена попадают в журнал регистрации. Откройте Администрирование → Обслуживание → Журнал регистрации и отберите события по слову «Обмен данными». Там видно направление, узел, текст ошибки и объект, на котором загрузка остановилась.

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

Как посмотреть, что уйдёт в следующем пакете

В типовых конфигурациях на форме синхронизации есть команда просмотра состава отправляемых данных. Она показывает зарегистрированные объекты по типам. Отсюда же можно добавить объект к отправке или снять с регистрации лишнее.

Это главный инструмент, когда «документ не доходит». Если документа нет в составе — он не зарегистрирован, смотрите отборы и правила регистрации. Если есть, но не загружается — ищите ошибку в журнале регистрации базы-приёмника.

Как ускорить синхронизацию данных

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

Сократить то, что регистрируется

• ✂️ Поставьте дату начала выгрузки. Документы трёхлетней давности в торговой базе не нужны.
• 🏢 Включите отбор по организациям, если в базе их несколько, а партнёру нужна одна.
• 🚫 Не включайте авторегистрацию регистров сведений и оборотных регистров в своих доработках, если их можно пересчитать в приёмнике.
• 🧹 Если узел больше не используется, удалите его настройку. Иначе платформа продолжит копить для него изменения.

Настроить частоту и момент запуска

Обмен раз в сутки собирает огромный пакет и идёт долго. Обмен раз в 10–15 минут передаёт маленькие порции и почти незаметен. Расписание задают в сценарии синхронизации: это регламентное задание, которое запускает обмен по нужным узлам.

Это ориентиры, а не правило. Если пакет не успевает уйти до следующего запуска, увеличьте интервал.

Обслуживание серверной стороны

На клиент-серверной базе таблицы изменений живут в той же СУБД. Если обмен долго не шёл, в них копятся сотни тысяч записей, и выборка замедляется.

Порядок действий:

1. Выполните обмен до конца, чтобы квитирование сняло отправленное.
2. Обновите статистику и перестройте индексы в СУБД штатным планом обслуживания.
3. Если в таблице изменений остался мусор по ненужным объектам, снимите регистрацию через просмотр состава отправляемых данных.

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