Начиная с платформы 8.3.6 у разработчика 1С появилось два альтернативных варианта ведения разработки – доработка основной конфигурации “по старинке” или с использованием механизма расширений.
Предлагаем разобраться в особенностях использования расширения конфигурации в качестве механизма адаптации прикладного решения под требования конкретного пользователя.
Зачем нужны расширения?
Основная цель создания механизма расширений — упрощение адаптации конфигураций к пожеланиям пользователей во время внедрений. Например, пользователю необходимо добавить команду на форму. До появления расширений пришлось бы снимать конфигурацию с полной поддержки и менять типовую конфигурацию. Это приводило к увеличению времени на обновление конфигурации, а если изменения вносились в стандартные объекты типовой конфигурации, то к появлению ошибок и блокировок. При обновлении конфигурации внесенные изменения могли и вовсе пропасть, то есть замениться на типовые, от поставщика.
Использование расширения призвано исключить эти неудобства. Дорабатываемую через расширения конфигурацию не надо снимать с поддержки. В результате сохраняется простота обновления типового прикладного решения, стоящего на поддержке.
Сравнение разработки через изменение конфигурации и с использованием расширения
Попробуем выяснить так ли это. Для этого сравним адаптацию системы через изменение конфигурации и с использованием расширения.
| Критерии сравнения | Конфигурация | Расширение | Комментарий | Источник |
|---|---|---|---|---|
| Создание регламентных заданий |  |  | В расширении нельзя создавать регламентные задания | |
| Ограничение на работу конструктора запросов | | | Конструктор запросов видит только данные, добавленные в расширение. Чтобы конструктор видел метаданные основной конфигурации, необходимо выйти из контекста расширения, например, построить запрос в обработке. Затем его перенести в расширение, что довольно утомительно — инструмента, позволяющего это сделать в один клик, нет. | |
| Подключение внешних печатных форм для собственных документов | | | В расширении для собственных документов не подключаются назначаемые печатные формы. Реализовать это можно только командами из формы. Причина: в подсистеме используется ТЧ «Назначения», где для дополнительного отчета хранятся ссылки на идентификаторы объектов метаданных. При этом справочника в БСП два: для объектов метаданных и для объектов расширений. Но хранить ссылку там можно только для объектов метаданных. | |
| Добавление предопределенных элементы в собственные справочники и заимствованные объекты | | | Реализовано с версии 8.3.20 | https://wonderland.v8.1c.ru/blog/razvitie-rasshireniy/ |
| Изменение длинны и точности предопределяемых типов | | | В расширении нельзя изменить точность учета чего-либо. Например, веса с сотых до тысячных если это необходимо. (Реализовано с версии 8.3.20) | https://wonderland.v8.1c.ru/blog/razvitie-rasshireniy/ |
| Создание предопределенных элементов для планов видов характеристик | | | Нельзя создать предопределенный элемент. Например, для статьи расходов. (Реализовано с версии 8.3.20) | https://wonderland.v8.1c.ru/blog/razvitie-rasshireniy/ |
| Доступность всех объектов конфигурации по ссылке на наборы типов | | | В расширении при ссылке на определенный тип объекта возвращаются только те типы, которые определены в конфигурации, и не учитываются те, что добавлены в расширение (Реализовано с версии 8.3.20) | https://wonderland.v8.1c.ru/blog/razvitie-rasshireniy/ |
| Возможность изменения параметров номеров и кодов объектов | | | Изменение длины, типа и других настроек кода/номера объектов с помощью расширений конфигурации было невозможно. Например, невозможно увеличить длину номера документа. Если менять это в самой конфигурации, то надо включить в ней возможность изменений, что усложнит обновление конфигурации на новую версию. (Планируется с версии 8.3.22) | https://wonderland.v8.1c.ru/blog/razvitie-rasshireniy-8322/?sphrase_id=271065 |
| Настройки нумерации | | | В расширении нельзя изменить свойства нумерации для объектов типа «Документ», «Бизнес-процесс», «Задача» и «Нумератор». (Планируется с версии 8.3.22) Можно будет увеличивать значение свойства «Длина номера», задавать значение свойства «Тип номера», задавать значение свойства «Допустимая длина номера», «Периодичность» и «Контроль уникальности» | https://wonderland.v8.1c.ru/blog/razvitie-rasshireniy-8322/?sphrase_id=271065 |
| Создание собственных нумераторов | | | В расширении нельзя создавать свои нумераторы. (Планируется с версии 8.3.22) | https://wonderland.v8.1c.ru/blog/razvitie-rasshireniy-8322/?sphrase_id=271065 |
| Изменение значения свойства «Длина кода» для объектов типа «Планы обмена», «Справочники», «Планы видов характеристик», «Планы счетов», «Планы видов расчета» | | | (Планируется с версии 8.3.22) | https://wonderland.v8.1c.ru/blog/razvitie-rasshireniy-8322/?sphrase_id=271065 |
| Изменение значения свойства «Тип кода» для объектов типа «Справочники» и «Планы видов расчета» | | | (Планируется с версии 8.3.22) | https://wonderland.v8.1c.ru/blog/razvitie-rasshireniy-8322/?sphrase_id=271065 |
| Изменение значения свойства «Длина наименования» для объектов типа «Планы обмена», «Справочники», «Планы видов характеристик», «Планы счетов», «Планы видов расчета», «Задачи» | | | (Планируется с версии 8.3.22) | https://wonderland.v8.1c.ru/blog/razvitie-rasshireniy-8322/?sphrase_id=271065 |
Спорный момент применения расширений — повышение вероятности отключения всех доработок при возникновении ошибок при обновлении. Например, вы дорабатывали реквизит формы документа, который разработчики 1С решили исключить из типовой конфигурации. Тогда при обновлении, возникнет ошибка применения расширения и весь доработанный функционал перестанет действовать. Хуже всего в этой истории то, что иногда об этом нет никаких сообщений, то есть ни пользователь, ни разработчик не в курсе произошедшего. Это может быть весьма чревато, особенно при работе с регламентированным или управленческим учётом.
При разработке непосредственно в конфигураторе в таком случае перестанет работать только объект с ошибкой, но не все доработки.
Заключение
В заключении можно сказать: расширение до конца не решает проблему обновления с доработками. Почему обновление доработанной конфигурации вообще занимает больше времени? Потому что нужно проверить, не возникло ли конфликта между доработкой и новой конфигурацией, и, если конфликт все-таки возник, то понять, как его решить. А такой конфликт может возникнуть независимо от того, где сделана доработка.
Вывод:
- Расширение НЕ решает проблему обновления, оно просто смотрит на нее с другой точки зрения.
- При изменении типовых механизмов в ЛЮБОМ случае нужен квалифицированный специалист для обновления. Если изменения и обновления конфликтуют, нужно разбираться и решать этот конфликт. Иногда с написанием нового кода.
В целом можно выделить несколько причин, при которых точно НЕ стоит использовать расширения:
- Объем доработок. Создание большого количества новых объектов в расширении плохо влияет на производительность.
- Старая конфигурация. Невозможно или трудоемко использовать механизм расширений.
- Сложность доработки. Расширение не позволяет сделать необходимые действия с минимальными затратами. Например, создать регламентное задание, сложный отчет или другие задачи, которые нельзя выполнить с использованием расширения.
- Создание нового функционала, не связанного с основной конфигурацией. Например, будет разработан отдельный модуль или подсистема, которая мало связана с имеющейся функциональностью. В этом случае все части новой подсистемы надо создавать в основной конфигурации. А связь новой подсистемы и типового функционала осуществлять через расширение, если это невозможно сделать другими способами, без изменения типовой конфигурации.
Механизм расширений не отменяет изменения конфигурации, а в некоторых случаях дополняет его. Расширение незаменимо в качестве «багфикса» — быстрого исправления ошибки в рабочей базе. Так же их целесообразно использовать, если у вас небольшой объем доработок типового функционала программы.
