Регистры сведений в 1С: зачем нужны и как с ними работать

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

Главная особенность регистра сведений — структура «измерение + ресурс». Измерения задают координаты хранения (например, номенклатура и тип цен), а ресурсы — сами значения (цена). Такая модель позволяет быстро получать данные по ключу без сложных запросов и хранить историю изменений, если регистр объявлен периодическим.

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

Что такое регистр сведений и как он устроен

Регистр сведений состоит из трёх групп полей. Измерения — это ключи, по которым идентифицируется запись: например, «Номенклатура» и «ТипЦен». Ресурсы — хранимые значения: «Цена», «ПроцентСкидки». Реквизиты — дополнительная поясняющая информация, которая не входит в ключ и не является основным значением, например «Комментарий» или «Автор записи».

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

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

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

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

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

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

Зачем регистры сведений нужны на практике

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

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

Третий сценарий — контактная информация и дополнительные сведения. Адреса, телефоны, банковские счета удобно хранить в регистре с измерениями «Объект» и «Вид контактной информации»: один объект может иметь несколько адресов разных видов, и структура легко расширяется без изменения справочников.

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

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

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

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

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

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

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

// Запись цены в независимый периодический регистр
Запись = РегистрыСведений.ЦеныНоменклатуры.СоздатьМенеджерЗаписи();
Запись.Период = ТекущаяДатаСеанса();
Запись.Номенклатура = Товар;
Запись.ТипЦен = ТипЦены;
Запись.Цена = 1500;
Запись.Записать();

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

1. 1
   Определите, какие объекты задают ключ записи — это измерения
2. 2
   Решите, нужна ли история: да — периодический, нет — непериодический
3. 3
   Определите источник записи: вручную/программно — независимый, документ — подчинённый
4. 4
   Добавьте ресурсы (хранимые значения) и реквизиты (пояснения)
5. 5
   Создайте формы списка и записи, настройте права доступа
6. 6
   Проверьте заполнение на тестовых данных и работу среза последних

Типичные ошибки и ограничения

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

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

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

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

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

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

Часто задаваемые вопросы