Как повторно отправить данные при ошибке синхронизации между УТ 11 и БП 3 и нужно ли регистрировать их заново?

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

Принцип работы механизма регистрации и квитирования сообщений

Рассмотрим, как платформа 1С управляет составом выгружаемых данных при обмене через планы обмена:

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

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

Поиск и локализация ошибки загрузки

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

1. Анализ журнала регистрации в базе-приемнике: откроем Журнал регистрации в информационной базе 1С:Бухгалтерия предприятия. Установим отбор по уровню важности «Ошибка» за дату и время выполнения синхронизации. В тексте события будет указан конкретный объект, реквизит или обработчик, на котором прервалось чтение пакета.
2. Проверка соответствия версий формата EnterpriseData: если одна из конфигураций была недавно обновлена, в настройках синхронизации обеих баз следует проверить используемую версию формата универсального обмена. Несоответствие схем XDTO может вызывать критические ошибки десериализации.
3. Проверка битых ссылок: наличие в пакете ссылок вида «Объект не найден» способно приводить к аварийной остановке обработки XML-сообщения.

Способы массового сброса статуса «Отправлено»

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

Способ 1. Использование типовой обработки «Регистрация изменений для обмена данными»

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

Способ 2. Программный сброс номеров сообщений

Для программного сброса номеров сообщений без потери зарегистрированных изменений используем встроенный метод менеджера планов обмена:

// Очищаем номера сообщений для указанного узла обмена
УзелОбмена = ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат.НайтиПоКоду("БП");

Если ЗначениеЗаполнено(УзелОбмена) Тогда
    // Если второй параметр не передан, очищаются номера для всех изменений данного узла
    ПланыОбмена.ОчиститьНомераСообщений(УзелОбмена);
КонецЕсли;

Рекомендации при передаче больших объемов данных

Если размер пакета превышает десятки тысяч объектов (например, более 25 000 элементов), процесс загрузки может прерываться из-за превышения таймаута транзакции или нехватки оперативной памяти на сервере 1С. В таких ситуациях применим следующий алгоритм:

1. Порционная выгрузка: через обработку регистрации изменений временно снимем регистрацию с тяжелых документов. Сначала выполним синхронизацию только нормативно-справочной информации (справочники Контрагенты, Номенклатура, ДоговорыКонтрагентов).
2. Поэтапная регистрация документов: после того как НСИ успешно загружена и квитанция зафиксирована, зарегистрируем документы небольшими порциями (по периодам или типам документов).
3. Выгрузка в файл: переключим транспорт обмена на локальный или сетевой каталог. Это позволит изолировать этап формирования XML-файла от этапа его загрузки и локализовать ошибку с помощью пошаговой отладки.