Как перенести контактную информацию из УПП 1.3 в табличную часть БП 3.0?

При переносе данных между устаревшими конфигурациями на обычных формах (например, Управление производственным предприятием 1.3) и современными конфигурациями на базе Библиотеки стандартных подсистем (например, Бухгалтерия предприятия 3.0) часто возникает проблема несовпадения структур данных. В УПП 1.3 контактная информация контрагентов хранится в независимом регистре сведений КонтактнаяИнформация, тогда как в БП 3.0 она размещена непосредственно в табличной части КонтактнаяИнформация справочников (Контрагенты, Организации, ФизическиеЛица).

Разберем основные причины сложностей, с которыми сталкиваются разработчики, и подробно рассмотрим правильные способы переноса данных.

Почему не работают стандартные процедуры обновления?

Проанализируем ситуацию: попытки перенести данные во временный регистр приемника (например, УдалитьКонтактнаяИнформация) и запустить стандартные процедуры обновления вроде ПереносКИПриОбновленииС20() часто терпят неудачу по следующим причинам:

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

Для корректного решения задачи рассмотрим два надежных подхода: перенос напрямую через правила «Конвертации данных 2.0» и программную обработку с использованием штатных методов БСП.

Способ 1. Настройка правил конвертации в «1С:Конвертация данных 2.0»

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

Разберем по шагам настройку правила конвертации объектов (ПКО):

1. В ПКО для справочника Контрагенты создадим правило конвертации группы свойств (ПКГС) для табличной части КонтактнаяИнформация.
2. Поскольку источником выступает не табличная часть контрагента, а регистр сведений, снимем признак автоматического получения данных из источника.
3. В обработчике события ПередВыгрузкой для ПКГС табличной части сформируем таблицу значений запросом к регистру сведений источника. Посмотрим на пример кода:

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	КИ.Тип КАК Тип,
    |	КИ.Вид КАК Вид,
    |	КИ.Представление КАК Представление,
    |	КИ.Поле1,
    |	КИ.Поле2,
    |	КИ.Поле3
    |ИЗ
    |	РегистрСведений.КонтактнаяИнформация КАК КИ
    |ГДЕ
    |	КИ.Объект = &Объект";

Запрос.УстановитьПараметр("Объект", Источник);
КоллекцияОбъектов = Запрос.Выполнить().Выгрузить();

Рассмотрим подробнее важный нюанс сопоставления видов контактной информации. В БП 3.0 справочник ВидыКонтактнойИнформации имеет строгую иерархию по типам владельцев (предопределенная группа «Для контрагентов»). Если синхронизировать виды контактной информации исключительно по наименованию, они могут создаться в корне справочника вне нужной группы, из-за чего форма контрагента в приемнике их просто не отобразит. Настраивайте синхронизацию по полям ИмяПредопределенныхДанных либо по связке Наименование и Родитель.

Способ 2. Программное заполнение через вызовы подсистемы БСП

Если контактная информация уже была перенесена во внешнюю таблицу или читается напрямую из базы-источника (например, через COM-соединение), не следует записывать строки в табличную часть объекта напрямую через метод Добавить(). В БП 3.0 реквизит ЗначенияПолей хранит сложную структуру (в формате JSON или XML), содержащую коды ФИАС/ГАР. При обычной текстовой вставке форма редактирования адреса не сможет разложить контакт по отдельным полям (город, улица, дом).

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

Разберем по шагам заполнение табличной части через экспортный метод общего модуля:

1. Получаем объект контрагента для редактирования методом ПолучитьОбъект().
2. Определяем требуемый вид контактной информации (ссылку на элемент справочника ВидыКонтактнойИнформации).
3. Вызываем метод УправлениеКонтактнойИнформацией.ЗаписатьКонтактнуюИнформацию().
4. Записываем объект.

Посмотрим на пример обработки:

ОбъектКонтрагент = ВыбраннаяСсылка.ПолучитьОбъект();

ВидКИ = Справочники.ВидыКонтактнойИнформации.ЮрАдресКонтрагента;
ТипКИ = Перечисления.ТипыКонтактнойИнформации.Адрес;
СтрокаАдреса = "г. Москва, ул. Ленина, д. 10";

// Запись контактной информации средствами БСП
УправлениеКонтактнойИнформацией.ЗаписатьКонтактнуюИнформацию(
    ОбъектКонтрагент, 
    СтрокаАдреса, 
    ВидКИ, 
    ТипКИ
);

ОбъектКонтрагент.Записать();

Данный подход избавляет от необходимости вручную формировать структурированные строки формата XML или JSON в поле ЗначенияПолей. Текстовое представление сразу запишется в карточку объекта, а дальнейшую привязку к актуальному классификатору адресов можно выполнить штатной регламентной обработкой БСП по проверке адресов уже в рабочей базе.