При настройке правил обмена в конфигурации 1С:Конвертация данных 2.1 (КД 2.1) разработчики часто сталкиваются со следующей задачей: в базе-источнике документ является «однострочным» (все ключевые реквизиты, такие как Сотрудник, Подразделение, Должность, находятся в шапке), а в базе-приемнике аналогичный документ спроектирован как «многострочный» (данные хранятся в табличной части, например, в ТЧ Работники).
Если попытаться сопоставить правила напрямую, система выдаст ошибку: «Поле объекта не обнаружено "Работники"». Это происходит потому, что правила конвертации группы свойств (ПКГС) по умолчанию пытаются прочитать одноименную коллекцию (табличную часть) из объекта-источника, которой там попросту нет. В этой статье мы подробно разберем, как решить эту задачу двумя надежными способами, проанализируем возможные ошибки и рассмотрим лучшие практики разработки правил обмена.
Выясним причину такого поведения конвертации. Когда мы создаем ПКГС для табличной части (например, Работники) и оставляем поле «Источник» незаполненным или сопоставляем его с несуществующим объектом, движок КД 2.1 пытается автоматически извлечь данные. Он обращается к свойству объекта-источника с именем этой табличной части. Поскольку в документе-источнике нет табличной части Работники, платформа генерирует исключение: Поле объекта не обнаружено.
Для решения этой проблемы нам необходимо принудительно сформировать коллекцию (Таблицу Значений) в коде обработчиков и передать ее правилам обмена для последующего разбора. Рассмотрим два детальных сценария реализации этой логики.
Этот способ основан на подготовке Таблицы Значений (ТЗ) на уровне Правила Конвертации Объектов (ПКО) в обработчике Перед выгрузкой и передаче её в качестве структуры параметров.
Рассмотрим по шагам, как настроить этот механизм:
ПриемНаРаботу).Ниже представлен пример кода, который необходимо написать в обработчике ПКО Перед выгрузкой:
ТЗ = Новый ТаблицаЗначений;
ТЗ.Колонки.Добавить("Сотрудник");
ТЗ.Колонки.Добавить("Подразделение");
ТЗ.Колонки.Добавить("Должность");
ТЗ.Колонки.Добавить("ДатаПриема");
НоваяСтрока = ТЗ.Добавить();
НоваяСтрока.Сотрудник = Источник.Сотрудник;
НоваяСтрока.Подразделение = Источник.Подразделение;
НоваяСтрока.Должность = Источник.ДолжностьПоШтатномуРасписанию;
НоваяСтрока.ДатаПриема = Источник.ДатаПриема;
ВходящиеДанные = Новый Структура;
ВходящиеДанные.Вставить("Работники", ТЗ);
После написания кода перейдем к настройке ПКГС (Правила конвертации группы свойств) для табличной части Работники:
Работники в дереве правил.ВходящиеДанные.Сотрудник, Подразделение, Должность, ДатаПриема.Важно: Обратите внимание, что писать в обработчиках ПКС код вида Значение = ОбъектКоллекции.ИмяКолонки; не требуется. Платформа делает это автоматически, сопоставляя свойства по наименованию колонок ТЗ.
Существует более элегантный и архитектурно правильный способ решения задачи. Вместо того чтобы перегружать обработчики ПКО общего документа, мы можем локализовать логику формирования таблицы непосредственно внутри правил самой табличной части. Для этого используется обработчик Перед обработкой правила группы свойств (ПКГС).
Проанализируем этот подход подробнее:
В справке КД 2.1 к событию Перед обработкой для ПКГС указано: если определить переменную КоллекцияОбъектов в теле обработчика (присвоить ей значение типа ТаблицаЗначений или СписокЗначений), стандартное автоматическое получение коллекции из источника выполняться не будет. Это именно то, что нам нужно!
Разберем реализацию этого способа по шагам:
Работники.
КоллекцияОбъектов = Новый ТаблицаЗначений;
КоллекцияОбъектов.Колонки.Добавить("Сотрудник");
КоллекцияОбъектов.Колонки.Добавить("Подразделение");
КоллекцияОбъектов.Колонки.Добавить("Должность");
КоллекцияОбъектов.Колонки.Добавить("ДатаПриема");
НоваяСтрока = КоллекцияОбъектов.Добавить();
НоваяСтрока.Сотрудник = Источник.Сотрудник;
НоваяСтрока.Подразделение = Источник.Подразделение;
НоваяСтрока.Должность = Источник.ДолжностьПоШтатномуРасписанию;
НоваяСтрока.ДатаПриема = Источник.ДатаПриема;
При использовании этого метода флаг «Получать из входящих данных» ставить не нужно, так как мы определяем коллекцию напрямую в контексте обработки свойств. Это существенно упрощает структуру правил и делает их более читаемыми для других разработчиков, сопровождающих интеграцию.
Рассмотрим ситуации, когда имена колонок созданной нами программной таблицы значений отличаются от реквизитов табличной части базы-приемника.
Если в ТЗ колонка называется, например, ФизЛицо, а в базе-приемнике реквизит табличной части называется Сотрудник, автоматического сопоставления по имени не произойдет. Чтобы решить эту проблему:
Сотрудник в поле «Источник» вручную впишите имя колонки из вашей программной таблицы (в данном случае — ФизЛицо).Когда мы передаем в колонках ТЗ ссылки на объекты (например, элементы справочников Сотрудники, Подразделения), КД пытается автоматически подобрать для них ПКО на основании типов данных. Однако если для одного и того же типа данных в правилах определено несколько разных ПКО (например, для типа СправочникСсылка.Сотрудники есть ПКО СотрудникиФизическиеЛица и ПКО СотрудникиОрганизаций), автоматика может выбрать не то правило.
Чтобы избежать ошибок неверного сопоставления ссылок, для конкретного ПКС реквизита ТЧ выполните одно из следующих действий:
Перед выгрузкой: ИмяПКО = "СотрудникиОрганизаций";.Использование программного формирования коллекций открывает огромные возможности для трансформации данных. Допустим, в документе-источнике в шапке находятся несколько однотипных реквизитов (например, Сотрудник1, Сотрудник2, Сотрудник3). Нам необходимо развернуть эти плоские данные в многострочную табличную часть приемника.
Посмотрим на пример реализации такого развертывания в обработчике ПКГС Перед обработкой:
КоллекцияОбъектов = Новый ТаблицаЗначений;
КоллекцияОбъектов.Колонки.Добавить("Сотрудник");
КоллекцияОбъектов.Колонки.Добавить("Подразделение");
Для Номер = 1 По 3 Цикл
ИмяРеквизита = "Сотрудник" + Номер;
Если ЗначениеЗаполнено(Источник[ИмяРеквизита]) Тогда
НоваяСтрока = КоллекцияОбъектов.Добавить();
НоваяСтрока.Сотрудник = Источник[ИмяРеквизита];
НоваяСтрока.Подразделение = Источник.Подразделение;
КонецЕсли;
КонецЦикла;
Таким образом, мы легко превратили несколько разрозненных реквизитов шапки источника в полноценные строки табличной части документа-приемника всего в несколько строк кода.
При программном формировании коллекции вы получаете абсолютный контроль над выгрузкой данных. К примеру, если в процессе проверки выяснилось, что таблица значений не прошла валидацию или оказалась пустой, и выгружать документ с пустой табличной частью не имеет смысла, вы можете использовать встроенный флаг отмены.
Для этого в обработчике ПКГС Перед обработкой достаточно написать простой код:
Если КоллекцияОбъектов.Количество() = 0 Тогда
Отказ = Истина;
КонецЕсли;
Установка параметра Отказ = Истина в данном контексте отменит выгрузку исключительно этой конкретной табличной части, не нарушая работу выгрузки всего остального документа-приемника.
Мы проанализировали два основных подхода к переносу одиночных реквизитов шапки в табличные части приемника:
Применяя эти методы на практике, вы избавитесь от ошибок обращения к отсутствующим свойствам объектов и сможете гибко управлять структурой переносимых данных при любых обменах в экосистеме 1С.