Чем перечисление отличается от справочника в 1С

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

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

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

Что такое перечисление и как оно устроено

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

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

Классические примеры перечислений из типовых конфигураций: виды операций документов, ставки НДС в старых версиях конфигураций, способы округления, пол физического лица, статусы с ограниченным набором. Общий признак — список закрыт, известен заранее и привязан к логике программы.

Что такое справочник и как он устроен

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

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

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

Ключевые отличия: сравнение по параметрам

Различия удобно рассмотреть по конкретным техническим и прикладным критериям — от места хранения до поведения в запросах.

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

Когда выбирать перечисление

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

Второй сценарий — системные статусы и признаки с жёстким набором: пол, признаки «да/нет/неизвестно», направления сортировки, типы периодов. Здесь перечисление защищает данные от порчи: пользователь физически не сможет ввести значение вне допустимого списка.

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

Маршрут решения

Как выбрать тип объекта

Список значений фиксирован и каждое значение обрабатывается своим кодомСоздавайте перечисление

Пользователи должны добавлять значения без обращения к разработчикуСоздавайте справочник

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

Значения должны совпадать во всех узлах обмена без сопоставленияСоздавайте перечисление

Часть значений системная, но список должен расширятьсяСправочник с предопределёнными элементами

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

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

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

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

Типичные ошибки при выборе и их последствия

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

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

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

Как проверить правильность проектного решения

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

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

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

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

Кто добавляет новые значения

Норма

Пользователи добавляют элементы справочника сами, перечисления не меняются месяцами

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

Каждая неделя начинается с просьбы добавить значение в конфигураторе

Защита системных значений

Норма

Системные значения — перечисления или предопределённые элементы

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

Пользователь может удалить элемент, от которого зависит проведение документов

Дополнительные атрибуты

Норма

Все параметры значения хранятся в реквизитах справочника

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

Параметры зашиты в коде рядом со значением перечисления

Обмен между базами

Норма

Перечисления совпадают, ссылки справочников сопоставляются по GUID или коду

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

После обмена появляются дубли системных значений

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

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

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

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

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

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

Можно ли пользователю добавить значение в перечисление?

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

Что быстрее работает в запросах — перечисление или справочник?

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

Можно ли переделать перечисление в справочник на работающей базе?

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

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

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

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

В таблицах базы данных значение перечисления хранится как порядковый номер. Если вставить новое значение в середину списка, номера последующих значений сместятся, и ранее записанные документы начнут ссылаться на другие значения. Безопасно добавлять новые значения только в конец.

Что выбрать для списка ставок НДС?

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