Интересно мнение экспертов при каком уровне доработок УПП становится необновляемой?
Есть ли у кого-нибудь примеры внедрений с сильной доработкой УПП, где на поток поставлено обновление релизов? И если есть, как это организовано?

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

(2) Как помечаются и классифицируются доработки? Ну и, конечно, НАСКОЛЬКО доработана ваша конфа?

(5) О чем и речь.

Ключевой-то вопрос: при каком уровне доработок (из реальной жизни) конфа становится необновляемой? Типа "вот такие доработки - еще обновляем, а вот с такими - уже нет"

(0) Как и любая другая кофа, УПП знаменит не обновлениями, а неисправлениями глюков.

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

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

(13) Есть реальный опыт?

(8) у меня 727 точек отклонения
обновление занимает 3 дня, а вот прогон контрольного примера, ловля блох и их парирование 2-3 недели

(15) 727 точек в коде или + измененные реквизиты, расширение типов и т.д?
Насколько автоматизирован процесс (обновление + тестирование)?

(15) можешь привести пример кода? Интересно как помечаешь...?

(0) Когда стоимость обновления превышает стоимость настройки обмена между УПП и базовой БП ;-)

ЗЫ по факту все зависит от рук программистов, если нормально внесены доработки то может стоить адекватного времени

(18) Интересен реальный опыт организации обновлений сильно измененных УПП. Есть такой?

(14) я его и описал как мог

(19) Определеись в понятиях что такое сильноизменненная конфа и что в твоем понимании  сильноизмененнная конфа

(16)
любые изменения, включая новые реквизиты

не автоматизирован
тройное сравнение + аккуратный список отклонений + комментарии
+ контрольный пример + параллельное выполнение в двух системах

(17)
// ФИО дата
// мать вашу отдел разработи, опять не то субконто воткнули
...
//(ФИО)

(22) Параллельное выполнение в двух системах - что имеется ввиду.

Взять хотя бы расчет себестоимости в УПП, ты можешь сделать отдельную процедуру которая будет закрывать себестоимость так как надо а можно переписать саму процедуру расчета себестоимости.


Сам понимаешь что в 1-м случае ты потратишшь кучу времени на разработку. при этом обновление будет происходить гладко, во втором случае быстрая разработка и как минимум 10 часовые обновления

(23) Спасибо

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

(24)
берем 1.3.9.1 - эталон
обновляем до 1.3.17.1 - тестовая

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

закрывем период, формируем регламентированное,
сравниваем результат начиная от ОСВ и до значимых регистров

(27) В стоимости обслуживания сей махины

(27) если при запуске системы ставиться задача обновляться, то разработка будет дороже, только и всего

обновиться можно всегда
вопрос денег и рук
часто мощного сервера при реструктуризации

(30) Не всегда, если при разработке кто-то не подумал об обновлениях.

ЗЫ в частности у нас несколько клиентов отказалось обновляться, после оценки обновления базы в 3-5 человекомесяцев, сделали обмен с типовой УПП

Там сложность была что была в 8.0 когда то ввели левые и правые запросы, а до этого все запросы обычные писались

(30) Какие, по твоему, принципы должны быть заложены в доработку такой конфы?

(33) Не изменять типовые механизмы ;-)

у нас конфа на пути к необновляемой... хотят сверху нахлобучить упр. недвижкой и мсфо от хомнет.

(35) какие, кстати утилиты для разборки сборки cf-ки используете?

(31) дык см. (30) [если при запуске системы ставиться задача обновляться]

Вообще можно добавить свои документы, справочники регистры
не трогать объекты поставки и приэтом обновляться??

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

(39) Понятно, у меня есть свой опыт, просто возможно есть еще какие-то мысли по этому поводу.

(0) Дорабатывать нужно таким образом, чтоб по минимуму затрагивать типовые механизмы.

(35) МСФО от хоумнета смотрели? не проще за те же бабки нанять грамотного методолога и нарисовать маппинг с РСБУ на МСФО?

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

а главное детальная документация

(43) Я могу ошибаться но помойму у нас прогеры и документы копируют чтобы не переносить изменения

Если я не трогую типовые объекты только добавляю то что мне нужно можно обнвлять типовую часть конфы??

(43) + внешние обработки (печатных форм, заполнение тч и т.д.)
новые объекты вместо доработки старых
Что еще забыли?

(45) если нет вызовов общих типовых модулей и ни кто не кокнет в Рг нужные тебе ресурсы или Рг целиком - то можно

в УПП это случалось

(46) всё это сто раз описано,
в чем смысл начинать заново ?

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

(47) а где можно прочитать про процесс обновления хочу в ЗУПЕ добавить пару документов

(50) прочитать:
- миста
- инфо.старт - дивный набор статей по обновлению типовых

(51) Судя по всему мне тоже туда - не часто в интернете

(42) маппинг уже есть и так (без проецирование на УПП). В екселе рисуют... финики хотят автоматизировать это в УПП. А потом консолидировать с другими средами (1С и не только) уже в консолидации...

из Хомнета хотя бы пришел вменяемый человек. Позвали по консолидации другую контору - приперся некий юноша из Бит-а, пожевал сопли и отбыл, оставив чувство глубокого непонимания...

доработки должны быть не меньше 80го lvla!

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

(56)Не факт если умело пользуешь конвертер то не трудно перенести данные данные в нужную редакцию ..

(57) и доп. функционал быстренько переписать

А вообще надо говорить: "Любая доработка УПП = АТСТАТЫЩ обновление"

(59)вполне разумная цена ..

(59)+Частенько помогает, если надо отказаться от маразматических прозьб клиента.

(51) Как реестр доработок ведешь? В чем (инструмент)?

(62)Спец файлик есть в который всё заноситься что используется что нет ..

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

(35) Это всё будут дополнительные объекты, они никак не будут участвовать при обновлении. У нас тоже многочё набухано, ничё обновляемся. Отдельно человек полмесяца только этим и занимается.

(56) Переход с 1.2 на 1.3 не заметили, обычное обновление.

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

(67) "сколько раз какой модуль переделывали, что вначале имелось ввиду и для чего вообще было затеено"

Это и комментариях очень хорошо даже храниться и всегда актуально в отличие от документации в ворде. Даже если и будет такое описание я его всё равно не буду использовать, разве можно ему доверять.

(62) вордовкий файл с 12 колонками,
как под мой 21" монитор

(64) [Зачем эти реестры доработок не понимаю]
бывает

А кто какие доп. инструменты использует для обновлений?

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

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

(72) с правами проще,тут железное правило - делать свои на каждый мелкий "чих"

(74) Так и делаем, только с каждым чихом их всё больше и больше ))

(75) открой УТ 11 - мелкие парные роли, всё при дельно прозрачно

Там и функций у пользователя меньше.
Взять плановика в УПП - должен видеть продажи, закупки, производство, заказы, договора, проекты, контрагентов, номенклатуру, даже оплаты и т.д.

Я сейчас работаю в организации, в которой стоит не обновляемая УПП.
Организация не очень большая - около 50 пользователей, несколько филиалов. Сейчас штат IT - 2 чел. - админ и прог 1С (должен быть еще один прог).
Уверен, что если начали изменять УПП, то в результате она (через год или пять) обязательно станет не обновляемой.

Мне удалось убедить руководство фирмы в своем видении решения проблемы. Кратко, в чем оно заключается.

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

Что делая сейчас я. Два этапа. Первый, написание правил обмена между переписанной УПП и стандартной (обмен с 01 апреля - ввод налогового кодекса на Украине)(этап завершен). На этом этапе руководство увидело, что все их пожелания, которые реализовывались кучей новых документов в старой УПП, спокойно вписались в стандарт. Второй, остался вопрос интерфейсов и прав. Сейчас реализовываю АРМы. Что получаю? Получаю произвольный интерфейс, направленный на конкретное рабочее место и полный контроль за доступом без использования RLS (кстати под RLS впору сажать отдельного программиста. ИМХО).

Это очень кратко.

Думаю с нового года организация перейдет на стандартную конфигурацию, получив все преимущества использования АРМов.

(78) Я такие УПП десятками вижу.
Самое трудное это убедить, что "неоторые хотелки" именно в таком виде руководству не нужны (, и подойдет типовой функционал.
В УПП нужно добавлять специфику производственного учета и планирования, а все остальное можно использовать как есть...

(79) По поводу "некоторых хотелок". Используя АРМы, этот вопрос перестает быть "камнем предкновения", хотя для меня существуют принципиальные вопросы, например, использование форм списка документов - я их практически не использую (а пользователи перестали это замечать).

(78)[Создавая автоматизированные рабочие места.]
забавная идея
вместо того, чтобы сделать реквизит в договоре и навесить подписку перед записью выносить ЭТО в отдельный АРМ и гонять через обмен

вместо того, чтобы вести учет собственного ГТД в отдельном Рг выносить его во вне - бред

Помнится я обновлял БП 1.0 на 1.5 в течении 1.5 месяцев

Так что все можно обновить

Только этот уже не совсемм обновление, а разработка аналогичного функционала на новой версии

(78) что подразумевается под АРМ?

(85) автоматизированные рабочие места

(86) Это понятно. Я не понял как они реализуются.

(87) думая это была шутка
[На этом этапе руководство увидело, что все их пожелания, которые реализовывались кучей новых документов в старой УПП, спокойно вписались в стандарт]

(88) Я не шучу.
(87) Реализуется при помощи обработок (чаще одна обработка на все). Изменяется подход к конфигурации. Основным элементом становится не объект конфигурации (документ, справочник), а событие из жизни - "пришел покупатель", "не хватает товарных запасов", "выпустили продукцию" и т.д. Т.е. пользователь оперирует не документами, а событиями, что позволяет существенно упростить работу с стандартной конфигурацией и сократить число ошибок (не всегда удается объяснить пользователю правила заполнения документа ОПрЗС). Естественно АРМ пишется под конкретные бизнес-процессы предприятия.
(81) Никто не запрещает создавать новые объекты конфигурации.
Я думаю никто не будет возражать, что написать можно все что угодно. Вопрос только в умении. Тем более, что это не так уж и сложно если относиться к стандартной конфигурации как к большому объекту, который имеет свои свойства и методы.

(89) Можешь на примере "пришел покупатель" или на любом другом описать как все это будет работать? Все в одной базе? Типовой?

(90) Не, ну подход понятен. Только к теме отношение имеет отдаленное.

(91) Если есть чё по теме - милости просим.

(89) [Реализуется при помощи обработок (чаще одна обработка на все).]
тю
это не решает и 10% учетных задач
ни хранение информации
ни разграничение доступа
ни бизнес-правила

уж тем более не заменяет RLS

(93) Не перечислишь свои 12 колонок?

Реинжениринг бизнес-процессов делает УПП обновляемой всегда.
Только по-разному.

(95) ты намекаешь на приведение всех к типовым бизнес-процессам?

(95) ну да... бизнес, ведущийся 10 лет, должен перестроится, т.к. его отражение не укладывается в конфигурацию УПП, написанную в 2003-2004 году для некого свечного заводика?

(94) примерно 12 :три уровня вложенности, позиция в модуле,объект, тип объект, местонахождение, актуальность, новый, данные, контрол, код, комментарий

с таким сверх избыточным описанием  я с понедельника про четверг за 3 часа в день свою УПП обновил с 1.3.9.1 на 1.3.17.1 и приступил к контрольному тесту

(98) спасибо

100

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

(4) +

Почти всегда необновляемое можно привести к обновлянмому. Поэтому (0) - не правильный сабж.

Делите своё и 1С-кое и всегда сможете обновиться...

(0) Когда понимаешь, что это уже сильно не УПП...

(0) на любом уровне, если основной метод допилов "через задницу и скорее"

(101) Что по твоему мнению "правильное документирование"?

(105) Комментирование кода, регистрация изменений с описанием назначения доработки и логики решения.