Конфа УТ10.3+CRM 1.1старого релиза. Дописанная и переписанная вдоль и поперёк. Есть только оригинал текущего релиза и cf последнего релиза. Между ними порядка 20ти обновлений. Можно найти и промежуточные релизы (не все), но обновлять всё равно будет сложно, ибо база очень сильно переделанная. Нужен совет как обновиться до последнего релиза?

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

Как бы вы поступили на моём месте? Понятно, что лучше обновлять релиз за релизом, но на это уйдёт уйма времени - столько времени мне никто не выделит на работе.

(0) Если тебе на работу не выделяют время, я думаю не стоит за нее браться :)

(0) Для начала определись - а надо ли вообще ее обновлять?
Ведь это же не бухия.

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

(1)время выделяют 2  месяца без отрыва от производства. но не столько, сколько потребуется на обновление..
(2)надо. В новых релизах интеграция с Софтфон есть, выгрузки с бухгалтерию 2.0 и другие навороты. Надо обновляться.

(3)да я хоть постепенно согласен.  Главное правильный подход выбрать. Ну и ядро изнутри буду знать пока обновляю один за другим объекты.

(0) Обновление за деньги не рассматривается ?

(6)заранее трудоемкость нереально определить. там слишком много доработок. на предпроектное исследование только и на поиск релизов специалист потратит не менее недели.

(0) А не обязательно на все релизы обновлять. В каждом сказано - с каких можно. Это будет сокращение номер раз.
А доработки - сохрани. Те, что на данные не влияют - их в самом конце. Те, что влияют - объединение на самом деле бережно к данных относится.

Посмотри измнения в релизах, если 20 пропущено - это середина 2010 года, торговля 10.3 за это время не сильно свою структуру поменяла. Можешь сразу на последний.

не понимаю как смысл обновлять УТ. Обмен с бух? Так проще правила поправить. Корректировочные счет-фактуры? Проще только их перенести. Новая ТНН? подключаем как внеш.

(10) на самом деле прав, если сильно переписана, то смысла нет, тем более, что бух 2.0 должна уже отжить свое.
Лучше с нового года на 3.0 делай.

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

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

(11) Почему Бухия 2.0 "должна отжить"? Достаточно стабильная и работоспособная. Гоняться за новинками ради новинок?

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

Заодно можно сделать свертку базы

кстати да, обычно УТ не обновляют и дописывают все что надо

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

(7) ты сильно загибаешь, за неделю вполне обновляемо....

технология такая

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

я проходил 20 основных релизов за 4 дня

(0) Обновил бы все, потом бы внес все изменения.

(11) письмо 1с всем рассылало. Так же, как 1.6 была вполне рабочей и стабильной.

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

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

(0) Вопрос номер раз: какова цель?

+17 в некоторых случаях, когда доработки не касались рабочих метаданных (изменение размеров реквизитов типовых документов и т.п.), а делалось только добавлением новых сущностей, то схема может быть:
1. При первом обновлении на типовой релиз (либо при сравнении с типовым релизом базы) определяется список данных, которые могут потеряться (новые документы, РН, справочники и т.п.).
2. Эти данные выгружаются (хоть универсальной загрузкой выгрузкой)
3. Обновление идет типовыми релизамси до нужного
4. В последний типовой релиз вносишь свои доработки.
5. В последний типовой релиз со своими обработками загружаешь данные из пункта 2.

P.S. Кстати, при обновлении полезно будет еще провести аудит доработок. Иногда (или часто :) оказывается, что доработки уже реализованы стандартным функционалом полседнего релиза, либо стали неактуальными.

(0) Обновляться последовательно
Работодателю мягко объяснить, что только так и не иначе. И что незачем было так затягивать.

Кстати, еще вариант - создать базу на новом релизе с необходимыми доработками.
Перенести данные. Работоспособно, если данных немного.
Но придется переносить и движения, во избежание.

Стратегия примерно такая:
1. Готовишь последний релиз - переносишь все доработки.
2. Анализируешь добавленные/измененные реквизиты между релизами.
3. Анализируешь обработки обновления.
4. Пробуешь добавить новые реквизиты в текущий релиз, засекаешь время. Если по времени критично, то стараешься разбить на интервалы.
5. Пробуешь запустить обработки обновления, засекаешь время, разбиваешь на интервалы.
После п.4,п.5 имеешь представление, сколько времени потребуется для обновления конфиги.
6. Накатываешь реквизиты в рабочую БД
7. Запускаешь обработки обновления на рабочей БД.
8. Накатываешь последний релиз в рабочую БД.
Обновлял по такой схеме заводик, который работал в режиме почти 27/7. Иногда были окна в пару часов. И там релизов пропущено было поболе.

+24 и работает только если между релизами не было изменения данных

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

(27) ага....

релиз 1 - есть регистр "Расчет"
релиз 24 - регистр "Расчет" переименован в "УдалитьРасчет" и выполнен перенос в новый регистр "РасчетК"
релиз 32 - регистр "УдалитьРасчет" удален
Релиз 43 - текущий....

по твоей схеме при обновления с 1 на 43 релиз ты потеряешь все данные в "Расчет", и регистр "РасчетК" останется пустым....

)928) Если регистр щтатный то при обновлении это продумано, если нет, то обновление его не тронет.

(28) +1
не катит вариант (27)
верный ответ в (25)

(29) регистр штатный, а грохнится по тому что НЕЛЬЗЯ накатывать релизы без запуска в режиме предприятия...

(31) А ну да я о том же что все надо последдовательно обновлять.

(29) ты УПП-ху то хоть раз обновлял ?

(33) Обновлял.

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

(35) ты сказал "ключевые" релизы, применив термин ни как не связанный с изменением архитектуры системы

(17)но там очень много доработок. очень много. при том код сидит в в модулях объектов и в модулях формы.

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

(12)понравился вариант!

(0) Обратитесь в ИжтиСи и не парьтесь. Будет и быстрее и качественнее - баннер их сверху болтается...