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

Если типовая конфигурация 1С у вас на поддержке и вы хотите получать обновления, почти всегда разумнее делать доработки в расширении, а не менять конфигурацию напрямую. Прямое изменение оправдано редко: когда расширение технически не способно решить задачу или когда вы сознательно уходите с обновлений вендора. Ниже я показываю, как принять это решение без догадок.

Чем расширение отличается от правки типовой конфигурации

Конфигурация 1С состоит из объектов метаданных (справочники, документы, регистры), форм и модулей с кодом. Когда вы меняете её напрямую, вы правите эти объекты внутри самой конфигурации. Она перестаёт быть «типовой» в строгом смысле: возникает расхождение с поставкой, которое придётся учитывать при каждом обновлении.

Расширение, напротив, лежит рядом с основной конфигурацией как отдельный слой. Оно описывает, что добавить (новые реквизиты, обработки, отчёты) и что перехватить (до, после или вместо существующей процедуры). Основная конфигурация остаётся нетронутой, и обновление выполняется стандартным способом.

Звучит как простой выбор в пользу расширений, но у каждого подхода есть цена, и её полезно понимать заранее.

Когда лучше выбрать расширение

Расширения хорошо подходят, если вы хотите оставаться на типовой версии и регулярно её обновлять. Типичные задачи:

• добавить реквизит в документ или справочник и вывести его на форму;
• создать собственный отчёт или обработку;
• изменить поведение при проведении документа, добавив проверку или дополнительное действие;
• реализовать обмен с внешним сайтом или сервисом через HTTP-сервис;
• поменять печатную форму.

Главный выигрыш виден в момент обновления. Когда вышел новый релиз, вы обновляете основную конфигурацию, затем проверяете, что расширение по-прежнему подключается и работает. Конфликтов объединения, которые нужно разбирать вручную по сотням объектов, при этом нет. Подробнее про сам процесс обновления я писал в статье про обновление типовой конфигурации 1С без потери доработок.

Ещё один плюс: расширение можно отключить. Если после обновления что-то пошло не так, вы проверяете базу без него и быстро понимаете, где причина, в типовом коде или в доработке.

Когда расширения не справляются

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

• нужно изменить структуру данных так, что затрагиваются существующие объекты глубже, чем допускает механизм расширений;
• требуется переписать большую часть типового алгоритма, а перехват процедур превращается в нагромождение обходных решений;
• нужно удалить или принципиально переделать типовой объект;
• в конкретной версии платформы или конфигурации нужный механизм расширений недоступен.

Об ограничениях стоит читать документацию вашей версии платформы и конфигурации, они меняются от релиза к релизу. Я не буду приводить здесь точный список, потому что он устаревает, и перед проектом его нужно проверять на вашей версии.

Отдельный случай: вы осознанно ведёте свою ветку конфигурации и не собираетесь следовать за обновлениями вендора. Так бывает с очень специфичными отраслевыми решениями. Это законный выбор, но тогда обновления превращаются в ваш собственный проект, а не в рутину.

Что происходит при обновлении в каждом из вариантов

Здесь разница наиболее ощутима, поэтому разберём по шагам.

При прямом изменении конфигурации в момент обновления платформа сравнивает три версии: старую типовую, новую типовую и вашу текущую. Все объекты, затронутые и вами, и вендором, дают конфликты. Их решает специалист: вручную выбирает, чью версию оставить или как объединить. Чем больше правок и чем глубже они, тем больше времени уходит. Ошибка при объединении иногда проявляется не сразу, а через неделю в каком-нибудь редком документе.

При работе через расширение схема проще:

1. Обновляете основную конфигурацию.
2. Загружаете или подключаете актуальную версию расширения.
3. Проверяете, нет ли ошибок: некоторые перехваченные процедуры могли измениться в новом релизе.
4. Прогоняете контрольные сценарии на копии базы.

Проблемы возможны и тут. Если вендор переименовал или удалил процедуру, которую вы перехватывали, расширение сообщит об ошибке. Но найти и исправить такое место обычно проще, чем разбирать конфликт объединения на уровне всей конфигурации.

Как принять решение за 15 минут

Я обычно задаю заказчику несколько вопросов, и ответы быстро показывают направление.

1. Конфигурация на поддержке вендора, и вы планируете обновляться? Если да, по умолчанию выбираем расширение.
2. Насколько глубоко задача влезает в типовую логику? Добавить поле и проверку это одно, а переписать механизм расчёта себестоимости другое.
3. Кто будет сопровождать решение через год? Если разработчик сменится, расширение с чётким списком изменений передать проще, чем конфигурацию с россыпью правок.
4. Есть ли тестовая копия базы и процесс проверки после обновления?
5. Используется ли конфигурация в нескольких базах или филиалах? Расширение можно развернуть единообразно.

Если пункты 1, 3 и 5 дают «да», а пункт 2 говорит «задача небольшая или средняя», выбор очевиден. Если же задача требует переработки ядра, лучше честно оценить обе траектории и их стоимость владения на несколько лет, а не только цену первой разработки. О том, из чего складываются затраты, есть отдельный материал: из чего складывается стоимость доработки 1С.

Практические правила работы с расширениями

Если вы выбрали расширения, несколько привычек сильно экономят нервы.

Ведите описание: что именно перехвачено и зачем. Простой текстовый файл со списком «объект, процедура, причина» спасает при каждом обновлении.

Старайтесь перехватывать минимум. Чем меньше процедур затронуто, тем меньше шансов на поломку при смене релиза. Если можно добавить подписку на событие вместо перехвата большой процедуры, лучше добавить подписку.

Не копируйте целые куски типового кода в расширение. Копия живёт своей жизнью и перестаёт получать исправления вендора, а проблемы проявятся только со временем.

Называйте свои объекты с понятным префиксом, чтобы сразу видеть, что принадлежит расширению, а что типовое.

Держите отдельное расширение под отдельную функциональность, например обмен с сайтом и печатные формы отдельно. Так проще отключать и проверять по частям.

Пример простого перехвата в расширении выглядит так:

&После("ПриЗаписи")
Процедура Расш_ПриЗаписи(Отказ)
    // дополнительная проверка после типовой логики
    Если Не Отказ И ПустаяСтрока(ЭтотОбъект.Комментарий) Тогда
        // действие или предупреждение
    КонецЕсли;
КонецПроцедуры

Точные аннотации и допустимые места перехвата зависят от типа объекта и версии платформы, поэтому сверяйтесь с документацией и пробуйте на тестовой базе.

Как перейти с изменённой конфигурации на расширения

Частая ситуация: конфигурация когда-то была изменена напрямую, обновлений давно не было, и теперь бизнес хочет вернуться на поддерживаемую версию. Рабочий путь в таком случае я вижу так.

Сначала нужно получить точный список отличий от типовой поставки: платформа умеет сравнивать вашу конфигурацию с конфигурацией поставщика. Этот список обычно длиннее, чем помнят пользователи, и часть правок давно никому не нужна.

Затем каждое отличие классифицируется. Что-то можно просто отбросить, потому что типовая версия уже умеет то же самое. Что-то легко переносится в расширение. Что-то требует отдельного решения, например внешней обработки или изменения процесса. Классификацию лучше делать вместе с теми, кто пользуется системой, а не только с разработчиком, иначе можно выбросить то, на чём держится чья-то ежедневная работа.

После этого готовится чистая типовая версия нужного релиза, к ней подключаются расширения, и всё проверяется на копии боевой базы. Данные при этом не страдают, потому что расширения не меняют их структуру в обход платформы, а новые реквизиты, если они нужны, создаются самим расширением. Переключение на боевую базу стоит планировать на спокойный период и оставить возможность вернуться к старой копии.

Такой переход редко бывает быстрым, и обещать конкретные сроки до анализа отличий нельзя. Но после него обновления перестают быть ежегодным испытанием, и это обычно окупает усилия.

Частые вопросы

Можно ли перенести уже сделанные правки конфигурации в расширение?

Чаще всего можно, но это отдельная работа: нужно выписать все отличия от типовой версии, решить, что ещё нужно бизнесу, и переписать в виде расширения. Иногда при этом выясняется, что часть правок давно не используется. Такой перенос полезно воспринимать как ревизию.

Расширения замедляют работу базы?

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

Нужно ли расширение, если база нетиповая, самописная?

Тогда разделение на типовое и своё теряет смысл: вендора, который выпускает обновления, нет. Выбор строится вокруг удобства сопровождения, а не совместимости с релизами.

Что делать, если после обновления расширение перестало подключаться?

Не паниковать. Отключите расширение на копии базы, убедитесь, что основная конфигурация в порядке, затем по сообщениям платформы найдите изменённые объекты и поправьте только их. Поэтому обновления всегда стоит сначала проверять на копии.

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