Разработка и Конфигурация · 10 мин
Где определяется структура и прикладная логика бизнес-приложения в 1С
Где задаётся структура прикладной логики бизнес-приложения в 1С: метаданные, модули, конфигуратор, общие модули и подсистемы. Практическое руководство.
Прикладная логика бизнес-приложения в 1С не пишется «в свободной форме», как в классических языках программирования. Она определяется внутри конфигурации — структурированного набора объектов метаданных и модулей кода, которые вместе описывают, какие данные хранит система, как они связаны и какие алгоритмы над ними выполняются.
Главное место, где определяется структура приложения, — это дерево конфигурации в Конфигураторе. Именно там разработчик создаёт справочники, документы, регистры, отчёты и другие объекты, задаёт их реквизиты и связи. Поведение же — обработчики событий, расчёты, проверки — описывается в модулях, привязанных к этим объектам или вынесенных в общие модули.
Понимание того, где «живёт» каждая часть логики, критично и при разработке с нуля, и при доработке типовых решений: ошибка в выборе места для кода приводит к дублированию, трудностям обновления и скрытым дефектам.
Конфигурация как контейнер прикладной логики
Конфигурация — это полное описание прикладного решения: структура данных, интерфейс, права, алгоритмы. Она создаётся и редактируется в режиме «Конфигуратор», а исполняется в режиме «Предприятие». Любое бизнес-приложение 1С — будь то учётная система, торговля или зарплата — существует именно как конфигурация.
Центральный элемент Конфигуратора — окно дерева конфигурации. В нём объекты сгруппированы по видам: константы, справочники, документы, журналы, перечисления, регистры сведений и накопления, планы счетов, отчёты, обработки и другие. Добавляя объект в дерево, разработчик фактически объявляет новый элемент структуры приложения.
Важно понимать разделение: конфигурация разработчика (то, что вы редактируете) и конфигурация базы данных (то, что реально работает у пользователей). Изменения структуры применяются только после команды «Обновить конфигурацию базы данных», которая реструктуризует таблицы. До этого момента новая логика в рабочей базе не действует.
Объекты метаданных: где задаётся структура данных
Структурный каркас приложения — это объекты метаданных. Каждый вид объекта отвечает за свой аспект предметной области: справочники хранят нормативно-справочную информацию, документы фиксируют факты хозяйственной деятельности, регистры накапливают итоги и показатели, перечисления задают фиксированные списки значений.
Состав объекта определяется в окне редактирования или в палитре свойств: реквизиты (поля), табличные части, измерения и ресурсы регистров, длина и тип полей, индексы. Здесь же задаются связи — например, тип реквизита «СправочникСсылка.Номенклатура» связывает документ со справочником товаров.
Практический принцип: если логику можно выразить структурой (типом реквизита, видом регистра, движением документа), её лучше выразить структурой, а не кодом. Платформа автоматически обеспечит хранение, контроль типов и базовое поведение, а кода потребуется минимум.
Модули: где описывается поведение и алгоритмы
Код на встроенном языке 1С размещается в модулях, и выбор модуля определяет контекст исполнения: где код выполняется (клиент или сервер), какие данные ему доступны и когда он вызывается.
Основные места размещения кода:
- Модуль объекта — обработчики событий объекта:
ПередЗаписью,ПриЗаписи,ОбработкаПроведения,ОбработкаЗаполнения. Здесь описывается логика проведения документа, контроль данных при записи справочника. - Модуль формы — реакция на действия пользователя:
ПриОткрытии,ПриИзмененииреквизита, команды формы. Директивами&НаКлиентеи&НаСерверезадаётся место исполнения. - Общие модули — переиспользуемые процедуры и функции: расчёты, работа с запросами, интеграции. Именно сюда выносится логика, общая для нескольких объектов.
- Модуль менеджера объекта — операции над объектом вне конкретного экземпляра: печатные формы, начальное заполнение, обработчики получения данных.
- Модуль приложения и модуль сеанса — логика запуска системы, установка параметров сеанса, глобальные обработчики.
Признак правильно выбранного места: код исполняется там, где ему доступны нужные данные без лишних серверных вызовов, и не дублируется в нескольких объектах. Если одна и та же проверка встречается в трёх документах — ей место в общем модуле.
Роль подсистем, ролей и командного интерфейса
Структура приложения — это не только данные и код, но и то, как пользователь видит систему. Подсистемы группируют объекты по функциональным областям («Закупки», «Склад», «Зарплата») и формируют разделы командного интерфейса. Принадлежность объекта к подсистеме задаётся в его свойствах или в свойствах самой подсистемы.
Роли определяют права доступа к объектам и тоже являются частью структуры логики: разграничение «кто что может делать» — это бизнес-правило, реализованное декларативно. Дополнительно тонкая настройка доступа к данным выполняется через RLS (ограничение доступа на уровне записей) в шаблонах ролей.
При проектировании нового приложения порядок обычно такой: сначала моделируются объекты и связи, затем подсистемы и роли, и только после этого пишется код модулей. Обратный порядок — типичный признак проблемной архитектуры.
Механизмы расширения логики типовых конфигураций
При доработке типовых решений (1С:Бухгалтерия, Управление торговлей и подобных) структура логики определяется вендором, и прямое изменение объектов усложняет обновление. Для таких случаев платформа предлагает механизм расширений конфигурации: доработки хранятся отдельно и накладываются на типовую конфигурацию.
В расширении можно добавлять собственные объекты, дополнять модули через аннотации &ИзменениеИКонтроль, &Вместо, &Перед, &После, создавать свои формы и роли. Это позволяет сохранить возможность обновления типового решения.
Где размещать доработку
Подходит при полном отказе от автообновлений или когда расширение технически невозможно. Минус — трудоёмкое обновление и риск потери изменений.
Оптимально для большинства доработок: обновления сохраняются, изменения изолированы. Ограничение — не все объекты и сценарии поддерживаются.
Для разовых операций, печатных форм и сервисных функций без изменения структуры. Не подходят для изменения логики проведения документов.
Как проверить, что структура логики спроектирована верно
После определения структуры и размещения кода полезно пройти контрольные точки. Они помогают выявить архитектурные ошибки до того, как система попадёт к пользователям.
Как проверить результат
Движения формируются в обработчике ОбработкаПроведения модуля объекта, отмена проведения очищает записи автоматически
Движения пишутся из формы или внешней обработки, при отмене проведения остаются «хвосты» в регистрах
Общие алгоритмы вынесены в общие модули и вызываются из объектов
Один и тот же расчёт скопирован в модули нескольких документов
Серверная логика (запросы, проведение) в серверных модулях, клиентская — в клиентских, вызовы сгруппированы
Частые чередующиеся вызовы сервера из клиентского кода, ошибки недоступности процедур
Реструктуризация проходит без ошибок, данные сохраняются
Предупреждения о потере данных, ошибки преобразования типов
Дополнительно стоит использовать встроенную проверку конфигурации (меню «Конфигурация — Проверка конфигурации»): она выявляет синтаксические ошибки модулей, неиспользуемые обработчики и нарушения правил построения интерфейса.
Границы самостоятельной работы и риски
Изменение структуры метаданных — операция, затрагивающая данные. Удаление реквизита или изменение его типа при обновлении конфигурации базы данных может привести к безвозвратной потере информации. Перед реструктуризацией рабочей базы обязательно делайте выгрузку (dt) или резервную копию средствами СУБД.
Самостоятельно безопасно выполнять: добавление новых реквизитов и объектов, создание внешних обработок и отчётов, доработку через расширения на тестовой копии. К участию специалиста стоит привлекать изменение типов полей с данными, переработку схемы проведения документов, настройку RLS и обменов — ошибки здесь проявляются не сразу и дорого исправляются.
Что важно запомнить
Структура прикладной логики в 1С определяется в конфигурации: состав данных — объектами метаданных в дереве конфигурации, поведение — кодом в модулях объектов, форм и общих модулях. Правильный выбор места для каждой части логики упрощает поддержку и обновление, а доработки типовых решений безопаснее выполнять через расширения.
Частые вопросы
Чем конфигурация отличается от информационной базы?
Конфигурация — это описание структуры и логики приложения (объекты, модули, интерфейс). Информационная база — это конфигурация плюс фактические данные пользователей. Одна и та же конфигурация может разворачиваться на множестве баз: рабочих, тестовых, учебных.
Где писать код, который должен работать и при интерактивной записи, и при обмене данными?
В модуле объекта, а не в форме. Обработчики модуля объекта (ПередЗаписью, ПриЗаписи, ОбработкаПроведения) срабатывают при любом способе записи — из формы, программно, при обмене или в фоновом задании. Код формы выполняется только при работе пользователя с конкретной формой.
Можно ли изменить структуру типовой конфигурации без программирования?
Частично. Через механизм дополнительных реквизитов и сведений (в типовых решениях — раздел «Администрирование») можно добавлять поля к объектам без Конфигуратора. Но изменение состава регистров, логики проведения и связей объектов требует работы в Конфигураторе или расширении.
Что делать, если при обновлении конфигурации базы данных появляется предупреждение о потере данных?
Отменить обновление, выяснить, какие объекты и реквизиты затронуты (список показывается в окне реструктуризации), и оценить, есть ли в них данные. Если данные нужны — сначала перенести их в новые структуры обработкой на копии базы, и только потом выполнять обновление на рабочей.
Когда логику выносят в общий модуль, а когда оставляют в модуле объекта?
В модуле объекта остаётся то, что относится только к этому объекту: его проведение, его проверки заполнения. В общий модуль выносится логика, используемая двумя и более объектами, а также независимые алгоритмы — расчёты, работа с запросами, форматно-логический контроль, интеграционные функции.