как грамотно написать подсистему или дописать конфигу #297620

которая сможет жить отдельно или встраиваться в типовые конфиги от 1С ? Нужна не развернутая методика (стоит денег и буду думать сам), а концепт  ... Что то типа как написано CRM Prof у Раруса (может жить и как отдельно - продукт, а можно и встроить в УТ или УПП) по крайней мере заявляют это. Так же интересует как строите свои доработки, которые потом не создают гемор обновлениям. Конечно здесь вопрос для тех кто заботиться о своем коде  решение, а не пишет на коленке за полчаса что бы только состричь бабла, а дальше моя хата с краю ничего не знаю

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

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

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

да-да, точно пересекающихся объектов почти нет, полная независимость, но плата за это - слабая и тяжёлая связь между подсистемами

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