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

← На главную

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

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

Шаг 1: Создание правил конвертации объектов (ПКО)

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

Создадим ПКО №1: Заявка (Источник) —> ЗаказПокупателя (Приемник).
Создадим ПКО №2: Заказ (Источник) —> ЗаказПокупателя (Приемник).

В каждом из этих правил мы настраиваем соответствие реквизитов (ПКС). Обратите внимание, что если в Заявке табличная часть называется Товары, а в Заказе — Состав, то в соответствующих ПКО мы должны сопоставить их с табличной частью Товары документа Заказ покупателя.

Шаг 2: Проблема уникальности и поиск объектов

Разберем ситуацию, которая часто становится «подводным камнем». Если в источнике есть Заявка №001 и Заказ №001, то при загрузке в приемник без дополнительных настроек один документ может затереть другой, так как у них совпадут номера. Чтобы этого избежать, проанализируем настройки поиска.

Вариант А: Использование ГУИД (GUID). Если в ПКО включен поиск по уникальному идентификатору, система создаст два разных документа в приемнике, так как у Заявки и Заказа в источнике разные ГУИДы. Это самый надежный способ.

Вариант Б: Использование префиксов. Если поиск должен идти по номеру и дате, нам необходимо в событии Перед выгрузкой каждого ПКО программно изменить номер, добавив к нему префикс.


// В ПКО Заявка -> ЗаказПокупателя (событие Перед выгрузкой)
Номер = "ЗВ-" + Источник.Номер;

// В ПКО Заказ -> ЗаказПокупателя (событие Перед выгрузкой)
Номер = "ЗК-" + Источник.Номер;

Это гарантирует, что объекты не «схлопнутся» по ошибке при поиске по полям Номер и Дата.

Шаг 3: Настройка ссылки в документе «Реализация товаров и услуг»

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

По умолчанию КД 2.1 позволяет выбрать только одно ПКО для одного реквизита. Если мы выберем ПКО Заявка -> ЗаказПокупателя, то ссылки на Заказы не перенесутся. Чтобы решить эту задачу, воспользуемся параметром ИмяПКО в обработчике Перед выгрузкой данного ПКС.

Проанализируем алгоритм выбора правила:


// Обработчик ПКС "Заказ" в документе РеализацияТоваровУслуг
// Событие: Перед выгрузкой

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

ТипЗаказа = ТипЗнч(Источник.Заказ);

Если ТипЗаказа = Тип("ДокументСсылка.Заявка") Тогда
    ИмяПКО = "Заявка"; // Укажите точное имя ПКО из вашего проекта
ИначеЕсли ТипЗаказа = Тип("ДокументСсылка.Заказ") Тогда
    ИмяПКО = "Заказ";  // Укажите точное имя ПКО из вашего проекта
КонецЕсли;

Важный момент: Переменная ИмяПКО — это предопределенный параметр КД, который сообщает движку выгрузки, по какому именно правилу нужно превратить текущий объект-ссылку в XML-структуру. Таким образом, мы динамически подменяем логику в зависимости от того, какой документ является основанием в базе-источнике.

Шаг 4: Настройка поиска для связанных объектов

Выясним причину, по которой ссылка может не заполниться в приемнике, даже если код написан верно. Это происходит из-за рассинхронизации полей поиска. Чтобы документ РТиУ «увидел» свой Заказ покупателя, поля поиска в обоих ПКО (и для заявки, и для заказа) должны работать одинаково.

Рассмотрим рекомендации:

Если в ПКО Заявка -> ЗаказПокупателя вы ищете по Номеру и Дате, то и в ПКО Заказ -> ЗаказПокупателя должны быть установлены те же флаги поиска.
Если вы используете префиксы (как в Шаге 2), убедитесь, что логика формирования префикса в обработчиках ПКО совпадает с логикой поиска.
Лучшая практика — синхронизация по Уникальному идентификатору. В этом случае КД сама найдет нужный объект, независимо от его номера в базе-приемнике.

Шаг 5: Оптимизация процесса и работа с составными типами

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

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


// Пример более надежной проверки типа
Если Источник.Заказ.Метаданные().Имя = "Заявка" Тогда
    ИмяПКО = "Заявка_ЗаказПокупателя";
КонецЕсли;

Также не забывайте про обработку проведения. Часто Заявки могут быть не проведены, а Заказы — проведены. В ПКО в обработчике После загрузки вы можете установить статус документа-приемника в зависимости от состояния источника, используя свойство Источник.Проведен.

Резюме

Мы проанализировали процесс переноса нескольких типов документов в один. Основные этапы включают в себя создание отдельных ПКО для каждого источника и использование программного переопределения ИмяПКО в правилах конвертации свойств. Такой подход позволяет гибко управлять ссылочной целостностью базы данных без использования сложных произвольных алгоритмов выгрузки всей коллекции данных.