Как исправить ошибку «Неверный тип второго параметра Реквизиты: Не определено» при синхронизации УТ 11 и БП 3.0?

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

Событие: Получение. Обработчик: ПередЗаписьюПолученныхДанных. Объект: Справочник объект: Контрагенты... Ошибка выполнения обработчика. Неверный тип второго параметра Реквизиты: Не определено.

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

Выясняем причину: что происходит на уровне программного кода?

Для того чтобы понять природу сбоя, обратимся к общему модулю ОбщегоНазначения. Ошибка возникает внутри служебной функции, которая предназначена для быстрого чтения значений реквизитов объектов непосредственно из базы данных (без полной загрузки тяжелого объекта в оперативную память). Обычно это функция ЗначенияРеквизитовОбъекта() или её аналоги.

Эта функция принимает два обязательных параметра:

1. Ссылка — ссылка на объект базы данных (например, на конкретного контрагента).
2. Реквизиты — список полей, значения которых необходимо получить. Этот параметр должен иметь строго определенный тип: Строка (с именами полей через запятую), Массив или Структура.

Проанализируем фрагмент кода, на котором происходит аварийное завершение работы системы:

Если ТипЗнч(Реквизиты) <> Тип("Строка") 
   И ТипЗнч(Реквизиты) <> Тип("Массив") 
   И ТипЗнч(Реквизиты) <> Тип("Структура") Тогда
    
    ВызватьИсключение СтроковыеФункцииКлиентСервер.ПодставитьПараметрыВСтроку(
        НСтр("ru = 'Неверный тип второго параметра Реквизиты: %1'"), 
        Строка(ТипЗнч(Реквизиты))
    );
КонецЕсли;

Когда при импорте контрагента через универсальный формат обмена (XDTO / EnterpriseData) система доходит до обработчика ПередЗаписьюПолученныхДанных, запускаются алгоритмы сопоставления контрагентов, проверки дублей по ИНН/КПП, а также анализа контактной информации. Для этого принимающая конфигурация (БП 3.0) пытается динамически сформировать список реквизитов для анализа.

Если данные передаваемого контрагента в базе-источнике (УТ 11) заполнены некорректно, содержат логические противоречия или пустые значения в ключевых свойствах, алгоритм формирования списка реквизитов возвращает пустое значение — Неопределено. Передача этого значения во второй параметр функции модуля ОбщегоНазначения и вызывает фатальное исключение, полностью блокируя сеанс синхронизации.

Шаг 1. Быстрое решение проблемы через исправление данных контрагента

Рассмотрим самый простой и действенный практический способ решения проблемы, который помогает в большинстве случаев без привлечения программистов и изменения кода конфигурации.

Выполним следующие действия по шагам:

1. Идентификация проблемного объекта. Откроем журнал регистрации в базе-приемнике (БП) или изучите подробный лог ошибки синхронизации. В тексте ошибки всегда указывается ссылка на конкретного контрагента. Например: Справочник объект: Контрагенты, СОЮЗ ООО (e1cib/data/Справочник.Контрагенты?ref=...). Нам нужно запомнить наименование или ИНН этого контрагента.
2. Поиск контрагента в источнике. Перейдем в базу «Управление торговлей» (УТ 11) и найдем карточку этого контрагента.
3. Автоматическое заполнение реквизитов. Воспользуемся стандартным сервисом 1С для автоматического заполнения реквизитов по ИНН. Введем ИНН контрагента и нажмем кнопку заполнения. Сервис автоматически обновит юридический адрес, КПП, полное наименование и форму собственности в соответствии с данными ЕГРЮЛ.
4. Интерактивное сохранение. Нажмем кнопку «Записать и закрыть». Интерактивная запись крайне важна: в этот момент отрабатывают все встроенные платформенные проверки и заполняются скрытые системные параметры карточки контрагента (например, тип контрагента — Юр. лицо или Физ. лицо, страна регистрации и т.д.).
5. Перепроведение документов. Перепроведем все документы, оформленные по данному контрагенту за период текущей синхронизации. Это обновит связанные регистры сведений.
6. Запуск синхронизации. Повторно запустим процесс синхронизации данных. Корректно записанный контрагент без проблем пройдет валидацию XDTO и успешно загрузится в бухгалтерию.

Шаг 2. Анализ и устранение глубоких причин возникновения ошибки

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

1. Программное создание контрагентов внешними обработками

Очень часто контрагенты создаются в УТ 11 не вручную, а автоматически — через API, интеграцию с сайтами (интернет-магазинами), CRM-системами (например, Битрикс24) или при импорте из файлов Excel. Если разработчик внешней интеграции написал код создания карточки контрагента «напрямую», минуя стандартные процедуры проверки, объект записывается в базу «битым» (без заполнения обязательных реквизитов).

Чтобы избежать этого, в коде загрузки обязательно нужно использовать методы объектной модели 1С с вызовом обработчиков валидации:

НовыйКонтрагент = Справочники.Контрагенты.СоздатьЭлемент();
// Заполнение реквизитов...
НовыйКонтрагент.Наименование = "ООО СОЮЗ";
НовыйКонтрагент.ЮридическоеФизическоеЛицо = Перечисления.ЮридическоеФизическоеЛицо.ЮрЛицо;

// Обязательно используйте дополнительные параметры для проверки заполнения
НовыйКонтрагент.ОбменДанными.Загрузка = Ложь; 
НовыйКонтрагент.Записать();

2. Проблемы иерархии (Группы и Элементы)

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

3. «Битые» ссылки в связанных реквизитах

Если у контрагента в поле «Партнер», «Головной контрагент» или «Страна регистрации» выбрано значение, которое было удалено или помечено на удаление (отображается как <Объект не найден...>), это гарантированно приведет к сбою при формировании пакета обмена EnterpriseData. Используйте стандартную обработку «Поиск и замена дублей» или «Поиск битых ссылок» для очистки таких связей.

4. Рассинхронизация версий конфигураций

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

Применяя эти методы на практике, мы сможем оперативно диагностировать сбои при обмене данными и предотвратить повторное возникновение ошибок синхронизации между конфигурациями 1С.