Разработка и Конфигурация · 13 мин
Измерения в регистре сведений 1С: что это и как с ними работать
Измерения в регистре сведений 1С: что это такое, зачем нужны, как добавить и изменить без потери данных. Практические примеры, типичные ошибки и FAQ.
Регистр сведений в 1С — это объект конфигурации для хранения информации в разрезе заданных аналитик: курсов валют, цен номенклатуры, адресов контрагентов, настроек пользователей. Ключевую роль в структуре такого регистра играют измерения — именно они определяют, «в разрезе чего» хранятся данные, и формируют уникальность записей.
Ошибки в проектировании измерений — одна из самых дорогих проблем при разработке: после того как регистр наполнен данными в рабочей базе, изменить состав измерений без потери информации бывает сложно или невозможно. Поэтому понимать устройство измерений нужно до создания регистра, а не после.
Материал рассчитан на разработчиков и администраторов 1С: разберём, что такое измерение, чем оно отличается от ресурса и реквизита, как работает уникальность записей, как добавить или удалить измерение в существующем регистре и какие ограничения стоит учитывать.
Что такое измерение регистра сведений
Измерение — это поле регистра сведений, значение которого участвует в формировании ключа записи. Если регистр хранит цены номенклатуры, измерением обычно выступает «Номенклатура», а ресурсом — «Цена». Смысл простой: измерение отвечает на вопрос «для чего или кого хранится значение», ресурс — «что именно хранится».
Физически каждое измерение — это колонка в таблице регистра в базе данных. По комбинации измерений платформа строит индекс уникальности, поэтому поиск записи по полному набору измерений выполняется быстро даже в больших таблицах.
Количество измерений в регистре сведений не ограничено жёстко, но на практике редко используют больше 3–5. Каждое дополнительное измерение увеличивает размер ключа, усложняет логику записи и замедляет операции выборки по неполному набору разрезов.
Измерения, ресурсы и реквизиты: в чём разница
В структуре регистра сведений три вида полей, и их часто путают. Различие принципиально, потому что от него зависит уникальность записей и поведение запросов.
| Вид поля | Роль | Участвует в ключе уникальности | Пример |
|---|---|---|---|
| Измерение | Аналитический разрез хранения | Да | Номенклатура, Сотрудник, Организация |
| Ресурс | Хранимое значение | Нет | Цена, Курс, Ставка |
| Реквизит | Дополнительная информация к записи | Нет | Комментарий, Автор записи |
Практическое следствие: если сделать «Цену» измерением, то для одной номенклатуры можно будет хранить несколько записей с разными ценами одновременно — ключ станет «Номенклатура + Цена». Это ломает логику «актуальная цена» и приводит к неоднозначным выборкам. Обратная ошибка — сделать измерением то, что должно быть ресурсом, невозможно заметить сразу: регистр работает, но данные дублируются.
Реквизиты не участвуют в ключе, поэтому по ним нельзя однозначно идентифицировать запись. Их используют для служебных пометок, которые не влияют на аналитику.
Как измерения формируют уникальность записей
Для непериодического регистра сведений уникальный ключ — это комбинация значений всех измерений. Для периодического к ключу добавляется поле «Период»: одна и та же комбинация измерений может встречаться много раз, но с разными датами.
Это свойство работает в обе стороны. С одной стороны, платформа сама защищает данные от дублей: попытка записать второй набор с тем же ключом вызовет ошибку «Запись с такими ключевыми полями существует». С другой стороны, метод Записать() менеджера записи с существующим ключом не добавит новую строку, а перезапишет старую — это удобно для обновления значений, но опасно, если разработчик ожидал добавления.
Типичный сценарий записи из кода выглядит так:
МенеджерЗаписи = РегистрыСведений.ЦеныНоменклатуры.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Период = ТекущаяДатаСеанса();
МенеджерЗаписи.Номенклатура = НоменклатураСсылка; // измерение
МенеджерЗаписи.Цена = НоваяЦена; // ресурс
МенеджерЗаписи.Записать(Истина);
Параметр Истина в методе Записать() означает замещение существующей записи с тем же ключом. Если передать Ложь и запись с таким ключом уже есть, платформа выдаст ошибку.
Периодический и непериодический регистры: влияние на измерения
Периодичность регистра определяет, входит ли дата в ключ записи. В непериодическом регистре значение ресурса одно на комбинацию измерений — например, текущий адрес доставки контрагента. В периодическом хранится история изменений: курсы валют на каждую дату, история цен, кадровые назначения.
Для периодических регистров платформа предоставляет виртуальные таблицы СрезПоследних и СрезПервых, которые возвращают актуальные значения ресурсов на указанную дату по каждой комбинации измерений. Это основной способ получать «текущие» данные без ручного поиска максимальной даты.
Выбор между периодическим и непериодическим вариантом делается до заполнения регистра: смена периодичности у заполненного регистра — такая же рискованная операция, как изменение состава измерений, и требует переноса данных.
Сравнение вариантов
Подходит для данных без истории: текущие настройки, соответствия, штрихкоды. Ограничение — старое значение при записи теряется безвозвратно.
Подходит для данных с историей изменений: цены, курсы, ставки. Ограничение — больший объём данных и необходимость использовать срезы для получения актуальных значений.
Записи привязаны к документу-регистратору и удаляются вместе с ним. Подходит, когда данные должны изменяться только документами, а не произвольной записью.
Как добавить измерение в существующий регистр без потери данных
Добавление нового измерения — наиболее безопасная из структурных операций, но и она требует аккуратности. При реструктуризации платформа добавит колонку в таблицу, и у всех существующих записей новое измерение получит пустое значение.
Опасность в другом: если после добавления измерения в регистре окажутся записи, у которых совпадают значения старых измерений, но новое измерение у них пустое у всех — конфликта не будет, ключ просто расширится. А вот если вы планировали заполнить новое измерение разными значениями для существующих записей, делать это нужно отдельной обработкой до или сразу после обновления.
- 1Сделайте резервную копию базы или разверните копию для теста.
- 2В конфигураторе откройте регистр сведений и добавьте новое измерение, задайте тип и имя.
- 3Обновите конфигурацию базы данных — платформа выполнит реструктуризацию.
- 4Если новое измерение должно быть заполнено у старых записей, выполните обработку обновления данных.
- 5Проверьте запросом, что записи читаются корректно и дублей по новому ключу нет.
Удаление измерения — обратная операция, и она опаснее. Если после удаления измерения у нескольких записей совпадут значения оставшихся измерений, реструктуризация не сможет сохранить обе записи без нарушения уникальности. Платформа может отказаться обновлять базу или потребовать разрешить конфликт вручную. Поэтому перед удалением измерения нужно запросом проверить, есть ли потенциальные дубли по новому ключу.
Изменение типа измерения и связанные риски
Смена типа измерения (например, с «СправочникСсылка.Контрагенты» на составной тип) при реструктуризации приводит к преобразованию значений. Если старые значения не приводятся к новому типу, они будут очищены — данные в этом поле теряются безвозвратно.
Безопасный путь при необходимости сменить тип: создать новое измерение с нужным типом, перенести значения обработкой, проверить результат, затем удалить старое измерение. Это дольше, но сохраняет контроль на каждом шаге.
Отдельный случай — сужение составного типа. Если измерение имело составной тип, а вы убираете один из видов ссылок, записи со значениями исключённого типа потеряют это значение. Перед такой операцией выгрузите затронутые данные запросом и сохраните их.
Как проверить структуру и данные регистра после изменений
После любой реструктуризации регистра полезно выполнить несколько контрольных проверок. Они занимают минуты, но позволяют поймать проблему до того, как с ней столкнутся пользователи.
Первая проверка — количество записей до и после изменения. Считайте их запросом ВЫБРАТЬ КОЛИЧЕСТВО(*) ИЗ РегистрСведений.ИмяРегистра в копии базы до обновления и в рабочей после. Расхождение без объяснимой причины — сигнал о потере данных.
Вторая проверка — поиск дублей по новому ключу перед удалением измерения: сгруппируйте записи по остающимся измерениям и найдите группы с количеством больше одного. Третья — откройте несколько записей в режиме предприятия и убедитесь, что значения измерений и ресурсов на месте и отображаются корректно.
Как проверить результат
Числа совпадают или расхождение объяснимо объединением дублей
Записей стало заметно меньше без причины — вероятна потеря данных
Измерение заполнено осмысленно или осознанно оставлено пустым
Пустые значения там, где логика требует заполнения — выборки дадут неполный результат
Срезы и выборки возвращают ожидаемые данные
Ошибки запросов или пропавшие строки в отчётах
Когда измерения не нужны: альтернативные варианты
Не каждая задача требует регистра сведений с измерениями. Если данные относятся к одному объекту и не используются в аналитических выборках, их удобнее хранить в реквизитах или табличной части самого справочника или документа. Регистр сведений оправдан, когда нужна независимая от объектов таблица с быстрым доступом по ключу и историей.
Если записи должны строго контролироваться документами, выбирайте регистр сведений, подчинённый регистратору: там роль дополнительного измерения выполняет сам регистратор, а записи создаются и удаляются вместе с проведением и отменой документа. Это защищает данные от «ручных» правок в обход документооборота.
Перед созданием регистра выпишите на лист все будущие поля и пометьте каждое: участвует ли оно в ответе на вопрос «для чего хранится значение». Если да — это кандидат в измерения. Если поле просто дополняет запись, но по нему не ищут и не группируют, — оставьте его реквизитом, это упростит структуру.
Частые вопросы
Сколько измерений может быть в регистре сведений?
Жёсткого практического лимита для разработчика нет, но платформа строит по измерениям индекс уникальности, и его размер ограничен. На практике используют 1–4 измерения. Если кажется, что нужно больше, стоит пересмотреть структуру: возможно, часть разрезов логичнее вынести в реквизиты или разделить данные на два регистра.
Можно ли сделать измерение необязательным для заполнения?
Формально измерение может оставаться незаполненным — запись сохранится с пустым значением в ключе. Но логически это почти всегда ошибка проектирования: пустое значение становится полноценной частью ключа, и выборки по конкретному значению такую запись не вернут. Если разрез действительно необязателен, задумайтесь, не должен ли он быть реквизитом.
Что произойдёт, если записать набор с уже существующим ключом измерений?
Если используется режим замещения (Записать(Истина) или запись набора с замещением), старая запись будет перезаписана новыми значениями ресурсов. Если замещение отключено, платформа выдаст ошибку о нарушении уникальности, и запись не выполнится. Это штатное поведение, а не сбой.
Чем измерение регистра сведений отличается от измерения регистра накопления?
Принцип одинаковый: измерения задают аналитические разрезы. Разница в применении: в регистре накопления по измерениям рассчитываются итоги (остатки и обороты), поэтому там измерения влияют ещё и на скорость получения остатков. В регистре сведений измерения формируют только ключ записи, итоги по ним не хранятся.
Как переименовать измерение без потери данных?
Переименование в конфигураторе — безопасная операция: платформа распознаёт объект по внутреннему идентификатору, и данные при реструктуризации сохраняются. Опасно не переименование, а удаление старого измерения и создание нового с тем же именем — это разные объекты, и значения старого будут потеряны.
Можно ли использовать в измерении строку произвольной длины?
Нет. Строковое измерение должно иметь фиксированную длину, потому что оно входит в индекс уникальности. Строки неограниченной длины допустимы только в ресурсах и реквизитах. При проектировании задавайте длину с запасом, но без излишества — слишком длинный ключ замедляет работу индекса.
Что важно запомнить
Измерения — это ключевые аналитические разрезы регистра сведений: их комбинация (плюс период у периодических регистров) образует уникальный ключ записи. Проектируйте состав измерений до заполнения регистра, а любые изменения структуры в рабочей базе выполняйте только после резервного копирования и проверки на дубли по новому ключу.