Приветствую всех! Коллеги, меня не перестает мучить вопрос, в каких случаях для доработки типовой конфигурации нужно использовать механизм расширений, а в каких нужно просто снять конфигурацию с поддержки и переносить обновления поставщика путем сравнения-объединения? Уточню - доработки в типовой конфигурации серьезные,+ много своих объектов (документы, справочники, регистры...). На мой взгляд "допиливание" своих доработок в расширении под новый релиз поставщика более сложная задача, чем если бы я обновился путем сравнения-объединения с новым релизом. Или я неверно рассуждаю? Прошу сообщество помочь определиться с правильным подходом к серьезной доработке типовой конфигурации.
---
но пока у меня остаются открытыми следующие вопросы:
1. Критерий для принятия решения связан с тем какие именно доработки планируются. Изменения формы и на сколько они существенны, изменения модулей в части логики работы... Иногда проще сделать свою форму и написать для нее нужный функционал. Опять же программное изменение формы - интересный прием, но когда таким образом надо перекроить всю форму есть ли смысл делать это программно?
2. Если есть доработки в расширении (особенно написанные не вами) можно продолжить дописывать их, или изменения вносить в типовую. Только опыт Вам позволит сделать выбор.

Из моего опыта... Есть ЕРП, сначала ее сняли с поддержки(не с замка) и сильно дописали, потом решили вернуться на поддержку... Внедрили расширение, вернулись на поддержку, но и с расширением сильно дописана... сейчас я уже вношу изменения в конфигурацию, так как постановка на замок не планируется, да и обновления откровенно много занимают времени. Проще нужный функционал добавить из типовой....Как то так.. Вот
---
Если вы допустили снятие с замка, автоматически вы не обновите. Придется обновлять в ручном режиме и лучше всего в режиме дважды измененные. Если так уж важны новые фишки конкретного блока, обновляете его полностью, затем вносите те самые "немного затронутые изменения".
---
Думаю, что сколько врачей - столько и диагнозов. Никогда не будет универсального решения, пока не возникнет полнофункциональный набор 1С-Лего, а не нынешние, с потерявшимися кубиками и отсыхающими ветками. Возможно, переход будет, как кентавр, состоять из рекомбинации двух подходов: использование механизма расширений + перенос собственных доработок. Иначе - потеря функционала, остановка процессов, убытки и .....
---
Думаю, что сколько врачей - столько и диагнозов. Никогда не будет универсального решения, пока не возникнет полнофункциональный набор 1С-Лего, а не нынешние, с потерявшимися кубиками и отсыхающими ветками. Возможно, переход будет, как кентавр, состоять из рекомбинации двух подходов: использование механизма расширений + перенос собственных доработок. Иначе - потеря функционала, остановка процессов, убытки и .....

Да вполне согласен.
---
Вы забыли самый простой путь для серьезных доработок...
Не снимать с поддержки а просто включить возможность изменений - при этом замочек открывается напротив объектов в конфе...
И вы обновляетесь не через объединение, а обычным способом, но с бубнами конечно...

И таких измененных конфигураций на просторе туча...
А снимать с поддержки это откровенное извращение, если нужно внести небольшие изменения.... )))))
---
Если требуются небольшие изменения, то тут более-менее понятно. Остро встает вопрос если нужно изменить примерно 1/3 или более типового функционала.
---
Если собираетесь переписывать треть типовой конфигурации, при этом не планируете использовать механизм обновлений, то непонятно вовсе, почему появился вопрос о расширениях? Зачем они Вам?
---
Решение использовать механизм расширений было принято другими людьми, которые ныне не работают и вот я сейчас пытаюсь объективно оценить ситуацию (это было правильное решение или нет) и возможно изменить подход к дальнейшим доработкам.
---
Если много (1) изобретений идет внутри функций и процедур, то такие объекты лучше снимать с поддержки и не редактировать в коде "&вместо", так как это все ведет к проблемам.

Если доработки в начале и конце функций и процедур, то обязательно нужно переносить на расширения, так как код в этом случае не имеет создает больших проблем и объект модуля или форму вообще можно вернуть на поддержку.
---
если режим совместимости позволяет, то директива &ИзменениеИКонтроль сильно облегчит ситуацию
---
Да, слышал про эту новую фишку - попробую применить когда обновим платформу.
---
Тут на инфостарт целая лекция была что механизм (&ИзменениеИКонтроль) не срабатывает со стопроцентной гарантией.
---
Тут на инфостарт целая лекция была что механизм (&ИзменениеИКонтроль) не срабатывает со стопроцентной гарантией
Вы на это вообще не смотрИте. Когда Вы выполняете доработки, Вы рассчитываете, что они будут использоваться долгое время, в том числе после того, как платформа будет обновлена. И не стоит просчитывать заранее, как будут работать те или иные методы встроенного языка в будущем. Есть описание какого-то механизма, есть примеры его использования - вот на это и стоит опираться. И так понятно, что в работе функционала могут наблюдаться ошибки. Любая функция может давать сбой в определенных ситуациях. Ошибки отлавливаются и исправляются вендором. Оперативно или не очень.

А то так можно не использовать значительную часть функционала только потому, что в тех или иных релизах в работе этого функционала были зафиксированы баги.
---
Но по сути вы правы

https://wonderland.v8.1c.ru/blog/razvitie-mekhanizma-rasshireniy-konfiguratsii-15/

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

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

Специально для таких небольших доработок мы сделали компромиссное решение – новую аннотацию &ИзменениеИКонтроль. Она позволяет вам добавить собственные изменения в метод, сохраняя, при этом, его исходный текст.
---
единственное: у меня почему-то работало все это дело только с функциями, если не ошибаюсь
---
Если добавляются новые объекты или реквизиты, то делать это необходимо НЕ В РАСШИРЕНИИ. Был случай когда клиент хотел обновиться самостоятельно (БП, но расширение с добавленными реквизитами), и при обновлении удалил расширение. Потом подключил обратно, и естественно получил пустые реквизиты. Это лишь малая часть головняка, которая возможна при доработке через расширения.
---
Ну мы отключаем расширение на период обновления - и при обратном подключении данные не пропадали)). Может проблема была в том что клиент не отключил, а именно удалил расширение?
---
Проблема именно в этом. Поэтому нет никаких гарантий, что кто-то не залезет своими шаловливыми ручками и не испортит всё на корню.
---
Тогда давайте попробуем сравнить подходы к доработке типовой конфы если предполагается, что будет изменено не менее 1/3 функционала, с точки зрения +/- того или иного способа.
Я вижу такую картину:

1. Механизм расширений.
  + Вроде как используем последний тренд для доработки типовой конфы.
  - Адаптация своих доработок в расширении к очередному релизу поставщика, в основном из-за отсутствия механизма "сравнения-объединения" расширения с основной конфигурацией, за счет чего не видно где именно наши доработки пересеклись с типовыми. Сейчас приходится "ползать" по тексту модулей вручную и самому анализировать где что поменялось.
 - Нельзя в конфигураторе написать/изменить запрос с обращением к метаданным или реквизитам добавленным через расширение. Все запросы и СКД пишем в режиме 1С:Предприятие - потом переносим в конфигуратор... Особенно весело становится когда делаешь внешний отчет в ЗУП 3.1 с использованием специальных временных таблиц....
 - Нельзя во внешней обработке без танцев с бубнами задать у реквизита тип, который добавлен в расширении.

2. Снятие с поддержки - внесение изменений в основную конфигурацию.
 + При обновлении на следующий релиз путем сравнения-объединения сразу видим где наши доработки пересеклись с типовыми.
 + Пишем/меняем запросы и СКД сразу в режиме Конфигуратор.
  + Все новые типы метаданных доступны во внешних обработках.

Прошу дополнить/изменить данную оценку.
---
Я так же как и (6) не пойму - зачем использовать расширения если перерабатываете треть базы...
И кроме того опять же не вижу смысла снимать с поддержки, или вы не знаете как обновлять измененные конфигурации?
Да пусть там хоть 80% изменено - нет причины снимать с поддержки. И соответственно не надо никаких сравнить-объединить...
Штатный механизм обновления вам прекрасно предоставляет возможность увидеть все изменения и решить что с ними делать именно в свете обновления.

Добавьте
2. -Невозможность использование штатного обновления...

3. Разрешить изменения в конфе
+ Все + что и во 2
+ Всегда доступно штатное обновление с отображением , что было изменено вами, а что изменилось в обновлении по отношению к оригинальной конфе.

Вы реально -то можете назвать аргумент - за то чтобы именно снять с поддержки?
Вам нужно изменять - изменяйте - зачем с поддержки то снимать?

Для снятия могут быть причины - но не в вашем случае, вы по крайней мере ни одной мало мальской не указали
---
Видимо я не совсем верно выразился - под "снятием с поддержки" я имел ввиду внесение изменений в основную конфигурацию. Прошу извинить за некорректное использование терминологии.
---
Вот с подобных неточностей и начинаются ошибки программистов...
Нет?
Если вам говорят одно, а вы будете делать совершенно другое - к чему оно приведет?
Ведь это совершенно РАЗНЫЕ кнопки!
---
И опять же позвольте еще усомниться в вашей точности...
Если вы перепутали Снятие с поддержки и Вкл возможности изменений , то почему вы постоянно упоминаете обновление через сравнение-объединение, которое остается единственно возможным при снятии с поддержки.
Поскольку при простом включении возможности изменений - доступно именно штатное обновление с анализом изменений...
---
Тут суть в самой возможности этого анализа - в случае использования расширений такой анализ и применение его результатов возможны только в ручном режиме.
---
Да нет я не о расширениях...
Снятие с поддержки - внесение изменений в основную конфигурацию.
+ При обновлении на следующий релиз путем сравнения-объединения сразу видим где наши доработки пересеклись с типовыми.

Вы уж поймите до конца, что при возможности внесения изменений в конфу остается весь полный функционал обновления!
И не нужно обновлять именно "путем сравнения-объединения" не понятно чего с чем...
Ибо в штатном обновлении на первом шаге выполняется всегда сравнение и вы всегда можете увидеть все то что вам нужно...
---
Ок, пойду почитаю мануал про обновление конфы с включенной возможностью внесения изменений. До этого был опыт обновления конф только через сравнение-объединение :)
---
Главное там выбрать "Показывать объекты измененные дважды" - вы увидите те , которые вы изменили и которые меняются текущим обновлением - и вам остается решить чего с этим всем делать...
---
Спасибо за рекомендации. Правильно я понимаю, что в приведенной мною ситуации правильнее было бы вести доработки в основной конфигурации с включенной возможностью изменений?
---
Что это за изменения функционала такое , которое затрагивает 1/3 конфигурации ? Скорее всего это все плохо продумано и вмешательство идет там, где не надо.
Обычно требуется дополнять конфигурацию под нужды заказчика, а дополнять во многом можно не трогая типовой функционал: подписки на события, свои регистры, свои модули и свои обработки и команды, свои роли, внешние формы, внешние регламентные задания + изменение форм программно.
Об этом много написано.
---
Я думал это стандартная практика - когда мы берем более/менее подходящую типовую конфу и "перепиливыем" почти полностью под нужды заказчика. Разве у остальных была другая история?))
---
Представьте себе. Можно допилить под нужды так, что конфигурация будет легко обновляться.

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

Просто рано или поздно клиент задумается об обновлении своей конфы.
---
Ну вот например, нужно добавить новые реквизиты у типового документа и завязать на них логику при его проведении. Предлагаете новые реквизиты хранить в регистрах сведений, а потом в подписках на событие очищать результат типового проведения и создавать/изменять движения заново?
---
Реквизиты то свои можно добавить, документ при этом остается обновляемым и при сравнении объединении они никуда не денутся.

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

Но если нужно например хранить остатки в разрезе новых реквизитов, то лучше завести свои регистры.
---
Хорошо, но всегда остается вполне вероятным ситуация когда нам нужно будет "пересечься" с типовым функционалом.
---
Вероятность есть. Но при грамотном подходе эти пересечения можно свести к минимуму.

Всяко перелопачивать 1/3 конфы под нужды заказчика, превращая ее в необновляемого монстра никогда не нужно.
---
Нет конечно, если реально понадобились новые реквизиты (вот только реально они надобятся в 1 случае из 10, а в остальных случаях это блажь клиента или неграмотность программиста ведь есть понятия "доп реквизит"), то безусловно надо создавать именно реквизиты документа.

Современные конфигурации уже очень адаптированы под различные виды деятельности и переписывать 30% конфы по любому не представляю.
Ну 5-10 от силы...
---
Вы привели преступную практику, которая убивает базы клиентов, когда в переписанной на 30% конфе туча информации, но прогаммист это выполнивший ушел, и никто кроме него вообще не в состоянии разобраться что и для чего изменено...
Но зато такая ситуация очень удобна тем кто желает заработать - клиент платит огромные деньги за свои ошибочные просьбы "доработать", особенно когда у него все останавливается или начинает показывать пургу...
---
Ну вот именно с такой ситуацией мне и пришлось сейчас столкнуться - когда мы имеем 30 % основного функционала перепиленного с помощью расширений. Сейчас каждое последующее обновление на новый релиз начинает вызывать головную боль.
---
А вот тут могу только посочувствовать, если вас взяли в штат и вы работаете за зарплату а не по часам... ;-)))
Но на мой взгляд этот ваш вариант еще менее болезненный, ибо у вас осталась неизмененная конфа и вы скорее всего как минимум не теряете ни данных ни основной функциональности...
---
Вы думаете, что включив возможность изменением (или, тем паче, снятием с поддержки) и допилив без расширений головной боли убавится?))))
---
Я так не думаю, я пытаюсь вместе с сообществом найти правильный подход к доработке типовой конфигурации в случаях аналогичных моему. Если мы сейчас выработаем какое то решение, то это поможет многим избежать ошибок и сразу начать всё делать правильно.
---
Могу поделиться своими соображениями, если Вы не против:
1. Как уже было замечено - переписывать треть типового функционала, это далеко не тот феншуй, к которому нужно стремиться, и если необходимость такого реально обоснована, то тут приходит на ум, что не та конфигурация была выбрана за основу для настроек...
2. Принимать решение о включении возможности изменений можно и нужно только тогда, когда другими средствами реализовать желаемые настройки не представляется возможным...
3. Перед началом настроек, когда в системе уже есть много изменений, но необходимость реорганизации обоснована, нужно провести тщательное "расследование", в результате которого, вполне вероятно, что какая-то часть (возможно большая) просто не востребована пользователями, и включать её в новую реальность нет никакой необходимости
---
Большое спасибо за Ваше мнение - оно весьма содержательно.
---
в продолжении могу сказать, что уже 100500 тыщь раз приводил конфигурации, снятые с поддержки, в типовым, без каких-бы то ни было настроек - просто показав пользователям, как работает типовая - очень часто настройщики/поддержальщики настраивают что им скажут, не имея ни малейшего понятия, о том, что \то в типовой есть и работает /(боюсь предположить, что знают, но идут на это сознательно - тогда они просто тридварасы, но увы, бывает и так))))
---
https://wonderland.v8.1c.ru/blog/razvitie-mekhanizma-rasshireniy-konfiguratsii-15/

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

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

Это понятное ограничение, но технически следовать ему не очень удобно. Такое переименование в расширении приходится выполнять вручную. К тому же не всегда бывает ясно, какое исходное имя было у переименованного объекта.
---
Мда.... уж
---
Коллеги, большое спасибо всем за Ваши ответы, но пока у меня остаются открытыми следующие вопросы:

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

2. В случае если мы уже имеем сильно измененную типовую конфигурацию с помощью механизма расширений, стоит ли "перетаскивать" все доработки в основную конфу для облегчения процесса обновления? Или стоит оставить всё как есть и двигаться в сторону проработки методологии ведения доработок (типа делаем все на подписках, избегаем директивы &Вместо и т.п.), чтобы упростить себе жизнь при обновлении?
---
но пока у меня остаются открытыми следующие вопросы:
1. Критерий для принятия решения связан с тем какие именно доработки планируются. Изменения формы и на сколько они существенны, изменения модулей в части логики работы... Иногда проще сделать свою форму и написать для нее нужный функционал. Опять же программное изменение формы - интересный прием, но когда таким образом надо перекроить всю форму есть ли смысл делать это программно?
2. Если есть доработки в расширении (особенно написанные не вами) можно продолжить дописывать их, или изменения вносить в типовую. Только опыт Вам позволит сделать выбор.

Из моего опыта... Есть ЕРП, сначала ее сняли с поддержки(не с замка) и сильно дописали, потом решили вернуться на поддержку... Внедрили расширение, вернулись на поддержку, но и с расширением сильно дописана... сейчас я уже вношу изменения в конфигурацию, так как постановка на замок не планируется, да и обновления откровенно много занимают времени. Проще нужный функционал добавить из типовой....Как то так.. Вот
---
1.для меня Критерием служит сложность той или иной доработки , если возможность сделать через расширение с минимальными затратами ( и изменения нужно вносить в 2-3 х местах ), то использую расширение Если изменения более сложные , то стоит задуматься об изменении основной конфигурации
2. Может и стоит , но явно не все а только критически важные , возможно стоит обьединить несколько расширений в одно если они заимствуют похожие объекты . В любом случае нужен комбинированный подход- что-то оставляем в расширении что-то переносим в основную
---
Судя по всему, для серьезных доработок, вариант с внесением изменений в основную конфигурацию является более подходящим...
---
Опять же если так серьезно нужно перерабатывать функционал, то стоит определить степень обновляемости. Все равно треть типового функционала будет переработана, и скорее всего это основная треть, так что именно нужно будет после этого обновлять? Вот как то так...
---
Ну допустим поставщик выпустил обновление блока по тарифам - который мы затронули совсем немного - и нам бы хотелось получить все новые фишки. Но при этом если мы автоматически установим обновление на блок по хранению сканов документов - это приведет к большой работе по адаптации нашего расширения к новым "не нужным" изменениям, только ради того что бы расширение подключилось - иначе получим ошибку при подключении.
---
Если вы допустили снятие с замка, автоматически вы не обновите. Придется обновлять в ручном режиме и лучше всего в режиме дважды измененные. Если так уж важны новые фишки конкретного блока, обновляете его полностью, затем вносите те самые "немного затронутые изменения".
---
(50) Большое спасибо за идеи! Я предполагаю что мы придем к похожей схеме.
---
Удачи. Не знаю как во всех типовых, но в ЕРП появились общие модули Локализация - с пустыми процедурами. Вот я их стал активно наполнять... Учитывая что в типовых они всегда будут пустыми, при их обновлении проблем не предвидится...
---
Спасибо :)