Обновление конфигурации на 20+ релизов

ну раз срезать не получится - сидите и обновляйте по 1

нет ты можешь попробовать на свой страх и риск

20 это много...

больше 10 не накатывал

Можно взять последний релиз и допилить его

(0) Можно начать с выбивания бюджета под новое внедрение

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

хотя может половина допилов уже не нужна, а вторая половина реализована в новых версиях типовой

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

ахаха, опытного 1Сника видно сразу: "Вам это не нужно"

(12) мы как то обновлялись(УТ 10.3) на релизов 10. потом месяц всплывали косяки. Пару недель была подготовка к прыжку и все выходные, чтобы это оказалось в боевой.

20 релизов? Мелочи жизни :) "Глаза боятся - руки делают"(цы) За неделю спокойно, без фанатизма, запросто. Обновление конфигурации с изменениями - это же рутинная операция для профи. Всего то двадцать раз повторенная :))

(15) Хотят всё и сразу? Выгрузка/загрузка КД.

(офф)
(17) И мне одного хватит, но за других не ручаюсь.

по одному релизу есть шанс только больше косяков нахватать по дороге

PS: Всё становиться гораздо проще, если есть "полный" CF последнего релиза.

>А сейчас допилили вроде до рабочего состояния, но нужен учет ЗП со всеми изм-ми законодательства и регл. отчетами из коробки.

в хохляндии может проще - у нас такую базу будет штормить каждый квартал от 6ндфл 4фсс и прочего. т.е. обновлять надо "часто". вы и они к этому готовы?

пусть сидят в отдельной базе и не кукарекают

Один вопрос только сколько денег? А остальное накатывайте последовательно...

>если код правится тупо на месте без подписок/переопределения штатных процедур то будет амба

не будет...

есть выгрузка/загрузка модулей

>Всё становиться гораздо проще, если есть "полный" CF последнего релиза.

без него тут вообще делать нех

(0)есть два числа. А и Б. предложи алгоритм обменять значения чисел без привлечения третьей переменной С.
если если алгоритм есть - смело обновляйся сразу на последний релиз.

(15) А разве в УТ есть учет ЗП?

>И что мне это дает?

дважды измененные, йопта

>Там регистры так изменены (расчетов например)

руками галки натыкаете, не рассыпитесь

одни 20 релизов собрались один за одним нахлабучивать

другие последний, но в лоб

страна ты моя дуремария...

(32) точно, проглядела)

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

как то давно тоже надо было бп 1.6 обновить до последнего релиза. просто перенес изменения в последнюю конфу и допилилвал.

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

(38) помню не решился на такой эксперимент с УПП. Тогда 4 релиза обновил. Слышал, что после меня, под ФЗ.275 обновляли УПП на 20 релизов один за другим и ничего.

(40)Слыша такие истории всегда хочется спросить,а кто проверял,что ничего

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

(41) когда там ФЗ.275 вышел? - думаю, уже больше года полёт нормальный. кто проверял? пользователи и программисты. я просто не знаю, чем всё кончилось.

(42)
А, допустим, переливка с одного РС на другой?

Допустим.

(44) Если эта регламентная постобработка обновления, то она выполнится, так как в (35) обновление через все релизы.

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

(46) к (42)

(28) a=a+b

b=a-b
a=a-b
И при при чем здесь обновления?

Возьми и накати cf последнего релиза.
Задрали уже с этими последовательными обновлениями.

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

(0) Ну возьми конфигурацию поставщика и доведи ее до актуального релиза. Потом обновляй не с cfu, а сразу с cf. Только смотри - переименования/удаления реквизитов могут потом не дать заполнить нужные данные.

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

удивительно, что все должны как-то подозревать и подозревать верно, на предмет чего вообще делались изменения/доработки в конфигурации клиента, на которых возник запрет от основы типовой... Ну да ладно... Но удивляет также с чего бы это вдруг, внезапно возникает потребность иметь актуальный конфиг на базе с историей более 3 лет, более 5 лет...

Т.е. сейчас топикстартер мозг сломает "как обновить", затем начнет ломать мозг "как обрезать или свернуть". А можем быть лучше не ломать мозг два раза, в просто развернуть новую базу и перенести в нее и доработки (если они очень нужны до сих пор) и данные об актуальных остатках, да и все?!

(4) Разве? Около сотни - много, например с УТ10.2 до последней УТ10.3. Тут дело не сколько в количестве обновлений, а в количестве внесенных изменений. Возможно их придется полностью переписать.

(46) не наверное, а само собой, по-моему об этом даже упоминать не особо нужно

(41) что смущает?

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

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

(57) Они по-любому отработают последовательно, как и задумывалось. Код посмотри - там за несколько лет обработчики обновления сидят. Исключения - когда происходит двойное переименование или удаление реквизитов - вот здесь желательно запустить обработчики перед принятием изменений. Но после каждого релиза запускать не надо.

" Долгое время не пользовались, потому что внедрили криво. А сейчас допилили вроде до рабочего состояния" - это какое рабочее состояние если обновления вызывают проблемы? Доработки значит кривые. Если конфой не пользовались, то берете последнюю типовую и на нее изменения свои накладываете, но с учетом того, что завтра опять обновлять