Почему не переносится банковский счет контрагента в Конвертации данных 2.0: причины и решение

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

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

Разберем причину проблемы: полиморфизм владельца

Справочник БанковскиеСчета является подчиненным. Это означает, что каждый элемент этого справочника жестко связан с объектом-владельцем. Главная техническая сложность заключается в том, что владельцем банковского счета может быть как объект типа СправочникСсылка.Организации, так и СправочникСсылка.Контрагенты (а иногда и ФизическиеЛица).

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

Проанализируем ПКО «БанковскиеСчета»

Первым делом нам необходимо проверить само правило конвертации объекта БанковскиеСчета. Рассмотрим основные моменты:

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

Шаг 1. Проверка ПКС в документе-источнике

Рассмотрим ПКС в правиле конвертации документа (например, ПлатежноеПоручение). У нас есть два реквизита:

• СчетОрганизации
• СчетКонтрагента

Выясним, указаны ли для них правила конвертации. Часто разработчики забывают, что если имена реквизитов в источнике и приемнике различаются (например, в источнике БанковскийСчетОрганизации, а в приемнике СчетОрганизации), необходимо явно указывать соответствие. Если поле «Источник» пустое, а автоматическое сопоставление по имени не сработало, реквизит просто проигнорируется.

Шаг 2. Использование обработчика «Перед выгрузкой»

Если автоматика КД 2.0 не справляется из-за сложной логики владельцев, мы можем вмешаться программно. Проанализируем ситуацию в обработчике «Перед выгрузкой» для ПКС СчетКонтрагента. Иногда там стоит условие, которое блокирует выгрузку, если тип владельца не является организацией. Проверьте код на наличие конструкций типа Отказ = Истина.

Если нам нужно гарантированно выгрузить счет, мы можем использовать метод ВыгрузитьПоПравилу(). Посмотрим на пример кода, который можно разместить в обработчике ПередВыгрузкой свойства документа:

Если ЗначениеЗаполнено(Источник.СчетКонтрагента) Тогда
    УзелСвойства = СоздатьУзел("СчетКонтрагента");
    ВыгрузитьПоПравилу(Источник.СчетКонтрагента, , , , "БанковскиеСчета");
КонецЕсли;

Этот подход позволяет принудительно инициировать выгрузку объекта по конкретному правилу, минуя стандартные ограничения сопоставления типов.

Шаг 3. Синхронизация по полям поиска

Часто проблема кроется в том, что в ПКО БанковскиеСчета поля поиска настроены некорректно для разных типов владельцев. Проверьте вкладку «Поля поиска». Для корректной работы рекомендуется следующий порядок:

1. Владелец (обязательно участвует в поиске);
2. НомерСчета (или Код / Наименование);
3. ВалютаДенежныхСредств (если актуально).

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

Шаг 4. Включение в состав Плана обмена

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

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

Подведем итоги и сформируем решение

Чтобы исправить отсутствие счета контрагента в выгрузке, выполните следующие действия:

1. Проверьте ПКО подчиненного справочника: убедитесь, что в ПКО БанковскиеСчета не стоит жесткого фильтра по типу владельца в обработчике Перед выгрузкой.
2. Унифицируйте ПКС: в правиле конвертации документа для обоих свойств (счет организации и счет контрагента) должно быть указано одно и то же ПКО БанковскиеСчета.
3. Проверьте уникальность: убедитесь, что поиск настроен «По владельцу». Это исключит ситуацию, когда система находит похожий счет у другого контрагента и считает, что выгружать ничего не нужно.
4. Проанализируйте XML: если в файле выгрузки узел счета отсутствует полностью, значит, отказ происходит на уровне ПКС документа. Если узел есть, но он пустой — проблема в ПКО самого счета.

Использование этих рекомендаций позволит вам настроить стабильный перенос данных и избежать типичных ошибок при работе с полиморфными связями в «Конвертации данных 2.0».