Как перенести записи регистра накопления в Конвертации данных 2.1 без регистратора и сохранить вид движения?

При настройке обмена данными между конфигурациями 1С часто возникает специфическая задача: необходимо перенести только движения по регистру накопления, не создавая при этом сами документы-регистраторы в базе-приемнике. Типичный пример — синхронизация остатков между идентичными базами «Управление торговлей 10.3», где первичные документы (например, Чеки ККМ или Реализации) не должны дублироваться, а записи в регистре Товары в рознице должны появиться для корректного отображения остатков.

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

Анализ проблемы «битых ссылок» и целостности данных

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

Важно понимать последствия такого подхода:

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

Разберем способы решения технических сложностей при таком переносе.

Решение 1: Использование документа-контейнера (Корректировка записей регистров)

Профессиональный подход к данной задаче заключается в том, чтобы «подсунуть» записям регистра реальный регистратор, существующий в базе-приемнике. В конфигурации «Управление торговлей 10.3» для этих целей идеально подходит документ Корректировка записей регистров. Рассмотрим алгоритм настройки:

1. В правилах конвертации объектов (ПКО) для исходного документа (например, РеализацияТоваровУслуг) в качестве объекта-приемника выберем КорректировкаЗаписейРегистров.
2. Настроим сопоставление по GUID, чтобы один документ-источник всегда соответствовал одному документу-корректировке в приемнике.
3. В ПКС (Правила конвертации свойств) настроим перенос движений регистра ТоварыВРознице в соответствующую таблицу движений корректировки.

Этот метод гарантирует, что в базе-приемнике всегда будет физический документ, на который ссылаются записи регистра, что исключает проблемы при ТиИ и пересчете итогов.

Решение 2: Исправление типа «Вид движения» через ПКС

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

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

// В обработчике ПКС для свойства ВидДвижения
// Используем ОбъектКоллекции для обращения к текущей записи набора движений
Если ОбъектКоллекции.ВидДвижения = ВидДвиженияНакопления.Приход Тогда
    Значение = "Приход";
Иначе
    Значение = "Расход";
КонецЕсли;

Однако, как показывает практика, более надежным способом является программная установка типа в обработчике «При загрузке» в ПКО регистра в базе-приемнике, чтобы гарантировать приведение строки к системному типу ВидДвиженияНакопления.

Решение 3: Модификация кода обработки загрузки (для опытных разработчиков)

Если вы столкнулись с тем, что штатная обработка ОбменДаннымиXML в вашей старой версии конфигурации (например, УТ 10.3.8) некорректно интерпретирует типы данных при чтении набора записей, можно внести изменения в саму обработку. Рассмотрим пример кода, который необходимо добавить в функцию ПрочитатьНаборЗаписейРегистра:

// Внутри цикла чтения свойств записи регистра в обработке ОбменДаннымиXML
Если Имя = "ВидДвижения" Тогда
    Если Значение = "Расход" Тогда
        ТекущаяСтрокаНабораЗаписей[Имя] = ВидДвиженияНакопления.Расход;
    Иначе
        ТекущаяСтрокаНабораЗаписей[Имя] = ВидДвиженияНакопления.Приход;
    КонецЕсли;
Иначе
    ТекущаяСтрокаНабораЗаписей[Имя] = Значение;
КонецЕсли;

Данная правка принудительно проверяет имя считываемого свойства. Если это ВидДвижения, программа не просто подставляет строковое значение из XML-файла, а выполняет поиск соответствующего элемента системного перечисления ВидДвиженияНакопления. Это решает проблему, когда в базу записывается «битый» тип, который интерфейс 1С по умолчанию отображает как «Приход».

Решение 4: Использование ПКО для системного перечисления

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

1. Создаем новое ПКО: Источник — ВидДвиженияНакопления, Приемник — ВидДвиженияНакопления.
2. В таблице «Конвертация значений» вручную добавляем две строки:
   • Приход ---> Приход
   • Расход ---> Расход
3. В правилах конвертации регистра, в строке ПКС ВидДвижения, в колонке «Правило конвертации», выбираем созданное нами ПКО для перечисления.

В этом случае КД 2.1 сформирует в XML правильный идентификатор значения, который будет корректно распознан обработкой загрузки как объект нужного типа.

Подведение итогов

Мы рассмотрели несколько вариантов решения проблемы переноса движений регистров без документов-регистраторов. Резюмируем наши выводы:

• Самый быстрый путь: Программная подстановка вида движения в ПКС или правка кода обработки загрузки.
• Самый правильный путь: Использование документа Корректировка записей регистров в качестве приемника. Это сохраняет целостность базы и позволяет стандартным механизмам платформы корректно обрабатывать записи.
• Важный нюанс: Всегда проверяйте, как записи отражаются в виртуальных таблицах остатков после загрузки. В некоторых случаях может потребоваться принудительный пересчет итогов или установка флага ОбменДанными.Загрузка = Истина для обхода лишних проверок при записи набора.

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