Где определяется структура бизнес-приложения в 1С:Предприятие

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

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

Ниже разобрано, как открыть это дерево, из каких веток оно состоит, какие объекты за что отвечают, как изменения попадают в рабочую базу и какие ошибки чаще всего допускают начинающие разработчики.

Конфигуратор — единственное место описания структуры

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

Чтобы увидеть структуру, запустите базу в конфигураторе и выполните команду меню Конфигурация → Открыть конфигурацию. Если конфигурация ещё не открыта, платформа сначала покажет пустое окно, а после открытия выведет окно дерева объектов. Вызвать само окно дерева можно командой Конфигурация → Окно конфигурации.

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

1. 1
   Запустите базу в режиме «Конфигуратор» через ярлык или стартер 1cestart
2. 2
   Откройте меню «Конфигурация» и выберите «Открыть конфигурацию»
3. 3
   Дождитесь загрузки — появится окно дерева объектов
4. 4
   Если окно закрыто, вызовите его через «Конфигурация» → «Окно конфигурации»
5. 5
   Сверяйте ветки дерева с задачей: справочники, документы, регистры, подсистемы

Из каких веток состоит дерево объектов конфигурации

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

• Общие — подсистемы, общие модули, роли, параметры сеанса, общие формы и макеты;
• Константы — хранение единичных настроечных значений (валюта учёта, наименование организации);
• Справочники — условно постоянные списки: номенклатура, контрагенты, сотрудники, склады;
• Документы — факты хозяйственной деятельности: заказы, накладные, счета;
• Журналы документов — объединённые списки документов разных видов;
• Регистры — накопление и учёт: регистры накопления, сведений, бухгалтерии, расчёта;
• Отчёты и обработки — аналитика и сервисные операции;
• Планы — планы видов характеристик, счетов, видов расчёта, обмена.

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

Какие объекты за что отвечают в структуре приложения

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

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

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

Как изменения структуры попадают в рабочую базу

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

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

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

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

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

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

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

Типовая конфигурация, расширения и поддержка

Если вы работаете с типовым решением (например, «Управление торговлей» или «Бухгалтерия предприятия»), его структура тоже описана в дереве конфигурации, но она находится на поддержке поставщика. Прямое изменение объектов снимает их с поддержки и усложняет последующие обновления.

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

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

Как менять структуру

Прямая доработка конфигурации

Полная свобода изменений, но объект снимается с поддержки, обновления типового решения усложняются

Расширение конфигурации

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

Внешние отчёты и обработки

Подходят для печатных форм и аналитики без изменения структуры; не меняют метаданные вообще

Частые ошибки при проектировании структуры

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

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

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

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

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

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

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

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

Обновление конфигурации БД

Норма

Завершилось без ошибок, список реструктуризации соответствовал ожиданиям

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

Предупреждения об удалении данных, которых вы не планировали

Интерфейс в режиме «Предприятие»

Норма

Новые объекты видны в нужных подсистемах под целевой ролью

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

Объектов нет в меню или видны лишние разделы

Проведение документа

Норма

Движения по регистрам формируются, отчёты показывают данные

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

Ошибки проведения, пустые движения

Проверка конфигурации

Норма

Нет критических ошибок в журнале проверки

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

Ошибки в модулях, несуществующие ссылки на объекты

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

Можно ли изменить структуру приложения в режиме «Предприятие»?

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

Где хранится сама конфигурация?

Конфигурация хранится внутри информационной базы: в файловом варианте — в файле 1Cv8.1CD, в клиент-серверном — в базе данных на сервере СУБД. Отдельно конфигурацию можно выгрузить в файл с расширением cf через команду «Конфигурация → Сохранить конфигурацию в файл».

Чем конфигурация отличается от конфигурации базы данных?

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

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

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

Можно ли узнать структуру чужой конфигурации без исходников?

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

Что выбрать для доработки типовой конфигурации: изменение или расширение?

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