Перечисление и справочник в 1С: ключевые отличия и когда что использовать

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

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

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

1. Структурные различия: как устроены перечисления и справочники

Начнём с фундаментального: перечисление в 1С — это статический список предопределённых значений, жёстко заданный на этапе конфигурирования. Его элементы хранятся непосредственно в метаданных базы и не имеют собственных реквизитов (за исключением синонимов и представлений). Например, перечисление ВидыНалогов может содержать значения НДС_20, НДС_10, БезНДС — и этот список не изменится, пока разработчик не отредактирует конфигурацию.

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

📌 Перечисление: фиксированный набор значений, изменяемый только в конфигураторе. Пример: СтатусыДокументов (Черновик, Проведён, Отменён).
📖 Справочник: динамическая коллекция записей с произвольной структурой. Пример: Номенклатура (товары, услуги, комплекты).
🔄 Гибридный подход: иногда справочники используют для эмуляции перечислений (с флагом "Предопределённые элементы"), но это антипаттерн — об этом ниже.

Ключевое следствие: перечисления не имеют истории изменений — их значения существуют "вечно" в неизменном виде. Справочники же поддерживают механизмы версионирования, пометки на удаление и даже полноценный журнал изменений (если настроен).

2. Производительность и оптимизация: что работает быстрее

С точки зрения производительности перечисления выигрывают с разгромным счётом. Их значения хранятся в компактном виде (фактически как числовые идентификаторы) и не требуют обращений к таблицам базы данных. Например, сравнение двух значений перечисления сводится к сравнению чисел, тогда как для справочников 1С выполняет запрос к СУБД.

Разница становится критичной в циклах или при обработке больших массивов данных. Представьте отчёт, который анализирует статусы 100 000 документов:

⚡ Перечисление: сравнение Если Статус = Перечисления.СтатусыДокументов.Проведён Тогда... выполняется за доли миллисекунд.
🐢 Справочник: проверка Если Статус.Ссылка = Справочники.СтатусыДокументов.Проведён Тогда... требует обращения к базе и может тормозить при больших объёмах.

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

⚠️ Внимание: Не используйте справочники вместо перечислений в высоконагруженных расчётах (например, в алгоритмах ценообразования или логистики). Замена перечисления ВидыСкидок на справочник может увеличить время выполнения отчёта в 10–100 раз.

Критерий	Перечисление	Справочник
Скорость сравнения значений	Мгновенно (числовое сравнение)	Зависит от индексов (может быть медленно)
Память/дисковое пространство	Минимальное (хранится в метаданных)	Значительное (таблицы в СУБД)
Поддержка транзакций	Нет (изменения только в конфигураторе)	Да (полноценная работа в пользовательском режиме)
Гибкость структуры	Отсутствует (только синонимы)	Любые реквизиты, табличные части, формы

3. Когда использовать перечисление: 5 однозначных сценариев

Перечисления идеальны для закрытых наборов значений, которые:

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

Типичные примеры:

📄 Статусы документов: Черновик, НаСогласовании, Проведён.
💰 Виды оплат: Наличные, БезналичныйРасчёт, Карта.
📦 Типы упаковок: Коробка, Палетта, Контейнер.
📊 Виды отчётов: Ежедневный, Недельный, Месячный.
🔧 Типы ошибок: Предупреждение, Ошибка, КритическаяОшибка.

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

💡

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

4. Когда нужен справочник: динамика и гибкость

Справочники незаменимы, когда:

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

Классические примеры:

👤 Контрагенты: юридические и физические лица с реквизитами (ИНН, КПП, адреса).
📦 Номенклатура: товары и услуги с ценами, остатками, характеристиками.
🏢 Склады: с адресами, ответственными лицами, графиками работы.
👔 Сотрудники: с должностями, отделами, контактными данными.

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

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

- Значения будут добавляться пользователями в процессе работы?|+

- Нужно хранить дополнительные атрибуты (например, описание, дату создания)?|+

- Требуется иерархия (группы/подгруппы)?|+

- Значения могут меняться со временем (например, список городов)?|+

- Если хотя бы на один вопрос ответ "да" — используйте справочник.-->

5. Типичные ошибки и антипаттерны

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

❌ Антипаттерн 1: Справочник вместо перечисления для фиксированных значений

Пример: создание справочника ВидыНалогов с предопределёнными элементами НДС_20, НДС_10. Проблема: каждый раз при обращении к такому справочнику 1С выполняет запрос к базе, хотя можно было обойтись сравнением чисел (как в перечислении).

❌ Антипаттерн 2: Перечисление для динамических данных

Пример: хранение списка ГородаДоставки в перечислении. Проблема: при добавлении нового города потребуется обновление конфигурации и перезапуск базы — это недопустимо для бизнес-процессов.

❌ Антипаттерн 3: Избыточные реквизиты в перечислениях

Некоторые пытаются "расширить" перечисления, добавляя к ним реквизиты через обходные пути (например, используя синонимы для хранения дополнительных данных). Проблема: это нарушает архитектуру 1С и ведёт к ошибкам при обновлениях платформы.

Как избежать ошибок?

🔍 Правило 80/20: если 80% значений статичны и только 20% могут меняться — разделите их на перечисление + справочник.
📏 Тест на масштабируемость: спросите себя: "Что будет, если через год количество значений вырастет в 10 раз?" Если ответ "ничего страшного" — берите справочник.
⚖️ Баланс производительности: в критических по скорости местах (отчёты, расчёты) отдавайте предпочтение перечислениям.

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

В лучшем случае — незначительное падение производительности. В худшем — критические тормоза при массовых операциях (например, при проведении документов с проверкой статусов). Например, если в документе ЗаказПокупателя статус хранится как ссылка на справочник, то при выборке 10 000 заказов 1С выполнит 10 000 запросов к базе вместо одного сравнения чисел.-->

6. Практические примеры

разбор реальных кейсов

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

📌 Кейс 1: Статусы заказов в интернет-магазине

Задача: хранить статусы заказов (Новый, Оплачен, Отгружен, Завершён) и отображать их в личном кабинете клиента.

Решение: Перечисление СтатусыЗаказов. Почему?

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

📌 Кейс 2: Список поставщиков

Задача: вести базу поставщиков с контактными данными, условиями сотрудничества и историей заказов.

Решение: Справочник Поставщики. Почему?

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

А теперь гибридный кейс:

📌 Кейс 3: Виды доставки

Задача: хранить стандартные виды доставки (Курьер, Почта, Самовывоз) и позволяют пользователям добавлять свои (например, Транспортная компания X).

Решение: Комбинация!

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

7. Работа с перечислениями и справочниками в коде: синтаксис и нюансы

Давайте посмотрим, как объекты ведут себя в 1С:Предприятие 8 на уровне встроенного языка.

🔹 Перечисления: простота и скорость

Обращение к значениям перечисления тривиально:

Если ТекущийСтатус = Перечисления.СтатусыДокументов.Проведён Тогда // Логика для проведённых документов

КонецЕсли;

Преимущества:

⚡ Нет обращений к базе — сравнение происходит на уровне платформы.
🔍 Автодополнение в конфигураторе (видно все возможные значения).
📌 Возможность использования в аннотациях типов (например, в 1С:EDT).

🔹 Справочники: гибкость ценой сложности

Работа со справочниками требует учёта ссылочности:

Если ТекущийСтатус.Ссылка = Справочники.СтатусыДокументов.Проведён Тогда // Логика для проведённых документов // ВНИМАНИЕ: здесь происходит обращение к базе!

КонецЕсли;

Нюансы:

🔗 Всегда проверяйте ссылки на ПустаяСсылка() — справочники могут содержать NULL.
🔄 Для массовых операций используйте менеджеры записей или временные таблицы.
📊 При выборках добавляйте индексируемые поля в условия (ГДЕ Код = "001" вместо ГДЕ Наименование = "Молоко").

Особое внимание уделите предопределённым элементам справочников. Они создаются в конфигураторе и ведут себя почти как перечисления, но всё равно требуют обращения к базе. Пример:

// Некорректно (обращение к базе): Если Статус = Справочники.СтатусыДокументов.Проведён Тогда // Корректно (сравнение по ссылке):

Если Статус.Ссылка = Справочники.СтатусыДокументов.Проведён Тогда

⚠️ Внимание: В новых версиях 1С:Предприятие 8.3.20+ появилась возможность использовать перечисления в ЗАПРОС напрямую (через конструкцию ЗНАЧЕНИЕ(Перечисление.Имя.Значение)). Это упрощает работу с ними в отчётах. Однако в старых версиях для фильтрации по перечислениям приходилось использовать обходные пути (например, хранение числовых идентификаторов в виртуальных таблицах).

FAQ: Ответы на частые вопросы

❓ Можно ли конвертировать справочник в перечисление (и наоборот) без потери данных?

Технически да, но это нетривиальная задача:

🔄 Справочник → Перечисление: нужно вручную перенести все значения в новое перечисление, затем обновить код, где использовались ссылки. Данные в базе останутся, но логика работы изменится.
🔀 Перечисление → Справочник: проще — создаёте справочник, заполняете его предопределёнными элементами и меняете тип реквизитов в документах. Однако сравнения в коде станут медленнее.

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

❓ Как узнать, сколько памяти занимает перечисление vs справочник?

Перечисления занимают минимальное пространство — их значения хранятся как числовые идентификаторы (обычно 4 байта на значение). Справочники же хранятся в таблицах СУБД, и их размер зависит от:

Количества записей.
Количества и типов реквизитов (строка, число, дата и т.д.).
Наличия табличных частей.
Индексов и служебных полей (например, ПометкаУдаления).

Чтобы оценить размер справочника, используйте запрос к системным таблицам (например, SELECT SUM(LENGTH) FROM Information_Schema.Tables WHERE Table_Name LIKE 'SC%' для MS SQL).

❓ Почему в некоторых конфигурациях статусы документов сделаны справочниками, а не перечислениями?

Это обычно наследие старых версий или ошибка проектирования. Возможные причины:

🕰️ Исторические причины: в ранних версиях 1С 7.7 не было перечислений, и при миграции на 8.x их не всегда заменяли.
🔧 Гибкость: иногда статусы нужно настраивать под конкретного клиента (например, добавлять промежуточные этапы).
📊 Отчётность: если по статусам строятся сложные отчёты с группировками, справочники дают больше возможностей для анализа.

Однако в 99% случаев для статусов документов перечисление предпочтительнее — оно проще, быстрее и надёжнее.

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

Нет, перечисления в 1С всегда плоские (одноуровневые). Если нужна иерархия, используйте:

📖 Справочник с включённым режимом иерархии.
🔢 Несколько перечислений (например, КатегорииТоваров и ПодкатегорииТоваров).
🏷️ Регистр сведений с измерением "Родитель" (для сложных иерархий).

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

❓ Как правильно назвать перечисление или справочник, чтобы не путаться?

Следуйте соглашениям о наименовании:

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

Это поможет отличать объекты по именам в коде и избегать путаницы при рефакторинге.

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