При сопровождении типовых решений, таких как «1С:Бухгалтерия предприятия 3.0» (БП 3.0), перед разработчиком неизбежно встает дилемма: как внедрить необходимые клиенту изменения, сохранив при этом возможность легкого обновления конфигурации. Рассмотрим подробно, какой подход выбрать при разработке новых подсистем, документов, регистров и реквизитов, и проанализируем технические нюансы использования расширений в зависимости от версии платформы.
Представим ситуацию: у нас есть БП 3.0 на полной поддержке. Клиенту требуется масштабная доработка, включающая создание новой подсистемы, добавление документов, регистров накопления, отчетов и новых реквизитов к справочнику Номенклатура. Нам необходимо решить, стоит ли использовать механизм расширений или же лучше частично снять конфигурацию с поддержки.
Разберем основные аргументы, которые помогут нам принять решение:
Проанализируем наиболее устойчивую схему разработки, которую рекомендуют опытные специалисты. Она заключается в разделении ответственности между основной конфигурацией и расширением.
Шаг 1: Работа с метаданными в основной конфигурации. Чтобы минимизировать риск потери данных, добавим новые объекты (справочники, документы, регистры) и дополнительные реквизиты к типовым объектам (например, к Справочник.Номенклатура) непосредственно в основную конфигурацию. Для этого придется снять объект с поддержки с сохранением возможности изменений.
Важный совет: Всегда используйте уникальные префиксы для своих объектов и реквизитов (например, мп_ВесБрутто), чтобы избежать конфликта имен при выходе официальных обновлений от «1С».
Шаг 2: Вынос логики и интерфейса в расширение. Все изменения форм, обработчики событий и модификацию типовых модулей мы реализуем в расширении. Это позволит нам:
&Перед, &После и &Вместо для изменения поведения типовых процедур.Рассмотрим подробнее ситуацию, когда версия платформы и режим совместимости позволяют создавать данные прямо в расширении. Выясним причину, почему это может быть опасно. При подключении расширения с новыми реквизитами платформа создает в СУБД дополнительные таблицы или колонки. Если в процессе эксплуатации расширение будет отключено или удалено, платформа инициирует реструктуризацию базы данных, в ходе которой «лишние» данные будут зачищены.
Если вы все же решили хранить данные в расширении, обратите внимание на следующие правила:
Разберем по шагам, как правильно дописывать существующую бизнес-логику. Допустим, нам нужно изменить алгоритм записи документа при его проведении. Вместо полной замены метода (&Вместо), которую стоит использовать только в крайних случаях, рассмотрим применение аннотаций &Перед и &После.
Пример использования в расширении:
&После("ПередЗаписью")
Процедура мп_ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
// Наша логика, которая выполнится после типового кода
Если РежимЗаписи = РежимЗаписиДокумента.Проведение Тогда
Сообщить("Документ успешно обработан расширением!");
КонецЕсли;
КонецПроцедуры
Проанализируем ситуацию с подписками на события. В старых версиях платформы (до 8.3.15) собственные подписки в расширениях были недоступны. Разработчикам приходилось «вклиниваться» в существующие процедуры модулей объектов. В современных реалиях мы можем создавать полноценные объекты ПодпискаНаСобытие внутри расширения, указывая в качестве источника объект из основной конфигурации. Это самый «чистый» способ доработки.
Посмотрим на пример из практики: увеличение длины кода справочника. Если мы изменим длину кода в основной конфигурации, но забудем обновить этот справочник в расширении (куда он был заимствован ранее), система может выдать ошибку при запуске или реструктуризации. Расширение всегда должно «знать» о структуре заимствованного объекта. Помните: расширение может расширять (увеличивать длину строки или точность числа), но не может сужать типы данных относительно основной конфигурации.
Подводя итог, можно сказать, что на текущий момент (для версий платформы ниже 8.3.15 или при низком режиме совместимости) наиболее безопасной стратегией является:
Такой подход обеспечивает максимальную сохранность данных клиента и при этом дает все преимущества расширений для упрощения обновлений. Мы проанализировали риски и выяснили, что «кривые руки» администратора — это реальный фактор, который стоит учитывать при проектировании архитектуры решения. Со временем, когда типовые конфигурации массово перейдут на высокие режимы совместимости (8.3.17 и выше), использование расширений для хранения данных станет более оправданным, но и тогда вопрос дисциплины обслуживания БД останется на первом месте.