Регистр сведений в 1С: чем реквизиты отличаются от ресурсов

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

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

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

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

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

Классический пример — регистр «Цены номенклатуры». Измерение — «Номенклатура» (и, возможно, «ТипЦен»), ресурс — «Цена», реквизит — «Поставщик» или «Комментарий». По ключу «товар + тип цен» система однозначно находит цену, а реквизит лишь поясняет, откуда эта цена взялась.

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

Что такое ресурс и когда поле должно быть ресурсом

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

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

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

Что такое реквизит и когда его достаточно

Реквизит — это пояснение к записи. Типичные примеры: документ-регистратор, внёсший запись (для независимых регистров), ответственный пользователь, примечание, признак ручного редактирования, внешний идентификатор источника данных. Эти сведения полезны для анализа и аудита, но не являются предметом хранения.

Реквизиты не входят в ключ записи и не влияют на уникальность. Два одинаковых по измерениям набора с разными реквизитами невозможны независимо от значений реквизитов — платформа не даст записать вторую запись с тем же ключом. Поэтому переносить «важное» поле в реквизиты в надежде обойти контроль уникальности бессмысленно.

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

Сравнение ресурсов и реквизитов по ключевым признакам

Чтобы выбор роли был осознанным, удобно сопоставить оба варианта по практическим критериям. Таблица ниже отражает поведение платформы, а не оформление в конфигураторе.

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

Куда отнести поле

Ресурс

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

Реквизит

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

Измерение

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

Как выбрать роль поля: порядок действий

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

1. 1
   Сформулируйте вопрос, на который отвечает поле: «сколько/какое значение» — кандидат в ресурсы; «кто/откуда/почему» — кандидат в реквизиты; «в разрезе чего» — кандидат в измерения.
2. 2
   Проверьте тест на удаление: мысленно очистите поле. Запись потеряла смысл — это ресурс. Запись осталась полезной — реквизит.
3. 3
   Проверьте, нужны ли по полю отборы и соединения в запросах. Если да — поле должно быть измерением, а не ресурсом и не реквизитом.
4. 4
   Убедитесь, что поле не дублирует измерение: хранить в ресурсе копию измерения — избыточность и источник рассинхронизации.
5. 5
   Проверьте планы обмена и типовые механизмы: если регистр участвует в синхронизации, убедитесь, что новое поле включено в состав данных обмена.
6. 6
   Обновите конфигурацию базы данных и проверьте запись и чтение на тестовой копии, включая срез последних для периодического регистра.

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

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

Влияние роли поля на запросы и производительность

В запросах ресурсы и реквизиты обращаются одинаково — по имени поля. Различия проявляются в виртуальных таблицах и в семантике типовых решений. Например, при обращении к «СрезПоследних» платформа строит выборку максимальных периодов по ключу и подтягивает значения ресурсов; реквизиты присоединяются к найденной записи. Если вы по ошибке сделали значение реквизитом, запрос его вернёт, но смысловая модель регистра нарушится — и следующие разработчики будут трактовать структуру неверно.

Пример запроса к периодическому регистру сведений с корректной структурой:

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

Здесь «Цена» — ресурс, «Комментарий» — реквизит, «Номенклатура» — измерение. Запрос корректен в любом случае, но если бы «Цена» была реквизитом, а «Комментарий» — ресурсом, структура вводила бы в заблуждение: типовые обработчики и соглашения о наименовании ожидают, что значение регистра лежит в ресурсе.

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

Частый приём в типовых конфигурациях — добавлять реквизит «Автор» или «ИсточникДанных» в регистры, которые заполняются и обменами, и вручную. По этому реквизиту потом удобно строить аудит: кто и откуда внёс запись. Значение регистра при этом остаётся в ресурсе, и механика срезов не нарушается.

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

Первая и главная ошибка — объявление значения реквизитом «на всякий случай», потому что «ресурс звучит как-то серьёзно». Последствие: структура регистра перестаёт отражать смысл данных, отчёты и доработки строятся на неверных предположениях, а при чтении кода непонятно, что является значением записи.

Вторая ошибка — обратная: помещение в ресурсы служебных полей. Например, ресурс «ДокументРегистратор» в независимом регистре. Записей с пустым «значением» становится много, срезы возвращают ссылку на документ как «значение регистра», и аналитика по регистру искажается. Документ-основание — классический реквизит.

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

Как проверить правильность структуры регистра

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

Контрольные точки

Как проверить результат

Смысл записи

Норма

Очистка реквизитов не лишает запись смысла; значение лежит в ресурсе

Тревожный признак

Без «реквизита» запись бесполезна — поле нужно перенести в ресурсы

Срез последних

Норма

Срез возвращает ожидаемое значение ресурса на дату

Тревожный признак

В качестве значения возвращается служебное поле — перепутаны роли

Уникальность

Норма

Повторная запись с тем же ключом корректно отклоняется или перезаписывается по замещению

Тревожный признак

Ожидалась «вторая строка» с другим реквизитом — непонимание ключа регистра

Запросы и отчёты

Норма

Все обращения к полю работают после смены роли, отборы идут по измерениям

Тревожный признак

Ошибки в модулях, медленные отборы по реквизитам

Количество записей до и после обновления

Норма

Совпадает на тестовой копии

Тревожный признак

Записи потеряны — откат и анализ конфликтов уникальности

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

FAQ

Может ли регистр сведений не иметь ресурсов вообще?

Да. Регистр только с измерениями используется как хранилище фактов или признаков: например, «запрещённые к отгрузке комбинации клиент–товар». Само наличие записи с определённым ключом и есть информация. Реквизиты при этом могут пояснять, кем и когда запись добавлена.

Влияет ли выбор между ресурсом и реквизитом на уникальность записей?

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

Виден ли реквизит в срезе последних?

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

Что будет с данными, если перенести поле из реквизитов в ресурсы?

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

Когда поле лучше сделать измерением, а не ресурсом или реквизитом?

Когда поле определяет разрез хранения или по нему регулярно выполняются отборы и соединения. Например, если цены хранятся для каждого типа цен, «ТипЦен» — измерение. Если оставить его ресурсом, одна запись на товар не сможет хранить несколько цен, а отборы будут медленными.

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

Только контекстом. У справочника реквизиты описывают объект целиком и доступны всегда; у регистра сведений реквизит описывает конкретную запись с определённым ключом и появляется или исчезает вместе с ней. Принцип «пояснение, а не значение» в обоих случаях одинаков.