Словарь данных в 1С: что это и как его составить

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

На практике словарь данных чаще всего востребован в трёх ситуациях: при интеграции 1С с внешними системами (сайтом, CRM, WMS), при переносе данных между конфигурациями и при передаче проекта новой команде разработчиков. Без такого документа каждому специалисту приходится самостоятельно «выкапывать» структуру из конфигуратора, что занимает часы и приводит к ошибкам в обменах.

Важно понимать: словарь данных — это документ, который существует вне платформы 1С (таблица, wiki-страница, файл Excel или Confluence). Платформа сама хранит метаданные в конфигурации, а словарь — это их человекочитаемое и дополненное описание с пояснениями, которых в конфигураторе нет: назначением полей, правилами заполнения, ограничениями и особенностями обмена.

Что именно входит в словарь данных 1С

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

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

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

Чем словарь данных отличается от структуры базы и ER-диаграммы

Эти понятия часто путают, но они решают разные задачи. Структура базы данных (таблицы SQL) — это физический уровень: реальные таблицы и поля в СУБД с техническими именами вида _Reference123. Работать с ней напрямую опасно и для большинства задач не требуется.

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

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

Когда словарь данных действительно нужен

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

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

Как выбрать действие

Конфигурация типовая, доработок нет, обменов с внешними системами нетОтдельный словарь не обязателен — достаточно описания метаданных в конфигураторе

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

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

Разрабатываются нестандартные отчёты и обработкиОпишите регистры и источники данных, которые используют отчёты

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

Как составить словарь данных: пошаговый порядок

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

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

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

Формат хранения выбирайте по команде: Excel подходит для разового описания, wiki или Confluence — для живого документа, который правят несколько человек. Важно, чтобы у словаря был владелец и правило: изменение конфигурации не считается завершённым, пока не обновлён словарь.

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

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

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

Ещё одна ошибка — хранение словаря в виде единственного файла у одного сотрудника. При уходе этого человека документ теряется или перестаёт обновляться. Размещайте словарь в общем доступе с историей изменений.

Ограничения и риски при работе со структурой данных

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

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

Как проверить, что словарь данных составлен качественно

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

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

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

Полнота по ключевым объектам

Норма

Все объекты, участвующие в обменах и отчётах, описаны с реквизитами и типами

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

Часть объектов отсутствует или описана только по имени

Понятность описаний

Норма

По пояснению к реквизиту понятно его назначение без обращения к конфигуратору

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

Описания дублируют имя реквизита или отсутствуют

Связи между объектами

Норма

Указано, какие документы двигают какие регистры и на что ссылаются реквизиты

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

Связи не описаны, путь данных отследить нельзя

Актуальность

Норма

Словарь соответствует текущей версии конфигурации, есть дата обновления и ответственный

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

Структура в словаре расходится с конфигуратором

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

Частые вопросы о словаре данных 1С

Есть ли в 1С встроенный словарь данных?

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

Чем словарь данных отличается от глоссария терминов?

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

Можно ли автоматически сгенерировать словарь данных?

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

Кто должен вести словарь данных: разработчик или аналитик?

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

Нужно ли описывать в словаре типовые неизменённые объекты?

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

Как часто нужно обновлять словарь данных?

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