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

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

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

Ниже — что именно происходит при каждом типе правки, как не потерять записи и как пережить обновление структуры на рабочей базе.

С чего начать: оценка структуры и последствий

Сначала посмотрите, как регистр устроен сейчас и кто от него зависит. Откройте свойства регистра (правый клик по нему в дереве → Свойства) и запомните три вещи:

• 🧩 Режим записи — Независимый или Подчинение регистратору. От него зависит, есть ли у записей регистратор.
• 🕒 Периодичность — от Непериодический до По позиции регистратора. Период входит в ключ записи.
• 🔑 Измерения — их набор вместе с периодом и регистратором образует уникальный ключ.

Дальше оцените, что сломается. Найдите все места, где регистр используется: в Конфигураторе это делает команда Правка → Поиск ссылок на объект (или Дополнительно → Поиск ссылок на объект в контекстном меню регистра). Платформа покажет модули, формы, запросы и отчёты, которые обращаются к регистру. Запросы к виртуальным таблицам (СрезПоследних, СрезПервых) особенно уязвимы: если убрать периодичность, эти таблицы исчезнут и код перестанет компилироваться.

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

Как добавить измерение, ресурс или реквизит

Это самый частый и самый безопасный тип правки. В дереве конфигурации раскройте регистр, встаньте на нужную ветку (Измерения, Ресурсы или Реквизиты) и нажмите Добавить (клавиша Ins). Задайте имя, тип и свойства.

Разница между ветками принципиальна:

При добавлении ресурса или реквизита структура ключа не меняется — существующие записи просто получат пустое значение в новом поле. Риска потерять данные нет.

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

Полезные свойства измерения, которые задают тут же:

• Ведущее — если объект, на который ссылается это измерение, пометить на удаление и удалить, запись регистра удалится автоматически. Удобно для справочных регистров (например, цены привязаны к номенклатуре: нет номенклатуры — не нужны и цены).
• Основной отбор — измерение попадёт в основной отбор, по нему ускоряется выборка из форм связанного объекта.
• Запрет незаполненных значений — не даёт записать пустое значение в измерение.

Тип измерения или ресурса задавайте по месту: для ссылочных данных — конкретный тип (СправочникСсылка.Номенклатура), а не Любая ссылка. Составной тип замедляет выборки и раздувает индекс, поэтому его берут только когда в одном поле реально хранятся значения разных типов.

Прежде чем расширять регистр, прикиньте, то ли это решение. Если новое значение логически относится не к записи, а к другому разрезу учёта, возможно, аккуратнее завести отдельный регистр, чем нагружать существующий лишним измерением. Лишнее измерение увеличивает размер ключа и индексов во всей таблице.

Как изменить периодичность регистра сведений

Периодичность меняется в свойствах регистра полем Периодичность. Доступные значения — от Непериодический через В пределах секунды, В пределах дня, В пределах месяца, В пределах квартала, В пределах года до По позиции регистратора.

Направление изменения решает всё:

• ⬆️ Уточнение периодичности (например, из «в пределах дня» в «в пределах секунды») безопасно: ключ становится подробнее, старые записи остаются различимыми.
• ⬇️ Огрубление периодичности (из «в пределах дня» в «в пределах месяца» или в Непериодический) опасно. Период — часть ключа. Если несколько записей после огрубления попадут в один период, они станут одинаковыми по ключу.

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

Отдельный момент — переход в Непериодический. У непериодического регистра вообще нет периода и нет виртуальных таблиц-срезов. Все запросы с СрезПоследних и СрезПервых после такого перехода перестанут работать. Сначала перепишите код и запросы, потом меняйте периодичность.

Смена режима записи и удаление полей

Режим записи переключается свойством Режим записи: Независимый ↔ Подчинение регистратору.

• У независимого регистра записи создаёт код или пользователь вручную, регистратора у них нет.
• У подчинённого регистратора записи «принадлежат» документу-регистратору и живут вместе с его движениями.

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

Удаление измерения сокращает ключ. Если после удаления несколько записей совпадут по оставшимся полям, лишние будут удалены при реструктуризации — та же логика, что при огрублении периода. Удаление ресурса или реквизита данные по ключу не рушит: просто пропадёт один столбец значений.

Порядок безопасного удаления измерения:

1. Убедитесь, что измерение больше нигде не используется (Поиск ссылок на объект).
2. Выгрузите данные регистра, если после удаления возможны совпадения ключей.
3. Удалите измерение (Del на ветке Измерения).
4. Обновите конфигурацию базы данных и, при необходимости, загрузите данные обратно.

Как правки отражаются на виртуальных таблицах и срезах

У периодического регистра сведений платформа создаёт две виртуальные таблицы:

• РегистрСведений.<Имя>.СрезПоследних(<Период>, <Условие>) — последние по времени записи на указанный момент.
• РегистрСведений.<Имя>.СрезПервых(<Период>, <Условие>) — первые записи с начала.

После изменения структуры эти таблицы ведут себя так:

• Добавили измерение — срезы продолжают работать. Новое измерение можно добавить в параметр Условие и в список выбираемых полей запроса. Старый код не ломается.
• Добавили ресурс — поле появляется в срезе автоматически, его можно выбирать в запросе.
• Убрали периодичность — виртуальные таблицы СрезПоследних и СрезПервых исчезают. Любой запрос, который к ним обращался, даст ошибку компиляции. Это главная причина переписывать код до смены периодичности, а не после.

Пример запроса к срезу после добавления измерения Организация в регистр цен:

ВЫБРАТЬ
    Цены.Номенклатура,
    Цены.Организация,
    Цены.Цена
ИЗ
    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Период, Организация = &Организация) КАК Цены

Параметр Период в срезе обязателен для периодического регистра; для получения всех последних значений без привязки к дате передавайте в него текущую дату или границу диапазона.

Обновление конфигурации базы данных и перенос записей

Пока вы правите регистр в Конфигураторе, меняется только структура конфигурации. Чтобы изменения дошли до данных, выполните Конфигурация → Обновить конфигурацию базы данных (F7). Платформа покажет окно принимаемых изменений, а структурные правки отдельно вынесет в диалог реорганизации информации — там видно, какие таблицы будут перестроены.

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

• для файловой базы — просто закройте все остальные сеансы;
• для клиент-серверной — завершите сеансы пользователей (например, через консоль администрирования кластера), затем обновляйте. Предупредите людей заранее: их работа прервётся.

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

Когда изменение опасно для ключа (удаление измерения, огрубление периода, смена режима), безопаснее не полагаться на автоматическую реструктуризацию, а перенести данные вручную:

1. До изменения напишите обработку или внешнюю обработку , которая читает все записи регистра и складывает их во временное хранилище (таблицу значений, другой регистр, выгрузку в файл).
2. Измените структуру регистра и обновите конфигурацию базы данных.
3. После изменения второй обработкой запишите данные обратно, учитывая новый ключ: при огрублении периода решите, какую запись оставить в каждом периоде; при смене режима — проставьте или уберите регистратор.

Такой перенос дольше, но вы контролируете, какие записи выживут, а не отдаёте решение платформе.

Для подчинённого регистра есть нюанс: его записи переписываются не поштучно, а наборами по регистратору (Движения.<Имя>.Записать() или через проведение документа). Поэтому при обратной загрузке данных в подчинённый регистр собирайте записи в набор на каждого регистратора, иначе предыдущие движения этого документа затрутся. Для независимого регистра такого ограничения нет — записи пишутся по одной или пачкой без привязки к документу.

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

Типичные ошибки при реструктуризации

Эти ситуации возникают именно при изменении структуры регистра — в них нет повтора шагов инструкции, только диагностика.

Частые вопросы