Почему при успешной синхронизации УТ 11 и БП 3.0 объекты не снимаются с регистрации и как это исправить?

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

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

Как работает механизм «рукопожатия» (квитирования) в 1С

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

1. Выгрузка пакета данных из источника (УТ): При отправке данных УТ формирует файл обмена и присваивает ему уникальный порядковый номер сообщения (например, НомерОтправленного = 15). Все отправленные объекты фиксируются в транзакции как привязанные к сообщению № 15.
2. Загрузка и фиксация в приемнике (БП): БП считывает этот файл. Если чтение и запись объектов проходят успешно, БП записывает у себя в настройках узла обмена, что последнее успешно принятое сообщение от УТ имеет номер 15. Этот параметр называется НомерПринятого.
3. Отправка подтверждения (квитанции): При следующем сеансе обмена (или в конце текущего при двустороннем COM-соединении) БП формирует ответный пакет для УТ. Даже если из БП в УТ не должны передаваться никакие документы, БП обязательно отправляет служебный заголовок, в котором указывает: «Я успешно приняла твое сообщение № 15».
4. Снятие с регистрации в источнике (УТ): УТ считывает ответный пакет от БП, видит подтверждение получения сообщения № 15 и только после этого автоматически снимает с регистрации все объекты, которые были отправлены в пакете № 15 и более ранних.

Если этот цикл разрывается на любом этапе, УТ «не знает», дошли ли данные до БП, и в целях безопасности оставляет их зарегистрированными, чтобы отправить повторно при следующем сеансе. Если в мониторе обмена УТ вы видите статус «Данные загружены: Никогда», это главный признак того, что УТ ни разу не смогла успешно прочитать квитанцию от БП.

Решение 1. Ручная настройка формата обмена (EnterpriseData)

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

Проанализируем алгоритм ручной настройки формата обмена в «1С:Бухгалтерия предприятия»:

1. Перейдем в базу БП 3.0 с правами администратора.
2. Откроем раздел «Администрирование», далее перейдем в пункт «Синхронизация данных» и выберем «Настройки синхронизации».
3. Откроем карточку нашей настройки обмена с УТ.
4. Перейдем на вкладку «Служебная информация». Обратите внимание, что в некоторых версиях конфигураций эта вкладка скрыта по умолчанию. Для ее отображения может потребоваться нажать кнопку Еще -> Изменить форму и установить флажок напротив элемента формы СлужебнаяИнформация.
5. Найдем поле «Формат обмена» (версия формата EnterpriseData). Если оно пустое, это и есть причина проблемы.
6. Установим версию формата вручную. Она должна в точности соответствовать версии формата, выбранной в настройках обмена на стороне УТ 11 (например, 1.3, 1.5 или более поздние актуальные версии).
7. Сохраним изменения и запустим повторную синхронизацию.

Решение 2. Обход ограничений при первоначальной выгрузке больших объемов данных

Когда вы запускаете обмен в первый раз, количество зарегистрированных объектов может превышать десятки и сотни тысяч записей (например, справочники номенклатуры, контрагентов, партнеров и накопленные за годы документы). Попытка передать все 120 000 объектов за один раз при прямом COM-соединении часто приводит к аварийному завершению процесса из-за нехватки памяти на сервере, превышения времени ожидания транзакции или блокировок таблиц СУБД.

Выясним, как правильно выполнить первый запуск синхронизации без зависания регистрации:

1. Запуск «пустой» синхронизации для согласования форматов:

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

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

2. Порционная выгрузка данных:

   Не пытайтесь отправить все справочники и документы в одной куче. Сначала зарегистрируйте только базовые классификаторы (валюты, единицы измерения, ставки НДС) и выполните обмен. Затем зарегистрируйте справочники контрагентов и партнеров. На третьем этапе — номенклатуру. И только после успешного переноса нормативно-справочной информации (НСИ) переходите к регистрации документов.

   Для порционной регистрации в обработке Регистрация изменений для обмена данными нажмите кнопку Зарегистрировать изменения, выберите конкретный тип объекта (например, справочник Номенклатура) и установите отбор (например, по группе или по ссылке), чтобы переносить данные небольшими частями по 5 000 – 10 000 элементов.

Решение 3. Сброс и выравнивание номеров сообщений

Если одна из баз восстанавливалась из архивной копии или правила обмена пересоздавались заново, счетчики номеров сообщений в УТ и БП неизбежно разойдутся. Например, УТ отправляет сообщение под номером 45, а БП считает, что последнее отправленное ею сообщение было под номером 12, и ожидает от УТ подтверждения более ранних транзакций. Произойдет рассинхронизация, и квитанции перестанут приниматься.

Рассмотрим по шагам, как выровнять номера сообщений вручную:

1. В обеих базах (УТ и БП) откройте обработку Регистрация изменений для обмена данными.
2. Нажмите кнопку Настройка (в некоторых интерфейсах она называется Изменить номера сообщений).
3. Перед вами откроется окно с двумя ключевыми полями: Номер отправленного сообщения и Номер принятого сообщения.
4. Чтобы полностью сбросить историю и начать нумерацию пакетов с чистого листа, установите в обеих базах для этого узла обмена оба значения в 0.

Пример структуры заголовка XML-файла обмена, который формируется платформой при выгрузке, выглядит следующим образом. Обратите внимание на параметры MessageNo (номер текущего сообщения) и ReceivedNo (номер принятого сообщения, то самое подтверждение):

<Header>
    <FormatVersion>1.5</FormatVersion>
    <CreationDate>2023-11-15T10:30:00</CreationDate>
    <Source>УТ</Source>
    <Destination>БП</Destination>
    <MessageNo>1</MessageNo>
    <ReceivedNo>1</ReceivedNo>
</Header>

После установки номеров в 0 выполните один цикл обмена. Базы автоматически присвоят первому пакету номер 1 и корректно зафиксируют квитирование.

Решение 4. Диагностика скрытых ошибок при прямом COM-соединении

Если обмен настроен через прямое подключение к базе-приемнику, весь процесс выполняется в рамках одной общей транзакции. Если при записи хотя бы одного документа на стороне БП происходит некритичная на первый взгляд ошибка (например, сработал некорректный код в подписке на событие ПриЗаписи, не заполнено обязательное субконто или заблокирована таблица базы данных), платформа выполняет полный откат транзакции.

В этом случае данные в интерфейсе БП могут не появиться, но счетчик отправки в УТ увеличится. При этом запись о получении квитанции в узел обмена БП не запишется. Для локализации этой проблемы выполните следующие действия:

• Временно перенастройте обмен с прямого подключения на «обмен через локальный или сетевой каталог». Это позволит вам физически контролировать файлы выгрузки.
• Выполните выгрузку из УТ в каталог. На диске появится XML-файл обмена.
• Запустите загрузку этого файла в БП вручную и сразу же откройте Журнал регистрации в БП. Отфильтруйте записи по событию Обмен данными. Здесь вы увидите подробное описание ошибок (например, ошибки XDTO-сериализации, несоответствие типов или незаполненные реквизиты), которые блокировали успешное завершение транзакции.
• Проверьте права пользователя, под которым осуществляется COM-подключение. Учетная запись должна обладать ролью Администратор или специализированной ролью Выполнение синхронизации данных. Без достаточных прав СУБД заблокирует запись квитанций в служебные регистры сведений (такие как СоответствиеОбъектовИнформационныхБаз).