Скачиваем (https://users.v8.1c.ru) и устанавливаем нужные релизы конфигурации на компьютер в папку по умолчанию.
Не забываем делать бекап рабочей базы.
Все сравнение и объединение я делаю в копи рабочей базы.
Открываем "поддержка" выбираем пункт "обновление конфигурации"
Выбираю пункт искать в tmpits
Выбираю версию релиза на которую буду обновлять. Начинается процесс сравнения…
В результате получаем кучу изменений.
Меняю фильтр на "Показывать только дважды измененные свойства". Объектов становиться в разы меньше. Как правило в эти объекты были внесены "наши изменения"
Начинаем сравнивать изменения. Открываем первый объект и нажимаем"шестеренку"
Сверху выводятся процедуры и функции. Начинаем по одной просматривать их.
1. Если в процедуре только "наши изменения", то снимаем флажок. Эту процедуру не будем обновлять.
2. Если в процедуре только типовые изменения, то такую процедуру оставляем без изменений. С флажком и режим объединения "Взять из новой конфигурации поставщика"
3. Если в процедуре есть "наши изменения" и типовые, то нужно менять режим объединения на:
-Объединять с приоритетом новой конфигурации поставщика
-Объединять с приоритетом основной конфигурации
Выбор зависит каких изменений больше типовых или "наших".
Ниже я выбираю первый режим(На практике я чаще всего выбираю режим "Объединять с приоритетом новой конфигурации поставщика"). Теперь в нижнем экране нужно убрать все закомментированные строчки //MRG (анг. merger — слияние)
Убрать нужно только закоментированный(//MRG) "старый типовой код". Красным отметил те строчки, которые буду удалять.
"Наши изменения" тоже комментируются (//MRG). У этих строчек убираю комментарий (//)
Если бы я выбрал второй способ (Объединять с приоритетом основной конфигурации), то "наши изменения" не были бы закомментированы, но был бы закомментирован новый типовой код.
После того, как все процедуры отредактированы жмем "ок". Теперь "шестеренка" с зеленой галкой.
Типовые "Роли" и "Определяемые типы" Объединить с приоритетом основной конфигурации. Для того чтобы "Наши изменения" не удалились, а добавились новые типовые.
Объединение форм документов и справочников, в которых есть "Наши изменения" приходится делать отдельно (вручную) с таких форм я снимаю галочку объединения.
По этой причине желательно меньше вносить изменения в типовые формы. ( Управляемые формы. Изменение формы списка или формы объекта без внесения изменений в типовые формы )
После того как все объекты проверенны и объединены. Нажимаем кнопку "выполнить".
Конфигурация объединяется и сохраняется. Запуска в предприятии. Проходят процессы обновления.
После этого я сохраняю cf с новым релизом. Таких cf будет несколько, как правило конфигурацию обновляем не так часто и релизы накапливаются. В дальнейшем эти cf буду по очереди загружать в рабочую базу.
После того как cf загружен и база обновлена нужно ее запустить и выполнить в ней обязательные "процедуры обновления". Ход выполнения можно отслеживать встроенной в БСП обработкой "Результаты обновления программы"
Если обработка показывает, что процедуры обновления вообще не запускались, то фоновое задание нужно запустить вручную.
P.S. Чтобы "Наши изменения" не пропали с обновлением их нужно обязательно комментировать.
Чтобы облегчить этот процесс создадим шаблон
выберем новый шаблон
заполним название. Поставим галочку включать в контекстное меню.
Текст шаблона(Автоматически подставит текущее время):
// begin <?»", ДатаВремя, «»> ФИО №
// end <?»", ДатаВремя, «»> ФИО №
При написании кода из контекстного меню выбираем "наш шаблон"
вот спасибо, прям очень удачно ваша статья появилась. Мне как раз предстоит на днях обновлять сильно доработанную ERP на 1 релиз, а практики пока нет.
https://solutions.1c.ru/articles/1037/ (статья Рудакова, хорошо оформлена, но уже старенькая)
https://wiseadvice-it.ru/o-kompanii/blog/articles/1s-obnovlenie-netipovoy-konfiguratsii/ (статья от WiceAdvice, как-то мало в ней информации мне показалось)
Кратко просмотрел, на мой взгляд у вас подробно и грамотно расписано.
Что скажете насчет этих статей:
Вы забыли самое главное — это создание бэкапа перед этим всем. А то сейчас бухгалтера прочитав статью решат что они всё умеют и начнутся вопросы вида: «Всё сломалось после обновления. ПОМОГИТЕ!!!».
А в общем всё подробно описано. Обязательно буду использовать в качестве руководства для начинающих.
(1)
ОГО!!!
(2) Делаю обновление на копии базы. Готовлю cf.
Перед загрузкой в рабочую базу cf. Нужно сделать бекап рабочей базы)
Фоновое задание «Отложенное обновление ИБ» нужно нажимать много раз, пока не отработают все процедуры. Оно после успешного выполнения вообще должно пропасть из списка.
Можно еще добавить информацию о подключении в 1С внешних программ для объединения и сравнения, например Kdiff3. И тогда можно уйти от //MRG
(6)Поддержу, с Kdiff3 значительно проще.
Поддерживаю по KDiff3, 1 раз настроил и экономит 100500 единиц времени на каждое обновление. MRG это прошлый век.
https://wonderland.v8.1c.ru/blog/razvitie-sravneniya-obedineniya-moduley/?sphrase_id=128117
Подробнее:
(4) срочно напишите про то, что нужно делать бэкапы в тексте публикации в самом начале, а то Вам потом никто спасибо не скажет, если у кого то бэкапа не окажется. Либо укажите аидиторию — для кого публикация, что программистам — они хотя бы в большиснтве понимают, что бэкапы надо делать.
(9)написал)
(10)Еще можно дописать, что выгрузка в dt это НЕ бэкап.
я ставлю фильтр показывать отличия основной от старой -тогда показывает объекты, которые меняли только мы
можно Объединять и с приоритетом основной. НО -обычная форма скопирует все элементы форм (такую лучше ручками) , а управляемая добавит только новые элементы форм после этого просто проверить
плохой тон делать или переносить доработки из версию в версию.
Лучше один раз все перенести в расширение и потом править по мелочи
Это все фигня товарищи, скажите что делать если в новом релизе нет той процедуры в которую вы внесли изменение?
(11) А что же это? Чем выгрузка базы не бэкап?
(13) Не все можно перенести в расширения. Да и сам механизм расширения не без глюков.
(14) Если удалили процедуру, то значит изменили логику и надо пересматривать изменения и дорабатывать вновь, хотя возможно просто переименовали или вынесли в общий модуль.
(16) вот и говорю фигня все это, иногда можно начинать разработку заново, после обновления релиза)))
(17) Вообще я придерживаюсь такой логики:
1) Если планируется переписать конфигурацию, то значит обновления не нужны. Все что надо, надо дорабатывать, а не пытаться обновлять.
2) Если же нужны обновления и доработки конфигурации, то делать это внешними обработками и отчетами и независимые подсистемы. Что бы на обновления это не влияло.
3) Избегать конторы которые просят доработать ЗУП и БУХ, потому что им там что то не нравится, за исключением крупных контор, где целый отдел.
(18)
А если работаешь в конторе, где и ЗУП и БП и всё просят доработать? Вопрос риторический, расширения в помощь пришли.
Ну не знаю, я по старинке обновляю, с тремя базами, особенно сильно доработанные
Спасибо за статью, но в статье есть упущения.
Вы я так понимаю не особо сталкивались с очень сильно дописанным конфигурациям, а это значит что не все ваши утверждения верны.
При обновление таких конфигураций есть особенности.
1. Фильтр при обновление ERP не всегда удобен, в этом случае мы не видим какие объекты помечены на удаление и какие удалены (а это частая проблема в ERP). Плюс к этому если вы не пользуетесь системами юнит тестирования то вас ожидает сюрприз в конце вашей работы, например не отработка фоновых обработчиков.
2. Очень часто производится переименование процедур и функций, да что уж там модулей тоже, что при вашем подходе приводит конфигурацию либо к бардоку в модулях со старыми процедурами и функции либо вообще к неработоспособности.
эти ключевые причины мешают использовать описанный вами выше мехнаизм.
Я делаю проще, в процессе обновления я затираю весь код которые был доработан, а потом добиваю его через сравнение объединение, что позволяет как минимум вычистить мусор в модулях, при этом я сразу могу удивить какие модули были помечены, переименованы или удалены. Что оптимизирует процесс обновления и чистоту конфигурации.
А вообще лучше всего побывать автоматизировать данные моменты, т.к. на обновление не типовых конфигураций может уходить до 24 часов просто переноса кода.
Отсюда резюме: ваш описанный метод можно применять, на обычных формах, которые по сути сейчас статичны и максимум на БП и РТ остальные же конфигурации к сожалению подвержены достаточно большим изменениям и ваш описанный метод может подходить не всегда.
(13)Стоит заметить что при больших объемах данных, расширения работают медленнее дописанного аналогичного кода на 40% а внешние обработки 80%
так что использование расширений не всегда оптимально с точки зрения производительности.
(21) а что конкретно можно автоматизировать для уменьшения времени работ по обновлению, у вас есть какие-то наработки?
(23) ну пример привели выше KDiff3, не плохой инструмент.
Не читал всё (признаю — нее горжусь этим), но замеченное отмечу:
Нужно добавить вариант — обновление расширений.
(т.е. — когда изменения, сделаны в расширениях)
(22) Откуда такие данные?
(19) Для начала объяснить, что доработанную конфигурацию будет проблематично обновлять и с каждой новой доработкой все проблематичнее. Если руководство и глав бух разумные, то откажутся сразу, так как об оперативном обновление можно забыть.
Также можно обсудить и прийти к решению, когда можно обойтись без доработок. Вариант, что там проводки не так формируются не обсуждаются. Надо показать что не так делают.
У нас пытались предложить подправить, после нескольких бесед с руководством, отказались от этой идеи, как не разумной.
И да, по-любому — полного автоматизма, не будет никогда (и — нигде, практически. Автопилот — здесь не применим).
Всегда необходимо — тщательно обновлять.
Это включает:
1. Бекапы — сделать.
2. Анализ изменений.
(которые были + которые в типовой прошли)
3. Накат обновы.
(написано кратко — в реальности, это ХХХХХХХХХХХХХХХХХХХ времени может занять. Зависит от объёма работ и мощности ПК и сервера 1с)
4. Тестирование.
(в идеале — все участки/пользователи — сами проверят.
В реальности — это далеко не всегда так)
Далее — возврат к п. 3 (или даже 2) или Завершение (бекап — хранить долго!).
(21)
лет 5 назад была рекламная рассылка какой-то программы ижевской франи которая сама обновляет измененные конфигурации, причем она вроде даже прошла сертификацию 1Са. Отзывов не слышал, сам не пользовался. Вот интересно узнать может кто ее юзал 🙂
(26)
Прослушайте курс Богачева по Эксперту, он там это разбирает.
Да и если вы сами немного понимаете в принципах работы 1С то должны понимать что расширение это не скомпилированный код, который компилируется когда он нужен, отсюда и падение производительности.
(15)
(15)
Выдержка из документации на платформу.
Текущую информационную базу данных можно сохранить в файл на диске. Для сохранения данных в файл нужно выбрать пункт Администрирование ‑ Выгрузить информационную базу данных в файл. На экран выводится стандартный диалог выбора файла. Следует выбрать каталог и указать имя файла, в который будут записаны данные.
Механизм выгрузки предназначен:
● для получения образа информационной базы независимо от способа хранения данных;
● для переноса информационной базы из одной СУБД (или файлового варианта) в другую СУБД (или в файловый вариант).
Перед выполнением выгрузки информационной базы рекомендуется выполнить процедуру тестирования (средствами конфигуратора или отдельной утилиты) и исправить все обнаруженные проблемы.
Не рекомендуется использовать данный способ для создания резервной копии информационной базы по следующим причинам:
● может возникнуть ситуация, при которой файл выгрузки будет невозможно загрузить, если в информационной базе, из которой производилась выгрузка, существовали ошибки;
● длительное время создания;
● необходимость монопольного доступа к базе данных;
● высокие требования к оперативной памяти.
ПРИМЕЧАНИЕ. Работа информационной базы в монопольном режиме не переводит базу данных MS SQL в однопользовательский режим (single user).
Показать
Там же, на ИТС, в разделе БП.
(28) Мне почему то не зашла, косячила нещадно год — полтора назад. А именно снимала конфигурацию с поддержки и приводила ее в режим обновления только через Ижтиси, но это касаемо ERP под остальные конфигурации думаю зайдет нормально.
(17) ровно такой же вопрос у меня в голове, когда я вижу, что условным стажерам дают задачи по обновлению конфигураций, т.к. это считается «простой» работой. Как стажер может грамотно обновить ERP, если есть дважды измененные объекты и изменилась сама логика.
А разве не безопаснее обновлять не на готовый cf, а на cfu, но с подготовленными настройками объединения конфигураций?
А ещё вы не учли тот нюанс удаляемых процедур и функций поставщиком. Их нужно удалять только в том случае, что на них сторонний разработчик не делал ссылок в модулях (например на общие модули). А если их не удалять — то они будут хламиться.
(20) это как 7.7 обновляли?
(28) 1С-ИжТиСи. Их купила сама 1С несколько лет назад.
Прямо сейчас мы с ними подписываем договор на обслуживанием, чтобы они обновляли нашу допиленную ЗУП. Мне самому интересно, что из этого выйдет.
(33) Поддерживаю. Там много аспектов, которые нужно учесть. Ещё в этом объединении мы не сможем увидеть механизм объединения RLS, если они менялись.
(11)А в клиент-серверном варианте существует другой бэкап?
(37)Средствами СУБД.
Иначе существует вероятность, что dt может просто не загрузиться.
Вряд ли же есть привычка загружать выгруженный dt, чтобы проверить, что он загружается.
Спасибо добрый человек )) кое-что упускал. Как раз этой осенью БИТ много изменений внес в мою конфу, осталось еще один релиз сделать, завтра сяду с учетом новых знаний.
(2)ну бэкап вообще перед любым действием с конфой делаешь, эт азбука ж.
(31)
Средства СУБД как правило у админа, это надо согласовывать, а ДТ-ку выгрузить без проблем, выкинуть пользователей ночью можно.
Перед выполнением выгрузки информационной базы рекомендуется выполнить процедуру тестирования
хм. а я обратное читал, что надо перед тестированием выгрузку сделать ))
Хотя логика понятна.
(38)
Вряд ли же есть привычка загружать выгруженный dt, чтобы проверить, ч
Ну у нас например можно потом если полный ахтунг у админа поднять SQL на любой момент времени, но самому там ковыряться что-то не айс.
(28)
тоже не слышал, но общался с франчами, которые писали подобное, может и они, не знаю, они полностью процесс не автоматизировали все равно. Частично и потом программист проверяет. Вообще не представляю, как можно автоматизировать обновление сильно доработанной конфы. У меня вот этой осенью такая БИТовская «поехала», БИТ начал удалять реквизиты, которые критично участвуют во всех доработанных (им же) отчетах, формах. Боюсь как бы не пришлось заново писать вообще. На третьем релизе только в одной форме до 40 новых функций появилось, первые два уже осилил. Сижу вот кумекаю ))
Полезная статья. На этой неделе делал обновление жутко переписанной УТП.
НО. Выполнить требования заказчика можно не изменяя модули и формы. Я так работаю уже 10 лет на УПП. И скажите, что это не возможно.
дополню статью вебинаром о возможностях трехстороннего сравнения в конфигураторе
(31)
Документация написана для юристов. Чтобы потом не попасть на иски. На самом деле (сугубо ИМХО) выгрузка в dt (ОБЯЗАТЕЛЬНО с последующей загрузкой из dt в копию) — это и есть единственный гарантированный бекап. Если делать копию средствами SQL, то все ошибки в базе просто скопируются, и копии будут сбойные. А потом база окончательно гавкнется, вот тут то и обнаружится, что копии не годятся :(. А уж если база из dt загрузилась, то критичных ошибок там нет, только битые ссылки максимум.
(13) Зубры обновлений ИжТиСи говорят, что обновлять нужно не расширениями, и я им верю.
Почему:
1. Если режим вызова «после» или «перед» — то и в коде их переносить никакой проблемы не вызывает
2. Если режим «Вместо» — то в коде ты увидишь, что логику исправляемой функции поменяли, а расширение будет работать как ни в чем не бывало, и если особенно не повезет, то не будет, например заполнять новый реквизит, что приведет к левым движениям.
3. Изменения в формах единственное слегка оправданное место, но и с этим как повезет — форму перекосило, а ты даже сравнить не можешь, чисто веселая игра «найди 2 отличия»
ИМХО рсширения оправданы для:
1. Конфа все еще на замке — расширение дает до 2 часов экономии на принятии изменений. Загрузка конфы поставщика по сравнению со сравнением/объединением.
2. Командный интерфейс
3. «динамическое обновление» — потом все убрать в конфу
4. иногда формы, но проще в поддержке — мелочи делать кодом, а крупные переделки — рисовать свою форму
(13), если бы они еще работали стабильно, то им бы цены не было. А когда клиент теряет информацию из-за «глюка», то они никому не нужны.
(47), если менять формы программным способом:
— формы никогда уже не перекосит;
— не нужно играть ни в какие игры.
Статья полезна новичкам, Обсуждение — очередной холивар на тему расширений…. Использую расширения как на «замках», так и на дописанных, в том числе существенно. Ни разу никто не жаловался на потерянные данные. Кстати последние релизы уже умеют контролировать «Вместо», правда мне такой контроль пока не попадался.
(51) все гораздо проще, сейчас я сменил место работы, на предыдущем у нас было разделение труда и работы такого типа доставались другому программисту, хотя в теории процесс я себе хорошо представляю. Ну а на новом месте с ходу появилась задача по обновлению и поручить особо некому, да и мне хочется попрактиковаться 🙂
(53) отвечать не буду, скажу лишь, что таких предприятий не так уж мало на самом деле. Это те кому оказалось мало УПП, в свое время перешли на ERP, но привычка дорабатывать под себя осталась. Тут у вас появится законный вопрос, а как же расширения? Отвечу, что почти никак, они еще слишком сырые и подходят для самых примитивных доработок.
(53) Как правило это заводы. Каждое такое предприятие уникально, поэтому и допиливать приходится под нужны конкретного предприятия.
(55) «они еще слишком сырые и подходят для самых примитивных доработок». Я бы подискутировал на эту тему. Сейчас КА2 типовую внедряю, до этого участвовал в ERP внедрении.Процессы выстраиваем по типовому функционалу. Приходится убеждать, что типовой функционал он достаточно удобен. Сначала это отрицание вызывает, потом гнев, потом апатию, смирение и принятие. Хотя да, в режиме совместимости расширения еще не полностью раскрыли свой функционал в типовых решениях. Но глобально что-то менять, чтобы потом кукху надрывать при обновлении. Не не не. Я уж лучше отдельную подсистему сделаю с документами, регистрами, подписками на события, блэкджеком и плюхами, чтобы при сравнении/объединении не зацепило типовой функционал.
(56)Мало того, каждое предприятие уникально в пределах определенного промежутка времени. В меняющейся реальности нужно гибко подстраиваться под события. Если брать и переписывать «на живую» то очень трудозатратно потом это всё поддерживать, о чем и написал уважаемый Сергей. Кстати статьи WiSeAdvice иногда более информативны чем ИТС. (не реклама, просто респект ребятам/конкурентам)
(47)»Зубры обновлений ИжТиСи говорят, что обновлять нужно не расширениями, и я им верю.»
Как обновлять расширениями? Мне такой способ не известен.
Расширениями, кстати, сами 1с теперь патчат типовые конфы, устраняя свои же косяки. Вполне рабочий вариант.
Вообще расширения оправданы везде, где они помогают. Где мешают, там не оправданы. Всё просто.
(1) WiSeAdvice конечно же, извиняюсь за опечатку
(46) Загруженный dt не гарантия отсутствия критических ошибок, надо еще проверить что все работает и нет критических ошибок.
База может запускаться, но при попытке открыть список документов или какой нить документ, может вылететь с ошибкой.
Но такие ошибки как правило отлавливаются уже на рабочей базе.
(58)
Да все ХАОС. Но сути это не меняет. Существуют предприятия или группы предприятий в рамках корпораций, которым выгоднее держать свой штат разрабов, что бы поддерживать сильно допиленные ЗУПы, ERPы, УХи, Документообороты и т.п. Это нередкое явление и это себя оправдывает (vs. франчелыжные внедрения и поддержка). Каждому свой подход и ave WiSeAdvice.
(59) Да, не обновлять, а дорабатывать. Что-то у меня рука дрогнула.
Патчить — можно.Но патч живет до первой возможности убрать все в конфигурацию, на то он и патч. В случае разработки на живой базе это п 3. моего списка
(50) Тут не всё так однозначно, в платформе 8.3.15.1700 аннотация &ИзменениеИКонтроль работает некорректно, такие расширения постоянно слетают при обращении к заимствованной функции с сообщением, что функция была изменена. Я так понял, что ни до ни после директив #Вставка и #КонецВставки не должно быть ни одного байта лишнего. Я Hex-редактором это дело проверял, тогда заработало. Но пока технология сырая.
Обновление за один проход в сильно доработанных типовых конфигурациях прямой путь к ошибкам либо путь к дикому усложнению процесса обновления. Если в измененной конфигурации в каком-то модуле десяток вновь созданных процедур, десяток измененных процедур и в этом модуле делаются изменения в нескольких измененных процедур — не проскочите за раз, как бы не хотелось. Придется внимательно смотреть на логику. (с учетом разных потенциальных граблей — например была процедура Расчет() в которой были ваши изменения, а с нового года добавили процедуру Расчет2020() — не отследили и получите веселую жизнь).
Отдельная песня про измененные обычные формы — насколько помню, автоматически никогда корректно не менялось, приходилось все ручками.
Плюс при сравнении/объединении конфигураций не всегда корректно отображается цветовая палитра объектов (смотретьhttp://forum.infostart.ru/forum105/topic221980/message2272574/#message2272574 — первая картинка — разница типовой конфигурации, вторая и третья — общий модуль некорректно отображается цветом при установке/снятии галочки, четвертая картинка — некорректно отображается цветом измененный документ). Почему получилось так — сказать не могу, до меня эта конфигурация обновлялась двумя разными людьми, а может при обновлении что-то не так было.
Поэтому в сильно измененной конфигурации лично я обновлялся за два-три прохода. Сначала не измененные и немного измененные объекты, потом — сложнота.
(14) а что ты делаешь если процедуры на которую ты белыми нитками присобачил усовершенствование не стало в очередной версии?
просто добавь в свой чек-лист кроме тестирования правок конфигурации тестирование своих расширений.
в любом случае ты ДОЛЖЕН документировать свои доработки , в том числе свое представление о функциональной структуре изменяемого чужого приложения.
(35)
:
интересный опыт.
1. кто вам допилил зуп, не ваши сотрудники? зуп 3.хх?
2. в каком объеме? кол-во новых объектов, кол-во новых реквизитов типовых объектов, кол-во измененных процедур,
кол-во измененных форм,кол-во измененных макетов(скд в т.ч.) и т.п., просто порядок величин 1,10,100…
3. как происходит передача изменений? ведь не зная что для чего делалось можно вместо рукавов ширинку пришить 🙂
4. стоимость обслуживания меньше ставки 1с-ника средней квалификации?
(67)
1. ЗУП 3.1.10, пилил франч и потом я, когда сюда устроился (в этом году). Франч изосрал всю конфигурацию, внеся изменения куда можно и куда нельзя.
2. Порядка 100 изменений плюс-минус. Есть изменения в т.ч. в расчетной части — свой алгоритм доплаты до оклада по больничному листу. Есть доработки в части НДФЛ. Но основное — это измененные формы. У меня были мысли, как изменения в формах минимизировать, вынеся с модули и генерируя элементы кодом, но на это просто нет времени.
3. а вот это мне самому интересно. Из-за того что у нас очень долгое подписание договоров в компании — на практике не проверял. Типа, мы даем cf, а они возвращают cf актуального релиза с перенесенными изменениями.
4.
Нам оценили год обслуживания в 45 т.р. Т.к. у них это на 80% автоматизировано, я надеюсь, что качество будет выше, чем ручное обновление. Критичный функционал они допроверяют руками.
Я программист в одном лице, мне заниматься обновлениями уже в лом, честно говоря. Могу, но если это можно не делать — пусть делают они. Компания мое мнение поддерживает — что рутину надо скидывать на сторону.
(55) бывает не только привычка дописывать под себя, а отраслевая необходимость. тоже имеем сильно дописанную ERP. Расширения используем только для экстренных исправлений. Расширения не «зашли» по причине трудоемкости контроля расширяемых форм, процедур, а также «великолепного» решения при добавление в расширении объектов меняется структура БД, которая используется для интерграций с дургими системами учета
(68)
и
+
— выглядит как бомба
Добавлю к статье, что стандартном обновлении конфигурации есть возможность объединения модулей наполовину вручную в режиме «Взять из новой конфигурации поставщика». Это сильно ускоряет процесс, если наших изменений гораздо меньше, чем у поставщика. При этом бежим по тексту синими стрелками, видим, где были вставлены наши куски кода, и просто копируем эти строки из средней левой таблицы в нижнюю. Такой режим подойдет, даже если поставщиком были частично переименованы процедуры и функции модулей, Только при этом необходимо удалить старые процедуры и функции (проставить галочки вручную) и вручную из них перенести наши изменения в новые процедуры и функции.
Похоже у вас скриншот неправильный к этому примеру. В тексте идет речь про объединение с приоритетом основной конфигурации, а на скрине стоит режим «Объединение с приоритетом новой конфигурации поставщика» и в окне объединения видно, что комментируется наш код из основной конфигурации.
(8) программа kdiff3 понравилась, экономит время неплохо (конфликты решаются не прикасаясь к мышке, горячими клавишами).
К сожалению, поймал баг:
1) какой нибудь модуль объединить с помощью внешней программы (kdiff3), появится зеленая галка.
2) затем через правую кнопку мыши выбрать на этом же модуле «Показать различия в модуля…» и выйти из kdiff3, не сохраняя изменения
3) снова зайти в шестеренку с зеленой галкой, чтобы посмотреть результаты объединения
итог: 1с валится с критической ошибкой без возможности сохранить результаты объединения. Для больших конфигураций это может вылиться в большую потерю времени.
(32)
Этом механизм нестабильный: нет никакой гарантии, что сохраненные настройки объединения при их восстановлении восстанавливаются в то же самое состояние, что и при сохранении.
(30) Добрый день, Руслан! Разрешите, поясню эту ситуацию.
Да, технология автоматизированного обновления от «1С-ИжТиСи» по умолчанию подразумевает снятие с поддержки. Но заказчик всегда может попросить вернуть объекты на поддержку в обновленной конфигурации. Большей части наших клиентов отсутствие поддержки не мешает, но критичны сроки обновления. Тем же компаниям, которым поддержка критична — мы «замочки» возвращаем. Возможно, где-то случилось недопонимание.
(3) и что? хватит эту белиберду писать, что если нет опыта то не должен этим заниматься. Да без проблем, раз 10 не правильно сделает и потом пойдет без ошибок, ну со всеми так было. Как же ты получишь опыт если не возьмешься за такую работу?! Давай не будет говорить о поетапно нужно начинать. Достали такие как ты и ниже следометатели, которые оставляют тут «что это за предприятие» и т.д..
Есть замечания — пиши, нет — молчи.
Лишь бы наследить.