Расширения конфигурации или правки типовой?

«Снять с поддержки» в быту значит: править типовые объекты напрямую и на каждом обновлении вручную сливать конфликты. Расширение хранит ваш слой отдельно: типовая обновляется штатно, платформа подмешивает доработки. Так пишут и вендорские материалы, и нормальные практики внедрения.

Мой угол: дешёвая правка «прямо в модуле» часто самый дорогой час через год.

Когда расширение — правильный выбор

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

С платформы 8.3.23 в расширениях появились и свои регламентные задания — ещё один аргумент не лезть в типовую «потому что иначе никак».

Когда правка типовой всё же бывает нужна

• глубокое изменение, которое расширение закрывает криво или дорого;
• исторический долг: база уже снята и переплетена;
• отраслевая / самописная, где «типовой» по сути ваша.

Даже тогда: карта отличий, тест, осознание цены каждого следующего обновления.

Чего избегать в расширениях

• жёсткое копирование огромных кусков типового кода «на всякий случай»;
• конфликт нескольких расширений без владельца;
• разработка сразу на проде;
• отсутствие списка: какое расширение зачем.

Как я выбираю на проекте

1. Цель процесса и критерий «готово».
2. Можно ли типовым механизмом / вариантом отчёта / настройкой?
3. Если код — сначала расширение.
4. Оценка обновляемости отдельно от «сделать к пятнице».
5. Смок на копии под рабочими ролями.

Доработки — от 2 999 ₽/час или смета. Сопровождение обновляемого контура — от 49 999 ₽/мес: услуги.

Опишите задачу одним абзацем — скажу честно: настройка, расширение или уже проект слияния.