Как настроить выгрузку связанных данных и очистку регистрации изменений при нетиповом обмене через план обмена в 1С

← На главную

При организации одностороннего или нетипового обмена между различными конфигурациями 1С (например, между базой на платформе 8.3 с управляемыми формами и базой 8.2 с обычными формами) разработчики часто сталкиваются с двумя характерными проблемами: некорректной выгрузкой подчиненных данных (контактной информации, связанных справочников, регистров сведений) и зависанием зарегистрированных изменений в узле плана обмена источника. Разберем подробно причины возникновения этих ошибок и эффективные способы их решения с помощью правил конвертации («1С:Конвертация данных 2.1») и встроенного языка платформы.

Проблема 1. Перенос зависимых данных и регистров сведений без лишних ПВД

Проанализируем типовую ошибку при настройке правил выгрузки данных (ПВД). Часто для переноса одного объекта-источника (например, договора или контрагента) и связанных с ним контактных лиц, категорий и контактной информации создают несколько независимых ПВД. В таком сценарии при выгрузке по плану обмена, где регистрируется только основной объект, связанные данные либо не попадают в выгрузку вовсе, либо возникают ошибки чтения входящих данных вида Получение элемента по индексу для значения не определено.

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

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

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


Источник = Объект.Ссылка;

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

// Выгрузка контактной информации по условию заполненности
Если ЗначениеЗаполнено(Источник.ЮЛ_Телефон) Тогда
    ВыгрузитьПоПравилу(Источник, , , , "КонтактнаяИнформацияКонтрагента");
КонецЕсли;

Если ЗначениеЗаполнено(Источник.ТелефонПредставителя) Тогда
    ВыгрузитьПоПравилу(Источник, , , , "КонтактнаяИнформацияКЛКТелефон");
КонецЕсли;

Если ЗначениеЗаполнено(Источник.emailПредставителя) Тогда
    ВыгрузитьПоПравилу(Источник, , , , "КонтактнаяИнформацияКЛКАдресЭлектроннойПочты");
КонецЕсли;

Обратим внимание на сигнатуру метода ВыгрузитьПоПравилу:

ВыгрузитьПоПравилу(Источник, Приемник, ВходящиеДанные, ИсходящиеДанные, ИмяПКО, ...)

Важно: Третий параметр отвечает за ВходящиеДанные, а четвертый — за ИсходящиеДанные. Если вы формируете структуру параметров вручную для передачи в ПКО, передавайте её строго в четвертый параметр (ИсходящиеДанные), иначе внутри ПКО возникнет исключение при попытке распаковать пустую коллекцию входящих данных.

Проблема 2. Борьба с дублированием объектов при сложной конвертации

Выясним причину, почему при конвертации одного справочника в другой (например, Договоры в Контрагенты) в базе-приемнике могут появляться дубли. По умолчанию в правилах конвертации объектов (ПКО) активен поиск по внутреннему идентификатору (UUID). Если у одного контрагента в базе 8.3 оформлено несколько договоров, то при сопоставлении по UUID договора в базе 8.2 будет создан отдельный контрагент на каждый договор.

Чтобы избежать появления дублей, применим следующие настройки в ПКО:

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

Проблема 3. Очистка регистрации изменений узла плана обмена

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

Если обмен настроен строго в одну сторону и ответные файлы в базу 8.3 не загружаются, автоматическая очистка не сработает. Рассмотрим два корректных варианта реализации.

Вариант 1. Использование двустороннего квитирования без бизнес-данных

Это наиболее надежный платформенный путь. Даже при односторонней передаче данных настроим ответную отправку минимального XML-сообщения от базы 8.2 к базе 8.3. Этот файл содержит исключительно служебный заголовок с номерами сообщений без самих объектов. При чтении такого заголовка в базе-источнике платформа 1С автоматически и безопасно удалит всю подтвержденную регистрацию изменений.

Вариант 2. Программное удаление регистрации с фиксацией номера сообщения

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

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


// 1. Формируем номер сообщения и выбираем изменения строго для этого номера
НомерСообщения = УзелОбмена.НомерОтправленного + 1;
ВыборкаИзменений = ПланыОбмена.ВыбратьИзменения(УзелОбмена, НомерСообщения);

// 2. Выполняем запись данных в файл обмена...
// [Код выгрузки данных через КД или XML]

// 3. После успешного сохранения и отправки файла очищаем регистрацию только для этого пакета:
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена, НомерСообщения);

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