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

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей IT и автоматизация бизнеса
← На главную

При сопровождении нетиповых или доработанных конфигураций (например, 1С:Управление торговлей 11 или 1С:Бухгалтерия предприятия 3.0) часто возникает задача упростить последующие обновления. Вынос доработок пользовательского интерфейса и логики форм в расширение конфигурации — один из самых популярных подходов. Однако этот механизм имеет ряд неочевидных особенностей и подводных камней, о которых важно знать заранее.

Разберем подробно, как платформа 1С обрабатывает заимствованные формы, почему модуль формы в расширении создается пустым и как правильно разрабатывать расширения, чтобы не ломать логику при выходе новых релизов типовых решений.

Как платформа работает с формами в расширениях

Когда мы заимствуем форму в расширение, многие разработчики сталкиваются с двумя неожиданными моментами:

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

Для взаимодействия с методами основной формы платформа предоставляет следующие директивы вызова процедур и функций:

  1. &Перед — выполняет дополнительный код перед запуском типового обработчика.
  2. &После — выполняет доработанный код сразу после завершения типового обработчика.
  3. &Вместо — полностью перехватывает управление и отключает исполнение базового метода (если не вызван метод ПродолжитьВызов()).
  4. &ИзменениеИКонтроль — позволяет встраивать точечные изменения непосредственно в тело типового метода с жестким контролем неизменности оригинального кода поставщика.

Основные риски при обновлении типовой конфигурации

Проанализируем типичные проблемы, которые могут возникнуть после наката очередного релиза конфигурации поставщика:

  1. Переименование или удаление элементов формы: если поставщик в новой версии изменил имя реквизита, элемента формы или переименовал группу, жесткая привязка расширения к старым именам вызовет ошибку при открытии формы или выполнении кода.
  2. Изменение сигнатур процедур и функций: добавление, удаление или смена порядка параметров в типовых обработчиках событий (например, в процедуре ПриСозданииНаСервере) приведет к аварийному завершению расширения с директивами &Перед, &После или &Вместо.
  3. Конфликты в запросах динамических списков: если форма модифицирует произвольный запрос динамического списка, а в типовом обновлении удаляются поля или таблицы, форма перестанет открываться.

Рекомендации по надежной разработке форм в расширениях

Рассмотрим проверенные практики, позволяющие минимизировать трудозатраты при регулярных обновлениях базы:

  1. Программное создание элементов и реквизитов: вместо визуального редактирования элементов в редакторе формы расширения безопаснее добавлять элементы программно в обработчике события ПриСозданииНаСервере, а реквизиты создавать с помощью метода ИзменитьРеквизиты().
  2. Предпочтение директиве &ИзменениеИКонтроль: использование контроля версий исходного кода позволяет конфигуратору сразу подсветить методы, которые были изменены поставщиком в новом релизе, предотвращая скрытые ошибки в бизнес-логике.
  3. Использование стандартных переопределяемых модулей БСП: если типовая конфигурация построена на Библиотеке Стандартных Подсистем, вместо прямого заимствования форм часто достаточно переопределить логику в соответствующих общих модулях (например, для добавления команд печати или заполнения объектов).
  4. Обязательная проверка применимости: после каждого обновления основной конфигурации перед запуском базы пользователями необходимо выполнять команду конфигуратора Конфигурация > Расширения конфигурации > Проверить возможность применения.
← На главную