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