Справочники и Данные · 11 мин
Как описать структуру справочника 1С
Как правильно описать структуру справочника 1С: реквизиты, табличные части, иерархия, коды и наименования. Практические примеры и типичные ошибки.
Справочник в 1С — это объект конфигурации для хранения условно-постоянной нормативно-справочной информации: номенклатуры, контрагентов, сотрудников, складов, валют. Прежде чем создавать элементы и заполнять данные, нужно продумать и формально описать структуру справочника: какие у него будут реквизиты, табличные части, иерархия, длина кода и наименования. Ошибки на этом этапе дорого обходятся: изменить структуру после того, как база заполнена данными и на справочник ссылаются документы, значительно сложнее.
Описание структуры нужно в нескольких ситуациях: при проектировании новой конфигурации, при документировании существующей для обмена данными, при постановке задачи разработчику и при анализе чужой конфигурации. Во всех случаях логика одна — зафиксировать состав полей, их типы, обязательность, связи с другими объектами и правила заполнения.
Ниже разобран практический порядок описания: от стандартных реквизитов до табличных частей и подчинённых справочников, с примерами и типичными ошибками.
Что входит в структуру справочника
Структура любого справочника 1С складывается из нескольких обязательных и необязательных компонентов. Стандартные реквизиты — Код и Наименование — платформа создаёт автоматически, меняется только их длина и настройки. Дополнительные реквизиты разработчик добавляет сам: это поля вроде «ИНН», «Адрес», «Единица измерения». Табличные части хранят списки данных внутри элемента, например несколько контактных телефонов контрагента.
Отдельные характеристики описывают поведение: вид иерархии (список, иерархия групп, иерархия элементов), длину кода и наименования, автонумерацию, контроль уникальности, подчинённость другим справочникам. Всё это — часть структуры, и в описании её нужно фиксировать наравне с полями.
Стандартные реквизиты: код и наименование
Код — служебный идентификатор элемента. Для него задают тип (число или строка), длину, автонумерацию и контроль уникальности. Числовой код с автонумерацией удобен для простых справочников без обмена данными. Строковый код нужен, когда коды задаёт пользователь вручную (например, артикулы) или когда справочник участвует в обмене между базами — тогда числовые коды могут конфликтовать.
Наименование — основное представление элемента для пользователя. Типичная ошибка — оставить длину наименования по умолчанию (25 символов), а потом обнаружить, что полные названия контрагентов не помещаются. Оцените реальную длину данных с запасом: для контрагентов и номенклатуры обычно требуется 100–150 символов. Увеличить длину потом можно без потери данных, но это лишняя реструктуризация базы.
Если справочник подчинён другому (например, «Договоры» подчинены «Контрагентам»), в структуре появляется стандартный реквизит «Владелец». Для иерархических справочников добавляется «Родитель», а если включено использование предопределённых элементов — поле признака предопределённости.
Как описать дополнительные реквизиты
Для каждого пользовательского реквизита в описании фиксируйте пять параметров: имя (идентификатор в конфигураторе), синоним (как поле видит пользователь), тип данных, обязательность заполнения и назначение. Тип указывайте максимально точно: не просто «строка», а «строка(50)», не «число», а «число(15,2)» с точностью.
Если реквизит ссылается на другой объект, укажите полный тип ссылки: «СправочникСсылка.Контрагенты», «ПеречислениеСсылка.СтавкиНДС». Составные типы (когда поле может хранить ссылки на разные объекты) используйте осознанно: они усложняют запросы и отчёты. Для строк неограниченной длины помечайте это явно — такие поля нельзя индексировать и использовать в отборах без ограничений.
Пример фрагмента описания в табличном виде:
| Реквизит | Тип | Обязательный | Назначение |
|---|---|---|---|
| ИНН | Строка(12) | Нет | Идентификатор налогоплательщика контрагента |
| КПП | Строка(9) | Нет | Код причины постановки на учёт |
| ЮрАдрес | Строка(250) | Нет | Юридический адрес |
| ОсновнойДоговор | СправочникСсылка.Договоры | Нет | Договор по умолчанию в документах |
Удобно описывать структуру в виде таблицы «Имя — Тип — Обязательность — Назначение». Такой формат одинаково хорошо читают и разработчик, и аналитик, и заказчик, а разногласия выявляются до начала разработки.
Табличные части и их описание
Табличная часть нужна, когда к одному элементу справочника относится список однотипных строк: контактные лица контрагента, единицы измерения товара, банковские счета организации. Для каждой табличной части в описании указывают её имя, назначение и состав колонок — по тем же правилам, что и для реквизитов: имя, тип, обязательность.
Важное ограничение: табличная часть хранится внутри элемента и «умирает» вместе с ним. Если строкам нужна самостоятельная жизнь — на них должны ссылаться документы, по ним нужны отчёты или они существуют отдельно от владельца, — вместо табличной части правильнее завести подчинённый справочник. Это одно из ключевых проектных решений, которое стоит явно зафиксировать в описании структуры.
Табличная часть или подчинённый справочник
Иерархия, владельцы и связи
Иерархия определяет, могут ли элементы вкладываться друг в друга. Вид «Список» подходит для простых справочников (валюты, единицы измерения). «Иерархия групп и элементов» — когда папки служат только для группировки (номенклатура). «Иерархия элементов» — когда любой элемент может быть родителем (подразделения, статьи затрат). В описании укажите вид иерархии и пример структуры папок на 2–3 уровня.
Подчинённость фиксируется указанием владельца: «Справочник ДоговорыКонтрагентов, владелец — Контрагенты». Проверьте, действительно ли элемент без владельца бессмыслен: договор без контрагента — да, а вот склад вполне самостоятелен. Избыточная подчинённость мешает: например, делая банковские счета подчинёнными контрагентам, вы лишаетесь возможности ссылаться на них из других контекстов без указания владельца.
Также опишите, где справочник используется: в каких документах и регистрах на него ссылаются. Это поможет оценить последствия будущих изменений структуры.
- 1Определите назначение справочника и приведите 3–5 примеров реальных элементов
- 2Задайте параметры кода: тип, длину, автонумерацию, контроль уникальности
- 3Задайте длину наименования с запасом под реальные данные
- 4Выпишите дополнительные реквизиты: имя, тип, обязательность, назначение
- 5Опишите табличные части и состав их колонок
- 6Выберите вид иерархии и зафиксируйте подчинённость владельцам
- 7Перечислите объекты, которые ссылаются на справочник
- 8Проверьте описание на тестовых примерах: хватает ли полей для всех случаев
Описание через конфигуратор и программно
В конфигураторе структура справочника видна в дереве конфигурации: ветки «Реквизиты», «Табличные части», палитра свойств с длиной кода, иерархией и подчинённостью. Чтобы быстро получить описание существующего справочника, откройте его свойства и вкладки «Данные», «Иерархия», «Владельцы» — там собраны все ключевые параметры.
Программно структуру читают через метаданные. Это удобно для автоматического формирования документации или проверки конфигурации:
Мета = Метаданные.Справочники.Номенклатура;
Для Каждого Реквизит Из Мета.Реквизиты Цикл
Сообщить(Реквизит.Имя + " : " + Строка(Реквизит.Тип));
КонецЦикла;
Для Каждого ТЧ Из Мета.ТабличныеЧасти Цикл
Сообщить("Табличная часть: " + ТЧ.Имя);
КонецЦикла;
Такой обход метаданных позволяет выгрузить описание всех справочников конфигурации в файл и сравнивать структуру между версиями — например, при обновлении или аудите доработок.
Типичные ошибки при описании структуры
Большинство проблем со справочниками происходит не от сложности платформы, а от недооценки проектирования. Ниже — ошибки, которые встречаются чаще всего.
Отдельно отметим хранение избыточных данных. Если значение можно получить из связанного объекта (например, наименование контрагента по ссылке), не дублируйте его реквизитом — иначе получите рассинхронизацию при переименовании. Дублирование оправдано только для исторических снимков данных, и тогда это нужно прямо указать в описании.
Как проверить качество описания структуры
Все данные из реальных примеров элементов умещаются в описанные реквизиты
Часть информации некуда записать или её планируют хранить в комментарии
У каждого реквизита задан конкретный тип с длиной и точностью
Типы «строка» без длины или составные без обоснования
Указаны владельцы и объекты, ссылающиеся на справочник
Связи обнаруживаются только при попытке удалить элемент
Описание покрывает 3–5 реальных примеров, включая нестандартные
Описание работает только для идеального случая
FAQ
Чем описание структуры отличается от заполнения справочника данными?
Структура — это схема: какие поля, табличные части и связи существуют у справочника. Заполнение — это конкретные элементы, созданные по этой схеме. Сначала проектируют и описывают структуру, затем на её основе вводят данные. Менять схему после массового ввода данных сложнее и рискованнее.
Можно ли изменить структуру справочника после ввода данных?
Да, но с оговорками. Добавление нового реквизита безопасно. Увеличение длины строки обычно проходит без потерь. Смена типа реквизита или удаление поля могут привести к потере данных, а реструктуризация больших таблиц — к длительной блокировке базы. Любые изменения делайте на копии и с резервной копией рабочей базы.
Какой тип кода выбрать для справочника, участвующего в обмене?
Строковый код с отключённой автонумерацией либо с префиксами баз. Числовая автонумерация в распределённых базах неизбежно даёт одинаковые коды в разных узлах. На практике для обмена чаще опираются не на код, а на уникальный идентификатор ссылки, а код оставляют «для человека».
Как быстро получить список всех реквизитов существующего справочника?
В конфигураторе — через ветку «Реквизиты» объекта в дереве конфигурации. Программно — обходом коллекции Метаданные.Справочники[Имя].Реквизиты. Для выгрузки в документ удобно написать небольшую обработку, которая формирует таблицу «Имя — Тип — Синоним» по всем справочникам сразу.
Нужно ли описывать предопределённые элементы в структуре?
Да, если они есть. Предопределённые элементы создаются в конфигураторе и используются в коде по имени, поэтому их состав — часть структуры. В описании перечислите их имена и назначение, иначе при доработке кто-то может удалить элемент, на который завязан программный код.
Чем справочник отличается от регистра сведений при хранении данных?
Справочник хранит объекты с собственной идентичностью, на которые ссылаются документы. Регистр сведений хранит значения в разрезе измерений, например цены товара на дату. Если сущности нужны ссылки из документов и иерархия — это справочник; если нужна история значений по объекту — регистр сведений.
Что важно запомнить
Описание структуры справочника включает код, наименование, дополнительные реквизиты с точными типами, табличные части, вид иерархии и связи с другими объектами. Фиксируйте структуру до заполнения данными, выбирайте между табличной частью и подчинённым справочником осознанно, а изменения в рабочей базе проверяйте на копии.