Как перенести остатки из одного регистра накопления в другой с помощью Конвертации данных 2.1

← На главную

При переходе с одной конфигурации на другую (например, с УТ 10.3 на ERP или КА 2) часто возникает задача переноса остатков по регистрам накопления. Типичный вопрос разработчика: можно ли конвертировать данные напрямую из регистра-источника в регистр-приемник или обязательно использовать документ? Разберем эту ситуацию подробно, опираясь на внутренние механизмы платформы 1С и возможности конфигурации Конвертация данных 2.1 (КД 2.1).

Почему нельзя конвертировать регистр в регистр напрямую?

В платформе 1С:Предприятие 8 существует фундаментальное различие между регистрами сведений и регистрами накопления. Если независимый РегистрСведений может существовать сам по себе, то РегистрНакопления всегда жестко связан с документом-регистратором. В структуре базы данных каждая запись регистра накопления содержит поле Recorder, которое является ссылкой на уникальный идентификатор (GUID) документа.

Рассмотрим технический нюанс: в отличие от версии 7.7, где движения были результатом проведения документа, в версии 8 регистратор и его движения — это разные сущности. Движения могут существовать в базе даже без проведения самого документа (например, при программной записи набора записей), но ссылка на объект-регистратор обязана присутствовать в каждой строке. Поэтому при конвертации данных приемником всегда должен выступать документ, который станет владельцем этих записей.

Решение 1: Перенос регистратора вместе с его движениями

Если ваша задача состоит в том, чтобы просто перенести документы со всеми их движениями «как есть», разберем этот алгоритм:

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

Этот способ подходит, если структура регистров в обеих базах идентична и вы переносите первичные документы. Однако при переносе остатков (например, из ТоварыНаСкладах в СвободныеОстатки) такой метод не сработает, так как регистры разные.

Решение 2: Использование универсального документа-регистратора

Для переноса накопленных остатков проанализируем наиболее гибкий вариант — использование документа Корректировка записей регистров (или специализированного документа ввода остатков в ERP). Выясним, как настроить правила в этом случае.

Основная идея заключается в том, что мы не выгружаем объекты регистра накопления сами по себе. Вместо этого мы формируем данные для документа-приемника на лету. Разберем по шагам создание такого правила.

Шаг 1. Настройка ПВД (Правила выгрузки данных)

Вместо стандартного ПВД выберем тип «Произвольный алгоритм». Это позволит нам собрать остатки с помощью запроса непосредственно перед выгрузкой. Посмотрим на пример кода в обработчике Перед выгрузкой данных:


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |   ТоварыНаСкладахОстатки.Номенклатура КАК Номенклатура,
    |   ТоварыНаСкладахОстатки.Склад КАК Склад,
    |   ТоварыНаСкладахОстатки.КоличествоОстаток КАК Количество
    |ИЗ
    |   РегистрНакопления.ТоварыНаСкладах.Остатки(&ДатаОстатков, ) КАК ТоварыНаСкладахОстатки";

Запрос.УстановитьПараметр("ДатаОстатков", ДатаОкончания);
Выборка = Запрос.Выполнить().Выбрать();

Пока Выборка.Следующий() Цикл
    // Создаем структуру для передачи в ПКО документа
    ДанныеДляПКО = Новый Структура("Номенклатура, Склад, Количество");
    ЗаполнитьЗначенияСвойств(ДанныеДляПКО, Выборка);
    
    // Выгружаем данные по ПКО документа "КорректировкаЗаписейРегистров"
    ВыгрузитьПоПравилу(ДанныеДляПКО, , , , "КорректировкаЗаписейРегистров");
КонецЦикла;

Шаг 2. Настройка ПКО для документа-приемника

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

Рассмотрим, как передать данные из структуры ДанныеДляПКО в движения документа:

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

Важный нюанс: Проблема «Объект не найден»

В обсуждениях часто высказывается идея передать в поле Регистратор просто сгенерированный GUID, чтобы получить движения с битой ссылкой «Объект не найден». Настоятельно не рекомендуем этого делать по следующим причинам:

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

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

Оптимизация: Пересчет итогов

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

Зайти в базу-приемник в режиме «Конфигуратор».
Выбрать пункт меню «Администрирование» — «Тестирование и исправление».
Выбрать только пункт «Пересчет итогов».

Или выполнить аналогичную операцию программно через РегистрыНакопления[ИмяРегистра].УстановитьИспользованиеИтогов(Истина).

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