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

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

Причина 1: Сбитые номера сообщений обмена

Когда одна из баз сообщает, что «номер сообщения не тот», это означает нарушение последовательности пакетов. Каждая база хранит два числа для каждого узла обмена: НомерОтправленного и НомерПринятого. Если база-приемник ожидает пакет №10, а вы присылаете ей пакет №5, синхронизация блокируется.

Рассмотрим, как исправить эту ситуацию по шагам:

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

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

Причина 2: Ошибки проверки данных XDTO

Одной из самых неприятных проблем является ошибка валидации по схеме EnterpriseData. Рассмотрим типичный пример из практики:

Ошибка проверки данных XDTO:
Структура объекта '/ДополнительныеРеквизиты/Строка[11]/ЗначениеСвойства/КонтрагентСсылка' не соответствует типу...
Проверка свойства 'ЮридическоеФизическоеЛицо': Не установлено значение одного из следующих свойств: Наименование

Выясним причину этой ошибки. Она означает, что в базе-источнике (например, УТ) есть объект (документ или справочник), в котором задействован контрагент с незаполненными обязательными полями. В формате EnterpriseData поля Наименование и ЮридическоеФизическоеЛицо являются обязательными. Если они пустые, XDTO-пакет просто не сформируется.

Проанализируем ситуацию по шагам:

1. Обратим внимание на индекс в ошибке: Строка[11]. Это указывает на то, что проблема кроется в 11-й строке табличной части или дополнительных реквизитов выгружаемого объекта.
2. Найдем «битого» контрагента. Скорее всего, у него не выбран тип (Юр. лицо или Физ. лицо) или не заполнено краткое наименование.
3. Важный нюанс: иногда визуально поле заполнено, но в базе значение «битое». Рекомендуется заново выбрать значение в поле «Юр./Физ. лицо» и перезаписать карточку контрагента.

Причина 3: Проблемы с выгрузкой «Ввода остатков»

Часто пользователи пытаются перенести документы ВводОстатков через типовую синхронизацию, видят сообщение «Объектов обработано: 8», но в базе-приемнике ничего не появляется. Рассмотрим, почему это происходит.

Во-первых, проанализируем Состав плана обмена. В типовых конфигурациях (УТ 11, БП 3.0) документ Ввод остатков часто исключен из автоматической синхронизации. Разработчики предполагают, что остатки вводятся в каждой базе независимо перед началом использования обмена. Если документа нет в составе плана обмена СинхронизацияДанныхЧерезУниверсальныйФормат, он не будет передан, даже если вы зарегистрируете его вручную.

Во-вторых, проверим фильтры синхронизации:

• Дата начала обмена: если документ Ввод остатков создан датой 31.12.2023, а в настройках обмена указана дата начала 01.01.2024, то документ будет проигнорирован при загрузке.
• Фильтры по организации: убедитесь, что организация в документе совпадает с той, что разрешена в настройках узла обмена.

Если вам критично перенести именно эти документы, рекомендуем использовать обработку «Универсальный обмен данными в формате XML» с правилами, созданными в «Конвертации данных 2.0», либо воспользоваться выгрузкой/загрузкой через формат XML (но только для идентичных конфигураций).

Рекомендации по обновлению правил обмена

Если вы столкнулись с тем, что базы имеют разные релизы, правила EnterpriseData могут конфликтовать. Рассмотрим, как это исправить:

Посмотрим на настройки синхронизации. В современных версиях 1С правила «зашиты» внутри конфигурации. Чтобы обновить правила, нужно обновить саму конфигурацию до актуального релиза. Если одна база обновлена, а вторая — нет, попробуйте в настройках синхронизации принудительно понизить версию формата (например, с 1.10 на 1.8), чтобы обе базы «понимали» друг друга.

Для продвинутой отладки используйте следующий подход:

1. Выгрузите данные в файл (если используется обмен через файл).
2. Откройте полученный XML-файл в текстовом редакторе (например, Notepad++).
3. Проанализируйте структуру узла, на котором происходит сбой. Это поможет точно определить, какого реквизита не хватает для успешной валидации.

Помните, что «тренироваться» лучше на простых справочниках (Номенклатура, Контрагенты), и только после успешного обмена ими переходить к документам движения и остатков. Это позволит локализовать проблему: в данных она или в самой настройке транспорта сообщений.