Разработка и Конфигурация · 13 мин
Куда писать код в 1С: выбираем правильное место для процедур и функций
Разбираем, куда писать код в 1С: общие модули, модули объектов и форм, внешние обработки. Правила выбора места, типичные ошибки и проверка результата.
Вопрос «куда писать в 1С» возникает у каждого, кто начинает дорабатывать конфигурацию: код можно разместить в десятке разных мест, и от выбора зависит, будет ли решение работать стабильно, легко обновляться и не конфликтовать с типовым функционалом. Неправильно выбранное место для процедуры — одна из главных причин проблем при обновлении конфигурации и ошибок «Процедура или функция не обнаружена».
Встроенный язык 1С не существует отдельно от конфигурации: любой код пишется внутри модулей, а каждый модуль привязан к конкретному объекту — справочнику, документу, форме, обработке или приложению в целом. Поэтому правильный ответ на вопрос «куда писать» всегда начинается с другого вопроса: «к какому объекту и к какому событию относится моя логика».
В этом материале разберём основные типы модулей, правила выбора между ними, работу с внешними обработками как безопасной альтернативой и способы проверить, что код оказался на своём месте.
Как устроены модули в 1С и почему место имеет значение
Модуль — это контейнер для кода на встроенном языке. Каждый модуль имеет контекст исполнения: где он выполняется (на клиенте, на сервере или в обоих местах), какие объекты ему доступны и когда он вызывается. Например, код модуля объекта документа выполняется только в контексте этого документа и имеет прямой доступ к его реквизитам через ЭтотОбъект.
Контекст определяет и ограничения: в клиентском модуле формы нельзя напрямую выполнить запрос к базе данных, а в серверном общем модуле недоступны элементы формы и диалоги с пользователем. Попытка написать код «не в том месте» обычно заканчивается ошибкой компиляции или падением в момент выполнения.
Ещё один критерий — обновляемость. Изменения в типовых модулях конфигурации усложняют обновление: платформа при обновлении предложит сравнить и объединить изменённые объекты, и каждая ваша правка потребует ручного переноса. Поэтому опытные разработчики стараются выносить доработки в расширения или внешние обработки, оставляя типовой код нетронутым.
Общие модули: куда писать переиспользуемую логику
Общие модули находятся в ветке «Общие → Общие модули» дерева конфигурации. Это правильное место для функций и процедур, которые вызываются из нескольких объектов: расчёт налогов, форматирование строк, работа с файлами, интеграционные вызовы. Если одна и та же логика нужна и в документе, и в отчёте, и в обработке — она должна жить в общем модуле.
Ключевые настройки общего модуля задаются в его свойствах. Флаг «Сервер» означает, что код выполняется на сервере и имеет доступ к базе данных. Флаг «Клиент (обычное приложение)» или «Клиент (управляемое приложение)» позволяет вызывать модуль с клиента. Флаг «Вызов сервера» разрешает обращаться к серверному модулю с клиента — без него вызов завершится ошибкой.
Функции, которые должны быть видны извне, помечаются словом Экспорт. Без него процедура доступна только внутри своего модуля. Типичная структура вызова выглядит так: МойОбщийМодуль.РассчитатьСкидку(Сумма).
Когда общий модуль — ошибка
Не стоит складывать в общие модули логику, которая относится к одному объекту. Если процедура проверяет заполнение конкретного документа «Реализация товаров», её место — в модуле объекта этого документа или в расширении его модуля. Раздувание общих модулей «под всё подряд» делает конфигурацию трудной для сопровождения: найти нужный код становится сложнее, а риск задеть чужую логику при правке — выше.
Модули объектов и менеджеров: логика справочников и документов
Модуль объекта есть у каждого прикладного объекта — справочника, документа, плана счетов, регистра. Сюда пишут обработчики событий самого объекта: ПередЗаписью, ПриЗаписи, ОбработкаПроведения, ОбработкаЗаполнения. Именно здесь размещают проверки корректности данных, автоматическое заполнение реквизитов и формирование движений по регистрам.
Пример: если при проведении документа «Поступление товаров» нужно формировать записи в регистре остатков, код пишется в обработчике ОбработкаПроведения модуля объекта этого документа. Переносить эту логику в общий модуль или форму — ошибка: проведение может выполняться без формы вообще (фоновым заданием, при обмене данными), и код просто не отработает.
Модуль менеджера объекта предназначен для логики, работающей с объектом «снаружи», без создания экземпляра: получение представления, формирование печатных форм, поиск по реквизитам. В типовых конфигурациях именно здесь размещаются процедуры ДобавитьКомандыПечати и формирования табличных документов.
Модули форм: интерфейсная логика
Модуль формы содержит код, связанный с поведением интерфейса: обработчики нажатий кнопок, реакции на изменение полей, управление видимостью элементов. Директивы компиляции разделяют код по месту исполнения: &НаКлиенте, &НаСервере, &НаСервереБезКонтекста, &НаКлиентеНаСервереБезКонтекста.
Правило простое: всё, что требует обращения к базе данных (запросы, чтение и запись объектов), выполняется в серверных процедурах; всё, что связано с диалогами, предупреждениями и элементами формы, — в клиентских. Смешивать их нельзя: в клиентской процедуре прямой запрос к базе вызовет ошибку, а в серверной недоступны ПоказатьВопрос и элементы формы.
Частая ошибка новичков — писать бизнес-логику в форму. Например, расчёт итогов документа в обработчике кнопки «Пересчитать». Такой код не сработает при программном проведении документа, обмене или фоновом задании. Правильный подход: расчёт — в модуле объекта или общем модуле, а форма только вызывает его и отображает результат.
Модуль приложения, сеанса и команды: служебные точки входа
Модуль управляемого приложения содержит обработчики событий старта и завершения работы системы: ПриНачалеРаботыСистемы, ПередЗавершениемРаботыСистемы. Сюда пишут проверки версии платформы, напоминания пользователю, открытие стартовой страницы. Объём кода здесь стоит минимизировать — модуль выполняется при каждом запуске и влияет на скорость старта.
Модуль сеанса содержит единственный важный обработчик — УстановкаПараметровСеанса. В нём инициализируются параметры сеанса: текущий пользователь, настройки отбора, ограничения доступа. Код здесь должен быть максимально быстрым и без тяжёлых запросов, иначе пострадает каждый вход в систему.
Модули команд используются для глобальных и параметризуемых команд — например, кнопки «Печать» в списке документов. Код команды обычно короткий: получить параметр и вызвать нужную процедуру из общего модуля.
Внешние обработки и расширения: доработка без изменения конфигурации
Внешняя обработка — это файл с расширением .epf, который открывается в режиме «1С:Предприятие» через «Файл → Открыть» или подключается к справочнику «Дополнительные отчеты и обработки». Это идеальное место для разовых операций: пакетного изменения реквизитов, загрузки данных из Excel, тестирования гипотез. Конфигурация при этом не меняется, обновление не затрагивается.
Расширение конфигурации — механизм, позволяющий добавлять и переопределять объекты без снятия конфигурации с поддержки. В расширении можно создать свой общий модуль, заимствовать форму и дописать обработчики, добавить подписку на событие. Для большинства доработок типовых решений именно расширение — правильное место для кода: обновление проходит автоматически, а ваша логика сохраняется отдельно.
Куда писать доработку
Подходит только как крайняя мера. Усложняет обновление: каждую правку придётся переносить вручную при сравнении конфигураций.
Оптимально для постоянных доработок типового решения. Конфигурация остаётся на поддержке, обновление проходит штатно. Ограничение: не всё можно переопределить.
Подходит для разовых операций, загрузок, исправлений данных. Не меняет конфигурацию вообще, но не может реагировать на события объектов.
Для самописных конфигураций и снятых с поддержки решений. Полная свобода, но ответственность за обновление лежит на вас.
Подписки на события и регламентные задания
Подписка на событие позволяет выполнить свой код при событии объекта (запись, проведение, удаление) без изменения модуля самого объекта. Обработчик подписки размещается в общем модуле, а в свойствах подписки указывается источник (например, все документы) и событие. Это штатный способ добавить проверки или синхронизацию, не трогая типовой код.
Регламентные задания выполняют код по расписанию: обмен с внешними системами, пересчёт итогов, очистка устаревших данных. Метод задания — экспортная процедура в общем модуле с включённым флагом «Сервер». Важно помнить: регламентное задание выполняется на сервере без пользовательского интерфейса, поэтому никаких диалогов и сообщений пользователю в нём быть не должно.
- 1Сформулируйте, когда код должен выполняться: при открытии формы, при записи объекта, по расписанию, по требованию из разных мест.
- 2Если логика привязана к интерфейсу — пишите в модуль формы с правильной директивой компиляции.
- 3Если логика относится к данным конкретного объекта — в модуль объекта или подписку на событие.
- 4Если логика нужна из нескольких мест — в общий модуль с корректными флагами (Сервер, Вызов сервера) и словом «Экспорт».
- 5Если это доработка типовой конфигурации — сначала проверьте, можно ли реализовать её расширением или внешней обработкой.
- 6Проверьте результат: синтаксический контроль модуля, затем выполнение сценария в тестовой базе.
Проверка результата и типичные ошибки размещения
После написания кода выполните синтаксический контроль: в конфигураторе «Конфигурация → Проверка конфигурации» или кнопка проверки в редакторе модуля. Ошибки «Процедура или функция с указанным именем не определена» почти всегда означают одно из трёх: забыли Экспорт, не включили нужный флаг компиляции модуля или обращаетесь к серверному методу с клиента без «Вызов сервера».
Функциональную проверку делайте в копии базы: откройте объект, выполните сценарий, убедитесь, что код отработал и данные изменились как ожидалось. Для серверных процедур полезно временно добавить запись в журнал регистрации через ЗаписьЖурналаРегистрации — это позволит убедиться, что код вообще вызывается.
Как проверить результат
Ошибок нет, модуль компилируется во всех контекстах (тонкий клиент, сервер).
Ошибки «переменная не определена» или «метод не обнаружен» — проверьте директивы и флаги.
Процедура общего модуля вызывается и возвращает результат.
«Процедура не определена» — нет слова «Экспорт» или не включён «Вызов сервера».
Логика срабатывает и при проведении из формы, и при фоновом/пакетном проведении.
Код работает только из формы — значит, логика ошибочно размещена в модуле формы.
Доработки в расширении, обновление проходит без ручного сравнения.
При обновлении конфликтуют изменённые типовые модули — правки внесены напрямую.
Часто задаваемые вопросы
Можно ли писать запросы к базе данных в модуле формы?
Да, но только в процедурах с директивой &НаСервере или &НаСервереБезКонтекста. В клиентских процедурах прямое обращение к базе недоступно — нужно вызывать серверную процедуру, которая выполнит запрос и вернёт результат.
Чем расширение лучше прямого изменения конфигурации?
Расширение хранит доработки отдельно от типового кода, поэтому конфигурация остаётся на поддержке и обновляется автоматически. При прямом изменении каждое обновление требует ручного сравнения и переноса правок, что занимает время и повышает риск потери доработок.
Почему моя процедура из общего модуля «не видна» при вызове?
Три основные причины: у процедуры нет ключевого слова Экспорт; у серверного модуля не установлен флаг «Вызов сервера», а вызов идёт с клиента; либо не включён нужный флажок компиляции (сервер, тонкий клиент) в свойствах модуля.
Куда писать код, который должен выполняться каждую ночь?
Создайте регламентное задание и укажите в его свойствах метод — экспортную процедуру серверного общего модуля. В коде не должно быть диалогов и обращений к интерфейсу: задание работает на сервере без пользователя.
Можно ли обойтись внешними обработками и не трогать конфигурацию вообще?
Для разовых операций — загрузки данных, групповых изменений, проверок — да, внешних обработок достаточно. Но обработка не может автоматически реагировать на события (запись документа, проведение): для такой логики нужны расширение, подписка на событие или доработка конфигурации.
Где искать, куда типовая конфигурация «пишет» свою логику, чтобы доработать по аналогии?
Используйте глобальный поиск по конфигурации (Ctrl+Shift+F) по имени процедуры или фрагменту кода, а также «Поиск ссылок на объект» в контекстном меню. Изучите общие модули с суффиксами «Переопределяемый» и «Клиент» — типовые решения специально выносят туда точки для доработок.
Что важно запомнить
Место для кода в 1С определяется событием и контекстом: интерфейс — модуль формы, поведение объекта — модуль объекта, общая логика — общие модули, фоновые задачи — регламентные задания. Доработки типовых конфигураций безопаснее размещать в расширениях и внешних обработках, а любой новый код проверять на копии базы.