Добрый день!
На 24м году работы с 1с внезапно понял, что хочу (хотя бы частично) специализироваться на обновлении сложных нетиповых.
Люблю это дело, и получается, что умею в него достаточно изрядно))
Может ли существовать вообще среди нашего сообщества "рынок" таких услуг?
(Если вдруг у кого-то есть сразу конкретика - обращайтесь:-))

Может ли существовать вообще среди нашего сообщества "рынок" таких услуг
за 24 года не в курсе за рынок ?

Свежая регистрация и первое же сообщение с прицелом на рекламу. Подстраховался от возможных последствий? =)

(0) Муахаха
Это реально смешно

Представь на проекте допиленную ЕРПУХ (+ бесшовка с ДО) релиз дважды догоняли
Каждый раз месяц примерно выделенный спец обновлял (update) пытаясь учесть все доработки
С неоднократным тестированием аналитиками и заказчиком
И все осложнялось что проектные доработки в процессе update на старом релизе вперед убегали и приходилось каким-то местом совмещать доработки и новый релиз

И потом еще месяц-два уже в процессе на проде ошибки всплывали
И командой (2-3 аналитика и столько же разрабов) исправляли как поломанное типовое так и восстановление требуемого доработанного функционала

(0) специализироваться на обновлении сложных нетиповых.
ну, что такое нетиповые, это вроде бы понятно.
ЕРПУХ сюда не катит, она же типовая? Хоть и доработанная, но типовая? Так?
Аналогично всякие УПП и все такое прочее БП УТ и т.д.? Так?

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

(3) Ничего смешного не вижу.
Страшного впрочем тоже.
Брать в работу и делать))
"Законные" типовые объекты, типовые объекты, взятые из других релизов, и объекты, добавленные собственными программистами, отличаются на этапе сравнения/обьединения довольно явственно. Код впрочем тоже, дописки как правило имеют неповторимую, не свойственную для типовых стилистику, даже если программер принципиально не ставит метки..

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

(5) Это к тому что если не в курсе типового и допиленного функционала
Не понимаешь что это и зачем? И спросить некого кто знает
То нифига не сделаешь в разумные сроки и нормально, без кучи ошибок и итераций

(4) В первую очередь конечно допиленные/перепиленные, но не снятые с поддержки 1сные (включая ЕРПУХ) и отраслевые конфигурации.
В качестве отдельного извр... развлечения можно конечно и снятые с поддержки, слепленные из нескольких, частично обновленные и тд
Само собой не самописки, для них обновлений не выпускают))

(6)+ Вот банальный пример в теме
1С ДО 2 - настройка заполнения файла шаблона

В ДО работала вставка таблиц скриптами в режиме предприятия в шаблонах
А потом опс и перестала
И вперед самому (часто в инете ничего нет) разбираться/копаться с отладкой в куче модулей и кода почему перестало работать

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

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

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

(9)
Эмм
Может ты и хочешь но походу не умеешь

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

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

3. Проверяем что работает, если нечто не работает комментим доработки, возвращая по максимуму к типовому

4. Когда база-конфа обновлена до нужного типового и типовой функционал работает - приступаем к восстановлению всех доработок, используя сохраненное/проанализированное в п.1

5. Итерации возможно придется повторять несколько раз и писать свои обработчики
Если некие данные не сохранились или не сконвертировались правильно
Например был один регистра а стало два или наоборот
А доработки с данными не в том регистре что надо

6. Когда все отлажено на тестовых можно писать регламент/процесс обновления для базы прода
Возможно потребуются несколько скачков по релизам с запуском на каждом не только типовых но и своих обработчиков данных

(0) Рынок есть, например: https://1с-ижтиси.рф/автоматизированное_обновление_измененных_конфигураций_1с

(11) Хмм.. Как раз-таки вроде как умею, но пытаюсь упростить))
Я описал случай, когда конфа поставщика в порядке. Если ее отрезали для облегчения - да, это проблемка, и процесс максимально приближается к развернутому варианту из 6 пунктов.
Но насколько вообще часто так делают на практике? Может мне так повезло по жизни, но видел я такое в единичных случаях
Если же она в порядке, то она очень помогает нам по жизни, и на этапе обьединения можно сохранить не только добавленные объекты, но и большинство доработок вообще (меньшинство, которое надо будет потом добавить вручную, к сожалению тоже будет..)

(11) А если конфу поддержки действительно отрезали, то никто же нам не мешает прикрутить ее в копии перед началом процесса?

А ветка согласована? Это все-таки коммерческое предложение.

(0) А очень сильно упиленную УПП до ERP обновите, чтобы вся упилленная функциональность сохранилась?
Или есть попроще: вхлам перекоцанную УТ10 до УТ11 поднять?

(13) (14) Ты предлагаешь в (9) использовать первый "скачок" специально же вставил цитирование в (11)

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

Есть он в базе/конфе или отрезано пофиг
Вопрос только проблемы его добычи, древний релиз типовой нужной версии уже давно хрен достанешь без статуса франча

(16) Начать следовало с "обновить ТиС до УТ11"

"А очень сильно упиленную УПП до ERP обновите, чтобы вся упилленная функциональность сохранилась?"
Примерно год работы проектной команды человек так 10-15.

(18) нету ТиС. Но специально для (0) могу предложить УТ10.2 от 2008 года внедрения

Месяц работы по настройке правил на КД2 и небольшой доработке конечной конфы, правда в УНФ 3 перенос был. Но думаю в УТ11 того же порядка сроки.

(20) И даже ПУБ нету до КА/ЕРП?

(19) ты забыл ещё к этому число указать с 6-7 цифрами.
так я и сам могу, но за год не справимся.

(21) Это ты разогнался про месяц
Там может куча обменов/интеграций на ftp и текстовых файликах своего формата
Все от конкретной ситуации и функционала же зависит

(0) ИжТиСи, залогиньтесь.

(22) у меня вот ощущения такие, что с 7.7 на 8.0/8.1 как-то проще перескакивали что ли. То ли давно уже было, то ли я моложе был...

(23) ну по ценнику я не совсем в теме, но думаю да, миллионов 10+ проект стоит.

(26) Да было сильно проще
Ценники были ниже
И требуемого функционала меньше

(24) ну я про свой проект написал, там месяц заняло, ЭДО штатный заюзали, интеграций других не было. То есть наименьший срок взял.

(17) дык я к тому, что процесс сравнения при обновлении (а не обычном объединении!) УЖЕ трехсторонний:
Основная конфа со старой конфой поставщика
Старая конфа поставщика с новой конфой поставщика
Основная конфа с новой конфой поставщика
Это дает нам много интересных возможностей)) но конфа поставщика для этого таки нужна, да.. (Без нее возни сильно больше)