Как правильно вносить изменения в типовую конфигурацию для легкого ее обновления в дальнейшем

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

Объясню свою критику:
1. Если уж рассматривать правильности изменения в типовые конфигурации, то я бы написал о правильном добавлении ролей, интерфейсов, реквизитов объектов метаданных, модулей, форм. Там много интересных правил.
2. При создании динамических реквизитов формы, вы переводите их в разряд неявных. Особенно если их видимость зависит от других условий. Чем вводите в ступор других разработчиков, которые вместо 1минуты размещения уже своего реквизита, вынуждены разбираться в чужом коде или моделировать ситуации.
3. Вы сами можете врезаться в появление реквизитов типовой конфигурации по условиям. Вызвав безобразие на экране.
4. Некоторые документы очень сложны. Мне приходилось тратить множество времени на размещение реквизитов например в Отчете производства за смену, там несколько вариантов документа и сам реквизит нужно размещать несколько раз и дотошно его настраивать в разных функциях видимости в нескольких местах. В случае динамического размещения реквизита, это заняло бы кучу времени, как мне объяснить заказчику такое?
5. Если уж предлагать решение, то модуль целиком. Готовый, с указанными параметрами для расположения, родителями на форме, сервисом и т.д. Чтобы его можно использовать не только для расположения, а для всего спектра управления динамическими элементами.

(0) Методика переопределения и вызова обработчиков событий формы в 1С 8
http://infostart.ru/public/16980/

Мне убегать уже пора. Вкратце еще.
Elgrego, нужно не тыкать других собеседников в "незнание".
Если предлагаете систему, то писать о пользе, и недостатках. Где и как можно применять, а где нельзя.
Описывать нюансы технологии, давать людям сервис и учить на конкретных разработках.
Вы же добьетесь только того, что оголтелая школота рванет делать, как "правильно" (по вашему). Но огребать кренделей будут они, а не вы.
А технология создания динамических реквизитов формы описана просто везде, даже тут полно разработок, существует уже давно. Все идеи уже были высказаны ранее многократно.

(0) при переопределении обработчика динамически добавленного ЭУ все равно нужно писать в модуле формы вызов процедуры обработчика. Либо - строить непростую схему из (2) по "динамическому" переопределению обработчиков.
А вообще весь сыр-бор - из-за того, что 1С неспособна реализовать ООП и обращение к УЭ и их событиям из любого места кода, а также неспособна реализовать механизм программного переопределения событий существующих ЭУ.

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

Вот представляю ситуацию:
Есть база. Первый раз ее вижу. Надо обновить. Сравниваю. Вижу, что есть изменения в форме между конфигурациями поставщика, и между старой конфигурацией поставщика и текущей конфигурацией базы. Мои действия?
Отчет по сравнению показывает, что поставщик что-то накуралесил в форме. А в клиентской конфигурации вижу

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

В каком месте я перепутал? У Вас проблемы с восприятием информации.

Я пока все комментарии не прочитал, не узнал об этом.

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

Погорячился я)

Здесь я хотел написать, что это в модуле формы.
Один хрен каждый делает как ему удобней.
Честно я за 3 года во франче ни разу не сталкивался с такой методой у клиентов.
Потом три года сидел на фикси. Начал использовать такой способ. Лично мне было неудобно. И форма чуть дольше открывается. Вернул как было.
Сейчас работаю над проектом в команде. С трудом представляю, что будет, если начнем это применять.

Скоро - совсем скоро подобные темы уйдут в небытие, с БСП и их дополнительными реквизитами и свойствами.

Я там где дорабатываю модули ставлю в начале свою фамилию, в завершение три звездочки, потом проще искать.
Пример с изменением типового кода:

//Ткачев
// Если Стр.РазмерДанных > 6 Тогда
Если Стр.РазмерДанных > 10 Тогда
//***

А в чем легче потом... При обновлении?

(0) Проще доп страницу с нужными реквизитами добавить, если есть такая возможность, а не текущие двигать.
Или кнопку типа свойств объектов для редактирования своих доп. реквизитов (типа такого Универсальные механизмы для платформы 8.1.
А так обычные формы конечно быстрее обновлять.

Сам давно пришел к необходимости программно располагать элементы. Правда, с моей точки зрения,выигрыш получается только в случае небольшого количество добавляемых элементов (до 5-10). Если получается больше, то проще словить и перенести при обновлении

http://infostart.ru/public/116512/

Когда освоите эту тему, автоматизируйте дальше парсером, чтобы не ручками вставлять обновления в код:
http://infostart.ru/public/102193/

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

Модификации типовых конфигураций я бы условно разделил на 3 группы:

Добавление новых объектов метаданных, дополняющих функционал конфигурации.
Добавление новых объектов метаданных, встраивающихся в функционал конфигурации.
Внесение изменений в существующие типовые объекты метаданных.

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

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

Справочники, документы и регистры также могут существовать в конфигурации не мешая типовым объектам. Например, у вас возникла потребность автоматизировать планирование затрат организации в рамках конфигурации "Бухгалтерский учет". Вы создаете документ "Смета затрат", к нему регистр накопления и отчет по регистру. Этот функционал использует данные конфигурации (справочники "Статьи затрат", "Подразделения организаций", "Организации"), но он никак не нарушает работу типового функционала и не требует его изменения.

В общем, модификации первой группы - это "хорошие" модификации. Они дополняют функционал конфигурации и, в то же время, не мешают ее обновлению.

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

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

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

В качестве примера такой модификации можно взять случай, описанный ранее, когда создание альтернативного приходного документа в конфигурации "1С:Бухгалтерский учет 7.7" повлекло за собой необходимость изменения типовых объектов, отвечающих за формирование книги покупок (документы "Запись книги покупок", отчет "Книга покупок"). Хотя в том примере было сделано даже еще хуже - были созданные альтернативные документ и отчет.

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

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

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

Ну, и в завершении - как обновлять релиз конфигурации после того, как часть ее объектов перестали быть типовыми. Если обновление релиза типовой конфигурации - процесс механический, сводящийся к нескольким щелчкам мышью, то обновление измененной конфигурации - процесс творческий. И я бы не доверил его никакому искусственному интеллекту. У меня достаточно богатый опыт обновления конфигурации "1С:Бухгалтерский учет" на платформе "1С:Предприятие 7.7". Я выработал для себя простую систему, которой готов поделиться с вами. Не претендую на истину в последней инстанции. Это всего лишь подход к решению задачи.

Итак, исходные данные: конфигурация Ai - типовая конфигурация i-го релиза; Aj - типовая конфигурация j-го релиза, причем j > i; Bi - модифицированная конфигурация, основанная на типовой конфигурации i-го релиза. Условие задачи: обновить конфигурацию Bi до релиза j, сохранив при этом все собственные наработки.

Теперь решение. С неизмененными объектами я поступаю очень просто - обновляю их простым замещением новыми объектами. С этим, думаю, все понятно, пояснений не требуется. С модифицированными объектами поступаю следующим образом. Сравниваю конфигурацию Ai с конфигурацией Aj. В окне сравнения конфигураций я вижу все изменения, сделанные разработчиком в новом релизе без учета собственных изменений, поскольку сравниваю "чистые" конфигурации. Далее в своей конфигурации Bi нахожу те участки кода, которые претерпели изменения в новом релизе. Обновления вношу, копируя их блоками из конфигурации Aj в конфигурацию Bi. Трудоемкость этой работы зависит от объема и сложности изменений в типовых объектах. Для меня такой подход наиболее безопасный и, в конечном итоге, наиболее эффективный.

Ну что же. Вот, пожалуй, все, о чем я хотел сегодня сказать. Есть вопросы? Пишите!

как и обычно при обновлении все свои модификации придется ручками поправлять!

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

Дорогой автор!
Очарована вашей идеей! Обязательно возьму на вооружение.
Подскажите, есть ли у вас стандартная процедура добавления нового поля ввода - колонки в таблицу документа. Или нужно модифицировать процедуру ДобавитьПолеВвода(Форма,ИмяРекв,Панель,Доступность,Л,В,Ш,Выс,ПривязкаЛев,ПривязкаПрав,Данные,КнВыбора,КнОткрытия)
убрав привязки?

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

насколько я помню ПриОткрытии нет подписки, у нас все это дело вмонтировано в МеханизмНумерацииОбъектов

(0)

Прием №2 ???