Очистятся ли данные регистра сведений при изменении его подчиненности регистратору?

← На главную

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

Анализ поведения платформы при реструктуризации

Разберем основной вопрос: сохранятся ли данные? Ответ однозначный — нет, данные будут полностью удалены. Рассмотрим подробнее техническую причину этого процесса. Когда мы меняем режим записи регистра сведений, платформа инициирует процесс реструктуризации таблиц в базе данных на уровне СУБД (SQL Server, PostgreSQL и др.).

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

Регистратор (Recorder) — ссылка на документ, который создал запись.
НомерСтроки (LineNo) — порядковый номер записи в наборе, принадлежащем конкретному регистратору.

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

Почему это происходит: заглянем внутрь структуры

Проанализируем ситуацию с точки зрения индексов и производительности. При переходе к подчиненному регистру 1С автоматически перестраивает индексы. Если раньше поиск и уникальность базировались на измерениях, то теперь в состав кластерного индекса включается поле Регистратор. Это меняет логику работы оптимизатора запросов СУБД.

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

Как проверить поведение системы без риска для данных

Посмотрим на практический совет, который часто дают опытные разработчики. Если у вас нет возможности быстро сделать копию огромной рабочей базы, мы можем выполнить простую проверку в тестовой среде:

Создадим пустую конфигурацию.
Добавим в неё РегистрСведений с режимом записи «Независимый».
Добавим пару измерений и ресурсов, заполним регистр несколькими записями в режиме «1С:Предприятие».
В конфигураторе изменим режим записи на «Подчинение регистратору» и добавим документ, который будет выступать регистратором.
Применим изменения (F7) и убедимся, что таблица стала пустой.

Этот простой эксперимент наглядно подтверждает теоретические выкладки: реструктуризация со сменой подчиненности — это деструктивная операция для данных.

Пошаговый алгоритм миграции данных

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

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

Пример кода для программной записи данных в подчиненный регистр может выглядеть так:


НаборЗаписей = РегистрыСведений.НашРегистр.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Регистратор.Установить(СсылкаНаНовыйДокумент);

НоваяЗапись = НаборЗаписей.Добавить();
НоваяЗапись.Период = ДатаИзФайла;
НоваяЗапись.Измерение1 = ЗначениеИзФайла;
// Заполнение остальных полей...

НаборЗаписей.Записать();

Важные нюансы и последствия изменений

Рассмотрим дополнительные аспекты, которые могут повлиять на работу системы после изменения подчиненности:

Изменение логики срезов: Методы СрезПоследних() и СрезПервых() для подчиненных регистров начинают работать иначе. Они учитывают момент времени документа, а не просто календарную дату. Это может привести к тому, что существующие отчеты начнут выдавать иные результаты, если в одну секунду было введено несколько документов.

Блокировки данных: В независимом регистре блокировки обычно происходят по значениям измерений. В подчиненном же регистре блокируется весь набор записей по конкретному Регистратору. Если один документ делает тысячи записей, это может снизить параллельность работы пользователей.

Метод записи: Даже если регистр подчинен, в его свойствах есть флаг «Запись только через регистратор». Если установить его в значение Ложь, вы сможете записывать данные программно, не проводя документ, но наличие ссылки на Регистратор в каждой записи всё равно останется обязательным.

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