Не так давно заметил что многие зачастую стараются избегать использование расширений в угоду привычным внешкам. Сразу же стало интересно почему так, ведь зачастую решение задачи расширением в сотню раз проще. Можете описать плюсы и минусы, к примеру, доработки типовой ПФ или обработки путём расширения?

(0) В базовых кофигурациях расширения не работают.

(0) Изменение формы объекта. Изменение логики объекта.

(2) Ну в случае с небольшой доработкой например УПД. Попросили сделать им в Основании вместо Договора Счет на оплату. Если не расширением, то пилить УПД с нуля - это та ещё дичь. Ну это конечно такой себе пример, тут все слишком просто и ничего плохого тут думаю случить не может...

(3) смена режима совместимости на расширения влияет не благотворно, а на внешние обработки - почти никак

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

Вопрос в тему: Если, например, в каком-либо модуле с помощью расширения изменили процедуру. Затем в последующем типовом обновлении данная процедура была переписана, добавлены входящие параметры и прочее. Расширение как то на это реагирует или нужно самому постоянно помнить что где у тебя через расширения изменено и мониторить при обновлениях?

(6) Самому, в лучшем случае расширение не применится если процедура новая не та по входным что перекрывали

(6) Оно отвалится. Нужно будет смержить. Это будет видно в списке расширений.

(0) Изменять ПФ оч удобно. Зашел, подменил одну строку, готово.

(6) По идее оно никак не реагирует на это, если ты в своём расширении заменил какую-то типовую процедуру на свою, а типовая и все с ней связанные при обновлении вдруг поменялись, то думаю всё к чертям полетит и надо будет переделывать.

Расширение требуется когда надо изменить поведение типовой и сохранить относительную легкость типовых обновлений.

Если можно обойтись без расширения - лучше без него обойтись путем внешних обработок.

(10) Ну вот как в моём примере, когда на создание внешней УПД уйдёт уйма времени и сил, я честно даже пытаться не стану и просто сделают расширением.

(9) это будет хорошо, если к чертям полетит. А так может и будет тихо себе работать, но некорректно. и найдут последствия этой работы через полгода.

(10) а в чем легкость типовых обновлений? как мержить изменения типовой и переписанные процедуры или переделанные формы в расширении?

(13) Делать через ИзменениеИКонтроль. В конфигураторе реализовано трехстороннее объединение модулей через внешнюю программу. Пока что у меня все мержилось одной кнопкой.

(0) Плюсы: Расширение проще тиражировать.

Минусы:
1. Если есть добавленные реквизиты в расширении - есть риск потерять эти данные.
2. Не все объекты конфигурации можно использовать в расширении.

Моё мнение: расширение - это один из инструментов. Это не "волшебная таблетка от всех болезней".

Отлично подходит, когда нужно использовать "временную заплатку".
Для крупных проектов не подходит. Для средних - возможно, но с учетом ограничений (п.2 в минусах).

Пользоваться расширением или нет - нужно решать исходя из следующего правила:
"Любая сложная система стремится к повышению уровня хаоса. Задача разработчика держать уровень хаоса в допустимых пределах".

(15) Ну да, потеря данных из реквизитов в расширении это конечно было бы крайне печально. Буду иметь в виду. А вообще открыл для себя расширения вот буквально недавно, раньше как-то всё вне поля зрения оставалось, и был приятно удивлён. Да конечно выходит это не идеальный инструмент, но вспоминая прошлые задачи, которые я мог решить в сотню раз быстрее расширением и без каких либо рисков, понимаешь что всё таки крайне полезная вещь.

(16) не имей это ввиду. Абсолютно точно также можно прохерить данные и по объектам изнутри конфиги, если без включения мозга туда пхать куда попало.

А идеальных инструментов вообще не бывает.
Можно и с большим удобством ногой от микроскопа гвозди в подошвы ботинок вколачивать - очень удобно. Только микроскоп не для того придумывали.

(10) +100500

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

(14) т.е. надо использовать нештатные средства для сравнения модулей. а что с изменениями форм делать?

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

(22) ну так о чем и речь... нормальный вспомогательный инструмент. Практически на 100% замещает собой необходимость подключения ВПФ или внешних обработок.
Делающий использование таких обработок практически идентичными тому, как ведут себя обработки встроенные внутрь основной конфигурации, если их делают внутри, а не внешними.

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

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

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

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

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

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

(15) Если есть добавленные реквизиты в расширении - есть риск потерять эти данные

Поэтому я у своих клиентов применяю гибридный вариант.

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

(23) "Плюсов от применения Расширения, как способа модификации прикладного решения очень много."

Я правильно понимаю - смысл расширения в следующем.

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

Вариант решения который сейчас.

С формы снимается признак нахождения на поддержке. Вносятся изменения. При каждом обновлении необходимо проверять не затрут ли изменения доработки.

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

Проблем с обновлением в этом случае нет.

Так ?

(28)>>Вариант решения который сейчас.
>>С формы снимается признак нахождения на поддержке.
можно внести изменения в переопределяемый модуль в который идёт вызов при создании на сервере формы, сама форма останется на замке.

(29) Где происходит добавление реквизитов на форме ? В новой форме которая добавляется в расширения ?

Или реквизиты добавляются только программно ?

(30) да, только программно, я про вариант без расширения

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

(26) Я уже делал ВПФ из типовых, некоторые простые, с некоторыми придётся посидеть, а с УПД я вообще не вкурил... Она сделана обработкой и раскидана чёрт знает как повсюду. Ну может я просто реально туплю

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

один тот факт что можно одним движение отделить привнесенный код от стандартной очень много чего стоит

(32) +100500
Зачем или-или. Надо пользоваться тем инструментом, который подходит к для решения задачи, а не использовать всегда тот, который привычней.

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

Главный минус -- это расширение нельзя сравнить конфигурацией

но есть EDT, который всё никак не может догнать платформу
хотя уже 8.3.16

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

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

(39) кто ж спорит, сейчас кошерно реквизиты программно прописывать

(40) В случае с использованием расширения реквизиты даже программно не обязательно прописывать, их вполне можно добавить визуально. Просто при правильном подходе в расширение желательно не тянуть ВСЕ реквизиты формы, в идеале, чем меньше, тем лучше, по сути только нетиповые реквизиты... Это, конечно, не всегда делают, потому что влом, ибо после добавления формы в расширение надо пробежаться по всем реквизитам и по большей части затянутых этим добавлением в расширение и поудалять их нафиг. Делают это редко, обычно это происходит либо по незнанию, либо по лени :-)

Буквально на днях открыл еще один немаловажный плюс расширений - работа в веб клиенте. Столкнулся с важной, для работы программы клиента по его запросам, внешней обработкой, которая прекрасно работает в тонком клиенте и наотрез отказывалась трудиться в веб. Мудрил два дня, пришел к решению перенести обработку в расширение - все заработало как надо

(28) Я больше думаю не о модификации уже существующих форм - если я использую расширение. Да, так можно сделать и многие так и делают.
Но мне больше интересны возможности перехвата вызовов всяких разных процедур.

Визуализация тоже возможна, но она все-таки вспомогательная. Можно свою визуализацию в расширении написать :-)
Полностью свою форму сделать и только при необходимости, что эта форма в основной конфиге получила некие изменения, внести в свою форму новшества, чтоб поддержать изменения.

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

(43) Но это все я фрагментами перепобовал. Но готовую, чтоб похвастаться не дам.
Но на самом деле, есть определенные проблемы с тем, что все больше и больше функциональности именно в форме документа или вызывается из формы документа.
Много. Переделывать нужно очень и очень аккуратно.
Это болезнь всех продвинутых типовых.

не боюдут 1совцы заветы MVC

(45) ну это да. Но тем не менее, у разработчиков платформы этот опыт имеется на должном уровне.

(45) MVC... Тут в соседней ветке требуют запретить пользователям без полных прав проводить документ неинтерактивно - вечный вопрос о контексте формы и объекта со своим Мнением у каждого. Прикинь, в какую бы восхительную какаху превратилась бы платформа, учитывай она хотелки каждого со своим Мнением? =)

Подскажите пожалуйста пару моментов.

Позволяют ли расширения сделать следующее

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

2. В конфигурацию добавлен новый регистр, у существующих документов добавлено проведение по этому регистру. Возможно ли с использованием расширения иметь документ полностью на поддержке, а в расширении возможность движения по новому регистру ?

(48)
1. нет
2. Да

(49) да

А отладка в расширениях работает ?

(49) То есть получается что если у документа изменен модуль объекта и движения по новому регистру с помощью расширений это можно вынести в расширения и оставить документ полностью на поддержке ?

(52) да. но это и раньше работало, с помощью подписок.

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

(48) (49) что будет с данными, если расширение отвалится? Есть документ, который является регистратором для регистра из расширения, если такое расширение отвалится из-за ошибок, данные продадут?

(54) Забыл дописать про плюсы расширений - это перехват результатов процедур и функций.

(54) Начиная с 8.3.16 уже и константы в рсширении можно добавлять

(51) Работает

(55) Смотря что за расширения. В общем случае если мы добавляем объект (например Регистр), то создается отдельная табличка. И если расширение отвалиться то ничего не будет. пока расширение не удалишь, таблица останется в базе

https://wonderland.v8.1c.ru/blog/rasshirenie-dannykh/

Берем Пустую конфигурацию и создаем пустой справочник.
Физически будет создана таблица с именем ReferenceN, где N число - внутренний номер таблица. Для новой пустой базы это будет 31, следующая таблица будет с номером 32 и т.д.

Добавляем расширение и в расширении добавляем реквизит, физически будет создана новая таблица ReferenceNX1, т.е. у меня это Reference31X1, в которую будет скопирована структура и данные из таблица Reference31 и добавлено новая колонка под мой реквизит

Добавляем расширение 2 и в расширении добавляем реквизит 2, новых таблиц нет, а в таблице ReferenceNX1 появиться вторая новая колонка

Из режима предприятия добавляем данные - эти данные будут записаны в Reference31X1, в первичную таблицу ничего писаться не будет

Эмулируем отвал расширения.  В  независимости от того какое расширение отвалиться или отвалятся оба в режиме 1с предприятия при попытки изменения данных (или записи новых данных) мы получаем сообщение об ошибки - v8: Ошибка "Работа с таблицей невозможна. Структура таблицы несовместима с текущими..."

Удаляем расширение 2, а из расширения 1 удаляем наш реквизит 1. Так как теперь расширение не изменяет данные, то данные из Reference31X1 будут перенесены в Reference31, а таблица Reference31X1 будет удалена. Естественна данные из наших реквизитов будут утеряны навсегда, так как мы физически удалили эти реквизиты

Больше года работаю с двумя базами УНФ с ну очень обширными расширениями. Не могу сказать, что проблем совсем не возникает, но глобального ничего. в основном глюки случаются после обновления конфы. В других моментах не припомню.
Первое преимущество расширений - базу не нужно снимать с поддержки, для многих клиентов это ключевое условие. Соответственно, обновление конфы также проходит как обычной типовой базы, за редкими исключениями.
Второе, это возможность вносить изменния в код модуля объекта, менеджера, общие модули, модуль сеанса, модуль приложения. Разумеется, внешниие обработки здесь не помогут. А вносить изменения в аналогичные модули в типовой конфигурации - прощай возможность обновления, ну или  превратить этот процесс в ад.  
А вот ради добавления/изменения печатной формы создавать расширения точно не стоит - внешние печатные формы прекрасно с этим справляются.

(61) не всякие печатные формы прекрасно. Есть и такие, что можно или внутри конфигурации или только в расширении. в ЗУП кое-какие попадаются.

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

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

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

(63) Можем лишь мечтать о том, что расширения допилят в ближайшие пару лет до уровня, на котором о внешках и переписках конфы можно будет в принципе забыть...

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

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

(65) >> ...к каждому очередному обновлению типовой успевают выдать в сопровождениях на релизах по нескольку штук ... расширений до момента выхода нового обновления или релиза типовой.

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

А для разработки долгоиграющих расширений мало вдумчивой работы. Потому что в любой момент поставщик конфигурации (форма 1С) может без предупреждения пересмотреть логику и алгоритмы тех объектов, которые ты очень вдумчиво дорабатывал в своём расширении. И тебе мало того, что надо каждый раз анализировать и искать такие проблемы, а потом ещё и переписывать, но и тестировать каждое обновление. Потому что зачастую проблема совместимости расширения с конфигурацией не очевидна. Например, ты расширил какую-то процедуру или функцию, которую 1С не меняла в обновлении, но 1С поменяла другую процедуру, которая теперь по-новому формирует структуру параметров для твоей доработанной процедуры. Никакой синтаксконтроль не предупредит тебя о такой ошибке. Выявить её можно только на этапе тестирования, а иногда и очень тщательного, обрабатывая все возможные варианты и случаи, где задействован доработанный функционал.

(66) "Выявить её можно только на этапе тестирования" Ничего подобного. Надо привыкать после обновления нажимать кнопочку "Проверить возможность применения" и будет тебе счастье. НИ ОДНОЙ ошибки не пропускает (в том числе и те что ты предложил как пример). Многие исправляются по кнопке Исправить. Но тут надо подходить вдумчиво, иногда нужно что-то руками делать. Но ... проблем с выявлением ошибок в расширениях после обновления сейчас практически не существует

(67) бред

Пример функция возвращает текстзапроса. Мы вносим изменения, потому что в типовой ошибка. В следующем релизе 1С исправляет текст и добавляет новые поля. И что твой контроль покажет?

(69) проблема в том, что такого рода ошибку и внутри конфигурации пропустит точно также

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

(71) И на потребителей тоже, особенно в ERP

(60) Это одна из проблем расширений (я не про добавление реквизитов - ибо на мой взгляд это в принципе не верно а про невозможность отключения расширений при изменении структуры данных), но все равно - возможности перекрывают все недостатки.

(72) и на собственных разработчиков типовых тоже

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

(75) Нажимаешь кнопочку с воронкой и знаком заимствования и выводятся только измененные объекты. Никаких записей не надо. Ну а по-хорошему, надо после завершения расширения почистить его от ненужных элементов

(70) нет, так как сравнение конфигураций покажет что тут вся функция переписана в хлам, и ты включаешь голову

(67) Если ты не понял моего примера, переспроси. Встроенная проверка применимости расширения никак и никогда не выявит описанной проблемы. Даже если расширенная функция или процедура полностью переписана, не говоря уже о приведенном мною примере.

(70) >> такого рода ошибку и внутри конфигурации пропустит точно также

Можно. Но вероятность ниже. В окне трёхстороннего сравнения ты увидишь, что текст запроса тобою дорабатывался. И увидишь, что 1С В обновлении 1С тоже что-то поменяла в тексте запроса.
В случае, когда ты что-то допилил в расширении, ты не увидишь ничего. Тебе надо самому помнить, что ты дорабатывал некую процедуру и раз 1С изменила её в обновлении - надо идти в расширение и проверять совместимость твоих дописок с дописками 1С.

(61) "это возможность вносить изменния в код модуля объекта, менеджера, общие модули, модуль сеанса, модуль приложения"

Так это ключевое что нужно.

Наглядный пример с чем столкнулся.

Есть конфа БП. Не обновлялась три года. В конфу добавлено несколько регистров и у существующих документов включена возможность проведения по регистрам.

То есть
1. Изменены формы документов.
2. Изменены модули объектов документов.
3. Изменен состав регистров по которым проводится документ (добавление возможности проведения про новому регистру).

И на эту всю конструкцию надо натянуть релизы за 3 года. А это около 30 штук.

И начинаются пляски с бубном.

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

И самое паршивое что от этого не закроешься. Либо при каждом накатывании релиза смотреть все изменения (а это время) либо накатывать а потом если что-то отвалилось благодаря чудесной сериализации объектов (тому что это придумал в фирме 1С надо памятник при жизни ставить) выгружать из копии и загружать.


Если расширения позволят хотя бы 2 пункта из 3 решать то это уже будет здорово.

(73) "я не про добавление реквизитов - ибо на мой взгляд это в принципе не верно"

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

А вот то что при обновлении документа поступления от поставщика конфигурации отваливаются все движения по добавленным в конфигурацию регистрам которым добавлены тобой это уже веселей.

Рекомендации от Павла Чистова https://expert.chistov.pro/public/1039552/
В принципе, согласен со всем и пришел к тем же выводам, кроме пункта 2. Теперь приму к сведению

(11) почему у тебя на создание внешней упд уйдет много времени?
получение данных для ПФ - уже описана, макеты - тоже есть, остается вызвать один метод, подменить в нем данные, выполнить заполнение макета и все
на все про все обычно уходит полчаса - час

(82) На сколько мне известно он чистый теоретик. По пятому пункту абсолютно не согласен. Я вообще сильно сомневаюсь, что он, что то разрабатывал (возможно ошибаюсь)

(81) можно подробнее? (Не совсем понял о чем речь)

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

про патчи уже писали - как сценарий использования расширений?

(87) Писали. Им тут патчи не интересны.

(86) в (82) написано "рекомендации от.." :) кто то , что там писАл я не разбирался :)

(84) На сегодняшний день 5-й и 3-й пункт, на мой взгляд, самые важные и обязательные к исполнению. По крайней мере моя личная практика говорит именно об этом
(89) А здесь ты прав. не важно кто написал статью, важно что она опубликована на сайте Чистова, значит он полностью согласен и рекомендует

(90) а, моя личная практика говорит об обратном. Всех клиентов перевел на расширения (с добавлением в них новых объектов, справочников, документов , регистров) - никаких проблем нет.

Автор стати из (82) описывала собственный опыт.
Причем весьма богатый опыт использования расширений. Значительно более широкий, чем у некоторых присутствующих тут апологетов расширений.
Все её выводы абсолютно справедливы.
Мы поначалу тоже очень радовались возможностям, которые давали расширения, и пытались абсолютно все доработки перевести на них.
Но чем большее количество доработок выносилось в расширение, тем с бОльшими проблемами мы сталкивались при каждом обновлении исходной конфигурации. Были попытки разнести не связанные между особой доработки в разные расширения, ограничить доработки форм только программными методами, не делать расширения данных, и множество других компромиссов. Однако количество косяков при каждом очередном обновлении не сильно уменьшается. Причем косяков, которых не возникло бы будь доработки сделаны внутри конфы.
Так что расширения хороши, но только для очень небольшого круга задача. Да и то при условии соблюдения ограничений, изложенных в той статье.
А те кто пишет, что у него никаких проблем не было, либо ограничивался мелкими доработками (контролировать небольшие расширения действительно довольно легко), либо работает с расширениями недавно и не сталкивался со значительными изменениями расширенных объектов в исходной конфе при обновлении, когда едва ли не половину доработки приходится воспроизводить чуть ли не с нуля из-за того, что 1С-ники решили переработать логику какой-то подсистемы.

очередной холивар

(82) https://expert.chistov.pro/ это зеркало Инфостарта.

Можешь в этом убедиться поменяв в адресе ссылки на статью https://expert.chistov.pro/ на http://catalog.mista.ru/

Этих клонов (зеркал) полно. Для примера

catalog.mista.ru

soft.crimea.com

infostart.blog-buh.ru

catalog.lessons1c.ru

(85) Попробую.

У тебя есть документ "ПоступлениеТоваровУслуг".

В типовой редакции БП 3 у него в свойствах есть возможность проведения по 39 регистрам.

В конфигурацию добавляется еще один регистр. Например "УчетДвиженийЗапчастиРемонт".

В документе "ПоступлениеТоваровУслуг" добавляется возможность проведения по этому регистру. То есть было 39 регистров, стало 40.


Теперь смотри что получатся дальше.


Ты накатываешь обновления БП за 3 года. В какой-то момент поставщик конфигурации (фирма 1С) вносит изменения в документ "ПоступлениеТоваровУслуг" (например добавляет реквизит или меняет модуль объекта). И при замещении объекта тем объектом который есть в конфигурации поставщика у тебя слетает добавление возможности движения по регистру "УчетДвиженийЗапчастиРемонт".

В результате реструктуризации ты получаешь пропадание движений по регистру "УчетДвиженийЗапчастиРемонт" где регистратором был документ "ПоступлениеТоваровУслуг".


Так вот мой вопрос был в следующем - позволяет ли расширение сделать так чтобы эти добавления (возможность движения по регистру "УчетДвиженийЗапчастиРемонт" документа "ПоступлениеТоваровУслуг") не  
не затирались при замещении объекта.

То есть у тебя документ стоит в состоянии "изменения запрещены", но при этом расширение говорит что по этому документу возможно формирование движения по регистру "УчетДвиженийЗапчастиРемонт").

(95) Хоррроший вопросик
И какой ответ на ннего?

(96) Ответ на него можно получить от те кто плотно пользуется расширениями.

(97) я не использую типовые конфигурации, но если ты заимствовал документ в расширение и назначил ему дополнительные регистры то при обновлении ничего не слетает.

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

(99) Как ты используя расширение сможешь сделать что документ полностью стоящий на поддержке формирует движения по новому регистру ?

(98) >> я не использую типовые конфигурации

Тогда нафига тебе сдались расширения?....
Я для себя вижу только два места применения расширений:
1. тиражирование некой универсальной доработки для однотипных конфигураций
2. расширение типовой конфигурации, стоящей на поддержке (полной или частично).
А расширение для самописки - дичь какая-то. Геморрой на ровном месте.

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

Типовой документ даже в самом крайнем случае будет иметь процедуры обработчики:
если проведение есть, то обработка ОбработкаПроведения
есть только запись, но нет проведения - ПередЗаписью
вообще ничего нет, но есть подписка, например, ПроверитьДоступПриЗаписи - смотрим, какая процедура обработчик у такой подписки и перехватываем в Расширение именно ее, а не саму Подписку и это сработает. Можно удивляться, но захват в расширение процедур и функций просто из общих модулей работает!

Ну а дальше дописываешь все, что в голову взбредет...

Если речь идет о нетиповом объекте, вроде набора записей в чем-то - но если это же тупо новый набор и нее только запись, но и чтение в запросах по этому набору - хоть ты куда его размещай - придется написать заново. Старые типовые отчеты, АРМ и т.п. не увидят этих данных, если не напишешь нового отчета, нового запроса, динамического списка и т.д. и т.п.

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

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

(101) // А расширение для самописки - дичь какая-то

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

Это как мне говорили - а зачем при разработке самописной конфиги использовать хранилище конфигурации?!

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

Мне всегда казалось что скажем Оперативный учет можно под себя менять как угодно но оставляя выгрузку в бухгалтерию. А вот в бухгалтерии ничего по возможности не менять чтоб не ломать голову с обновлениями. Это я про 7-ку. В той же комплексной народ работает, но если она переписана сильно то каждое обновление еще тот геморрой поэтому мы ушли много лет назад на разделение ТИС-БУХ-ЗИК.
Что касается 8-ки. Пример для тех кто ведет учет в БП3. В документе "Отчет производства за смену" только один склад можно указать (то есть и сырье с него списывается и продукция на него приходуется). Если взять ПУБ 7.7 то там два скалад можно выбирать. Вот и мне желательно чтобы в БП 3.0 было два склада (то есть изменения в интерфейсе и в процедуре проведения). Вот как лучше делать - через расширение или через редактирование конфы ?

(105) В расширении пишешь под себя свой АРМ и крутишь типовыми документами, даже не изменяя в них состав реквизитов тч и шапки.
Т.е. если у тебя данная конкретная проблема ограничена просто вопросом, что нет возможности провести некий набор данных с использованием одного экземпляра документ-объекта, не ломаешь ничего типового, а прикручиваешь нужное рядом.

Если нужен аналог такого поведения, то посмотри на работу по Выпискам банка, в которых создается множество документов списаний или поступлений  расчетный счет, а вот документа Выписка даже не существует.

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

(106) Да даже можно просто. Где-то создать константу СкладДляПродукции и потом через расширения немного переписать модуль проведения документа "Отчет производства за смену". Все ж тоже самое. Списание сырья оттуда а оприходование готовой продукции отсюда

(108) Обычно я сталкиваюсь, когда сырье или материалы или ПФ идут с разных складов.
ОПЗС на закладке Материалы может быть не пустой только для самых обобщенных случаев учета.

(104) >> а зачем при разработке самописной конфиги использовать хранилище конфигурации?

Здесь как раз использование хранилища обосновано.
Хранилище решает две задачи:
1. Групповая разработка, когда над проектом работают несколько человек.
2. Хранение истории любых изменений. Даже если разработчик один, это может быть востребовано.

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

>> почему нельзя при этом использовать все возможности платформы, которые предоставляются?

А ещё платформа умеет решать системы линейных уравнений. Ты это тоже обязательно используешь в каждом проекте?...

(107) >> тиражными конфигурациями бывают не только типовые...

Под типовыми я понимаю любое тиражное решение, находящееся на поддержке у поставщика.
И не важно - кто этот поставщик и разработчик - 1С, РАРУС, БиТ или ООО "Рога и копыта" с какими-то своими отраслевыми решениями.
А если у конфы ещё и не одна поставка, это может вообще превратиться в ад. Мы такое извращение у себя уже пробовали, когда расширения не умели расширять данные.

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

(108) >> потом через расширения немного переписать модуль проведения документа "Отчет производства за смену"

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

Менять общие модули и модули проведения в расширении - последнее дело. 90% проблем при обновлениях возникает именно от этого. Уж больно часто 1С-ники любят пересматривать методики и подходы, перетаскивать процедуры и функции из общих модулей в модули менеджера и обратно, или таскать куски кода из одних процедур в другие.

(112) так вот "самописка" и находиться на поддержке. По хорошему в конфу поставщика вообще нефиг лазить - расширение справляется практически с любой задачей. Понятие "встраиваемых подсистем" (изменение конфы) вообще должно умереть.

+(113)ПисАть нужно изначально по-человечески, что бы у людей даже мысли не возникало снять конфу с поддержки.

(114) Это ты разработчикам тиражных решений расскажи.
А так же тем заказчикам, чей бизнес не укладывается на 100% в прокрустово ложе тех методик, которые реализованы в этих самых тиражных решениях. 90% пользователей вполне себе укладываются в типовые методики (хоть и не всегда понимают это). Но всегда есть 10% тех, кого никогда не устроит полностью методика, заложенная разработчиками тиражного решения. Кому по-любому придется допиливать конфигурацию под себя.

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

(113) Самописка не может находиться на поддержке.
Самописка - это конфигурация, которую ты сам написал и сам поддерживаешь.
Делать в самописке поставку и пытаться через неё обновляться - очень странное извращение. Бессмысленное и беспощадное.

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

(115) >>Это ты разработчикам тиражных решений расскажи

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

(117) так ты определись с понятиями, что такое самописка и может ли она быть тиражной.

(119) Я все определения довольно четко дал. Перечитай ещё раз, если что-то непонятно.
Самописка может стоять на поддержке (никто не запрещает этого делать), но это скорее некоторое исключение из правил.
Сам механизм поставок и поддержки предназначен для тиражирования. Использовать его на одной единственной базе данных, конфигурацию которой ты сам написал, - дичь. Для этого надо иметь очень веские основания. Я, например, себе такие с большим трудом могу представить.
Зачем? Создать поставку, поставить конфигурацию на поддержку, а потом ради доработок вместо того, чтобы дорабатывать эту поставку, лепить расширения? НА..УЯ?... Какой в этом смысл?
Мы когда делали поставку, если надо было внести изменения, мы вносили их в поставку и публиковали его. Всё.

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

(120) один из нас видимо чего не понимает :)
Я пишу конфу, выпускаю обновления, выкладываю а клиенты это обновления скачивают и обновляются. Что я должен сделать ? Хотелки различных клиентов добавлять в конфу ? Конфа единая - одна для всех клиентов. У всех клиентов конфа находиться на поддержке. Когда я выпускаю новое обновление - клиенты скачивают и обновляются. Если клиенту требуются специфические доработки то все это делается через расширения.

(121) "Под типовыми я понимаю любое тиражное решение, находящееся на поддержке у поставщика.
И не важно - кто этот поставщик и разработчик - 1С, РАРУС, БиТ или ООО "Рога и копыта" с какими-то своими отраслевыми решениями." (с) (111)

Т.е. у тебя тиражное решение, а не самописка, у тебя решения " находящееся на поддержке у поставщика ... поставщик и разработчик - ООО "Рога и копыта""

(121) Ну так это не самописка, а тиражное решение. Оно ничем не отличается от любой типовой конфигурации от 1С. Кроме масштабов распространения. Не называют же программисты, работающие в самой 1С, свои конфигурации самописками. Хотя пишут их сами.
Когда речь идёт о небольших доработках, делать их через расширения вполне разумное решение. В особенности, когда ты сам знаешь свою конфигурацию и четко себе представляешь - что и как можно расширять.
Когда же речь идёт о достаточно серьёзных доработках конфигурации, стоящей на поставке, которую не ты разрабатываешь, никто не даст гарантии, что допиленный тобою в расширении объект завтра поставщик не переделает до такой степени, что твоё расширение отвалиться. И далеко не все проблемы решаются за счет аккуратности, вдумчивости и внимательности.
Одно дело - дополнительный отчет или обработка, другое - добавить реквизитик какой-нибудь, и совсем третье - переписать проведение какого-нибудь ключевого документа по подсистеме НДС или бухучету в какой-нибудь БП, или (прости господи) ERP. Последнее делать через расширение выйдет себе дороже. Ну не умеют (и никогда не смогут) расширения контролировать изменение логики расширенного объекта во времени. Слишком нетривиальная это задача - понять как именно и какие конкретно изменения в исходной конфигурации повлияют на расширение.

если бы это не было таким явным бредом, я бы ветку не трогал... А так...