Справочник и регистр в 1С: 7 ключевых отличий и правила выбора

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

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

Материал будет полезен как начинающим специалистам, так и тем, кто хочет систематизировать знания. Мы не будем углубляться в синтаксис — сосредоточимся на логике работы и практических последствиях выбора того или иного объекта. Готовы разобраться раз и навсегда?

1. Назначение: статика vs динамика данных

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

Примеры из жизни:

• 📚 Справочник: Контрагенты, Номенклатура, Склады — это «карточки» объектов, которые редко меняют свои атрибуты (название, адрес, категория).
• 📊 Регистр: ОстаткиТоваров, ПродажиПоДням, ЗарплатаСотрудников — здесь фиксируются текущие состояния (сколько товара на складе сейчас) или исторические события (какие продажи были вчера).

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

2. Структура хранения: иерархия vs измерения и ресурсы

Справочники и регистры организуют данные по-разному на уровне физической структуры базы. Это влияет на скорость выборок, объём занимаемого пространства и даже на то, как 1С строит SQL-запросы «под капотом».

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

• 🌳 Поддерживают Иерархию (группы и элементы) — например, в Номенклатуре можно создать группы «Электроника» → «Телефоны» → «Смартфоны».
• 🔄 Каждый элемент имеет уникальный идентификатор (Ссылка), по которому к нему можно обращаться из других объектов.
• 📂 Реквизиты хранятся непосредственно в таблице справочника (например, Наименование, Артикул).

Регистры используют модель многомерного хранилища:

• 📏 Измерения — «координаты» записи (например, Номенклатура, Склад, Дата).
• 💰 Ресурсы — количественные показатели (например, Количество, Сумма).
• ⏳ Реквизиты — дополнительные атрибуты (например, ВалютныйКурс в регистре валют).

Характеристика	Справочник	Регистр
Основная модель	Иерархическая (дерево)	Многомерная (куб)
Уникальный идентификатор	Ссылка (GUID)	Комбинация измерений + дата/период
Типичный объём данных	Сотни–тысячи записей	Миллионы–миллиарды записей
Поддержка истории изменений	Только через механизм версий	Встроена (периодичность)

3. Производительность: что быстрее и почему

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

Справочники оптимизированы для:

• 🔍 Быстрого поиска по реквизитам (индексы на Наименование, Код).
• 📖 Чтения отдельных записей (например, открытие карточки контрагента).
• 🌐 Иерархических выборок (получение всех элементов группы).

Но они тормозят, если пытаться использовать их для хранения транзакционных данных (например, остатков товаров). Почему? Потому что:

• 🐢 Нет встроенных механизмов агрегации (придётся писать сложные запросы с ГРУППИРОВКА).
• 🧹 Нет автоматической «чистки» устаревших данных (в отличие от регистров с периодичностью).

Регистры заточены под:

• ⚡ Мгновенное получение агрегированных данных (например, «остатки по складу на дату»).
• 📈 Аналитику по измерениям (срезы по Номенклатуре, Складу, Периоду).
• 🔄 Автоматическое поддержание актуальности (механизмы перерасчёта при проведении документов).

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

4. Механизмы обновления: кто и как меняет данные

Способы модификации данных в справочниках и регистрах кардинально отличаются. Это влияет на целостность информации, возможность отката изменений и даже на то, как строится бизнес-логика в конфигурации.

Справочники меняются:

• ✏️ Вручную — пользователь открывает форму элемента и редактирует реквизиты.
• 🤖 Программно — через методы Записать, УстановитьРеквизит.
• 🔄 Обменами — при синхронизации с другими базами или внешними системами.

⚠️ Внимание: При прямом изменении реквизитов справочника через код не создаются движения по регистрам. Например, если вы вручную поменяете цену номенклатуры, это не отразится в регистре ЦеныНоменклатуры — придётся перепровести связанные документы.

Регистры обновляются только через:

• 📄 Движения документов — основной способ. Например, документ ПоступлениеТоваров создаёт движения в регистре ТоварыНаСкладах.
• 🖥️ Прямую запись (метод Записать) — используется редко, только в служебных обработках.
• 🔄 Перерасчёт — например, восстановление последовательности партий.

⚠️ Внимание: Если вы вручную измените запись в регистре накопления (например, исправите остаток товара), система не гарантирует целостность данных. При следующем проведении документа, затрагивающего этот товар, ваши правки могут быть перезаписаны!

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

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

5. Периодичность и история изменений

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

Справочники и история:

• 🕰️ По умолчанию нет истории — если пользователь изменил реквизит, старая версия теряется.
• 🔙 Механизм Версии данных позволяет отслеживать изменения, но:
  • 🛑 Требует настройки (включается в конфигураторе).
  • 🐢 Замедляет работу при частых изменениях.
  • 📦 Хранит все версии, даже если нужна только последняя.

Регистры и время:

• 📅 Периодические регистры сведений хранят данные с привязкой к дате (например, курсы валют на каждый день).
• ⏳ Регистры накопления автоматически поддерживают остатки и обороты по периодам.
• 🔍 Можно получить состояние «на дату» без дополнительных запросов:

  Остатки = РегистрыНакопления.ТоварыНаСкладах.Остатки(ДатаКонца, Номенклатура = СсылкаНаТовар);

Сценарий	Справочник	Регистр
Хранение цены номенклатуры	❌ Неудобно (нет истории)	✅ Идеально (РегистрСведений.ЦеныНоменклатуры)
Отслеживание изменений адреса клиента	✅ Возможно (через версии)	❌ Не предназначен
Расчёт остатков товаров на складе	❌ Категорически нельзя	✅ Основное назначение

6. Практические примеры: когда что использовать

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

Кейс 1: Хранение справочной информации о товарах

• ✅ Правильно: Справочник Номенклатура с реквизитами Наименование, Артикул, ЕдиницаИзмерения.
• ❌ Ошибка: Создать регистр сведений ДанныеНоменклатуры и хранить там те же данные. Почему плохо?
  • 🐢 Медленный поиск по наименованию (нет оптимизированных индексов).
  • 🔗 Сложно организовать иерархию (группы товаров).
  • 📉 Избыточный расход памяти (регистры не предназначены для статичных данных).

Кейс 2: Учёт остатков товаров на складах

• ✅ Правильно: Регистр накопления ТоварыНаСкладах с измерениями Номенклатура, Склад и ресурсом Количество.
• ❌ Ошибка: Добавить в справочник Номенклатура реквизит ОстатокНаСкладе и обновлять его вручную. Почему плохо?
  • 💥 Нет гарантии целостности (при ошибке в коде остатки разъедутся).
  • 📊 Невозможно получить остатки «на дату» без сложных запросов.
  • 🔄 При обменах данными придётся пересчитывать остатки полностью.

Кейс 3: Хранение истории цен номенклатуры

• ✅ Правильно: Периодический регистр сведений ЦеныНоменклатуры с измерениями Номенклатура, ТипЦены и ресурсом Цена.
• ❌ Ошибка: Добавить в справочник Номенклатура реквизит Цена и обновлять его. Почему плохо?
  • 📅 Нет истории (нельзя узнать, какая цена была вчера).
  • 📈 Невозможно анализировать динамику изменения цен.

Данные статичные (редко меняются)? → Справочник|

Нужна история изменений по датам? → Регистр сведений|

Нужно рассчитывать остатки/обороты? → Регистр накопления|

Требуется иерархия (группы/подгруппы)? → Справочник|

Данные обновляются документами? → Регистр-->

7. Ошибки начинающих и как их избежать

Даже опытные разработчики иногда допускают ошибки при выборе между справочниками и регистрами. Вот топ-5 антипатернов, которые приводят к проблемам в поддержке:

1. Хранение остатков в справочнике

⚠️ Внимание: Если вы видите в справочнике Номенклатура реквизит Остаток или КоличествоНаСкладе, это верный признак архитектурной ошибки. Такие данные обязательно должны храниться в регистре накопления!

2. Использование регистра сведений вместо справочника

• 🚫 Пример: создание регистра СписокКонтрагентов вместо справочника Контрагенты.
• 💡 Почему плохо: регистры не оптимизированы для хранения статичных данных и не поддерживают удобный интерфейс работы (формы списка/элемента).

3. Игнорирование периодичности

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

4. Ручное изменение регистров накопления

• 🚫 Пример: правка остатков в регистре ТоварыНаСкладах через Записать.
• 💡 Почему плохо: нарушается целостность данных, возможны расхождения с документами.

5. Избыточная детализация в регистрах

• 🚫 Пример: добавление в регистр накопления Продажи измерения Менеджер, если аналитика по менеджерам не нужна.
• 💡 Почему плохо: каждое лишнее измерение увеличивает размер регистра и замедляет выборки.

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

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

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

Почему в типовой конфигурации УТ 11 справочник «Номенклатура» не хранит остатки, а использует регистр?

Потому что остатки — это динамические данные, которые:

• Меняются сотни раз в день (приход, расход, перемещение).
• Требуют расчёта «на дату» (например, для отчётов или резервирования).
• Должны поддерживать целостность (связь с документами).

Регистр накопления ТоварыНаСкладах решает эти задачи «из коробки», тогда как справочник потребовал бы сложной доработки.

Как перенести данные из справочника в регистр, если изначально выбрали неверный объект?

Процесс миграции включает несколько шагов:

1. Создайте новый регистр с нужной структурой (измерения, ресурсы).
2. Напишите обработку, которая:
   • Читает данные из справочника.
   • Формирует движения в регистре (например, документом ВводНачальныхОстатков).

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

Удалите или архивируйте старые данные в справочнике (если они больше не нужны).

⚠️ Внимание: Перед миграцией обязательно сделайте резервную копию базы! Если в справочнике были данные, критичные для работы (например, ссылки на элементы), их придётся актуализировать в связанных объектах.

Можно ли использовать регистр сведений для хранения больших бинарных данных (например, фотографий товаров)?

Технически можно, но крайне не рекомендуется. Регистры оптимизированы для хранения структурированных данных (числа, строки, ссылки), а не для бинарных объектов. Для фотографий лучше:

• Использовать реквизит типа ХранилищеЗначения в справочнике Номенклатура.
• Хранить файлы во внешней системе (например, на диске или в облаке) и keeps ссылки в 1С.

Бинарные данные в регистрах приведут к раздутию базы и замедлению выборок.

Чем регистр бухгалтерии отличается от регистра накопления?

Регистр бухгалтерии — это специализированный регистр накопления, который:

• 📌 Привязан к плану счетов (измерение СчетБухгалтерскогоУчета обязательно).
• 💰 Поддерживает двойную запись (дебет/кредит), как в классическом бухучёте.
• 📊 Автоматически формирует бухгалтерские отчёты (оборотно-сальдовую ведомость, баланс).

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