В этой инструкции нетипового обновления измененной 1с 8.3 я не буду описывать базовые вещи, такие как: как открыть конфигуратор, что такое конфигурация БД, конфигурация поставщика и основная конфигурация. Об это и там много написано, и вы можете самостоятельно найти эту информацию на просторах интернета. Я постараюсь описать основные моменты процесса обновления и на что нужно обратить внимание.
Я взял для примера нетиповую бухгалтерию 3.0.51.22 и покажу как обновить ее до версии 3.0.53.29. На платформе версии 8.3.10.2561 (нет большой разницы на более старых платформах, просто раньше окошко сравнения выглядело чуть иначе).
Скажу сразу, будет много картинок и мало текста. Я считаю, что визуально проще запоминать процесс, чем читать море текста.

1. Проверить соответствие конфигурации БД и конфигурации поставщика.

Для этого вам нужно

При совпадении можете смело переходить к пункту 2.

1а. Постановка конфигурации на поддержку.

Если у вас отличаются версия БД и версия конфигурации поставщика, то вам нужно удалить текущую конфигурацию все через то же меню: конфигурация – поддержка – настройка поддержки. И нажать кнопку «Снять с поддержки».

После «недолгого» ожидания снимаем все галочки. Ну и можно убрать галку «Сохранять настройки автоматически». И жмем выполнить.

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

2. Обновление базы.

Теперь можно переходить к обновлению.

Скажу сразу обновление делать нужно ТОЛЬКО через меню «Конфигурация» - «Поддержка» - «Обновить конфигурацию…».
Использовать «Сравнить, объединить с конфигурацией из файла…» НЕЛЬЗЯ!!! При использовании этого механизма вам при следующем обновлении придется переходить к пункту 1а. Поэтому давайте не будем так делать и создавать себе (или тому, кто будет в следующий раз обновлять базу) лишние проблемы.

Далее выбираем файл обновления.
Хотелось бы сказать про обновление через несколько релизов. 1С не рекомендует обновлять на CF файлы, сразу прыгая через несколько релизов. Это нужно делать последовательно. В теории это правильно.
Объясню почему так не рекомендуют делать. Если программисты хотят удалить какой-либо реквизит, то они сначала приписывают к нему приставку «удалить», потом через несколько релизов удаляют его. И могут в каком то релизе перенести из него информацию. Вот пропуская этот релиз, вы можете потерять данные. Но на практике за свои уже лет 10 работы с базами 1с у меня был такой один случай. Когда почему-то разработчики решили перенести данные с перечисления на справочник. При том ничем критичным это для меня не закончилось. Я написал простую обработку, которая перекинула эти данные из архива в текущую базу. Никакого повторного обновления делать не пришлось.
Можете кидать в меня камни, но я всегда обновляю базу через cf файлы на несколько релизов.
Итак мы нажали обновление, нам выскочило сообщение с какой на какую версию будет произведено обновление. Мы нажимаем ОК.

Ожидаем, пока пройдет сравнение объектов.
Далее нам нужно внизу из списка выбрать пункт «показывать только дважды измененные свойства.

Так же хочу сказать по старые версии, раньше это был флажок.

Итак, мы теперь видим гораздо меньше объектов.

Если у вас пусто, то вам несказанно повезло, и вы можете смело нажимать кнопку «выполнить» и считайте обновление закончено. Ну у нас не все так просто, поэтому пробегусь по основным объектам.

Первое что хочется сказать. Ни в коем случае не переключайте режим объединения. Он должен стоять «Взять из новой конфигурации поставщика». Иначе вы получите в базе мусор с комментарием MGR.
Никаких кнопок «показать различия в модулях…» !
Жмем именно на значок шестеренки рядом с модулем

Открывается окошко, в котором очень много изменений в функциях и процедурах.

Для того чтобы понять в какой функции были изменения нам нужно будет либо взять копию базы, либо через меню конфигурация сохранить конфигурацию в файл. И дальше загрузить в пустую базу. Далее зайти в меню «конфигурация» и нажать «Сравнить конфигурации…»
Выбрать сравнение основной конфигурации с конфигурацией поставщика.

И вот ту можно уже посмотреть изменения через «показать различия в модулях…». Т.к. мы не собираемся ничего менять, мы только хотим посмотреть, что было изменено.

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

Вернемся к обновляемой конфигурации. Там мы через значок шестеренки зашли с режим объединения модулей. Далее ставим все галки…вручную..говоря про себя «спасибо» разработчикам платформы:)

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

Копируем его из верхнего окна и вставляем в нижнее окно.

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

Отлично. Теперь пробежавшись по всем объектам можно снять галку «сохранять настройку автоматически» и потом «выполнить»

На сообщение «Существуют объекты, измененные в основной конфигурации по отношению к старой конфигурации….. При обновлении будет выполнено замещение этих объектов! Выполнить?» Нажимаем смело ДА.

В следующем окне оставляем галки, как показано на картинке. И никак иначе!!! Должны стоять обе галки – «объекты редактируются с сохранением поддержки». Нажимаем ОК.

Все. Обновление нетиповой конфигурации 1с завершено.
Этот метод не претендует на идеал, но я думаю, многие совершают ошибки в этих шагах.
Конечно, я рассказал не все, тут еще много подводных камней. Но я думаю 90% обновлений можно смело обновлять по этой инструкции.

Нетиповая конфигурация 1С, это когда: 1) конфигурация 1С написана с нуля самостоятельно программистом, 2)конфигурация 1С была типовой, но в нее добавили изменения, даже если добавили один реквизит.

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

Для того, чтобы внести любые изменения в типовую конфигурацию 1С, необходимо разблокировать изменение типовой конфигурации 1С, а в некоторых случаях «снять ее с поддержки».

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

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

Существует 2 варианта обновления: а) Обновление 1С через поддержку (вызов через диалог Конфигурация/Поддержка/Обновить конфигурацию) и б) через Сравнение объединение с конфигурацией из файла. Следует обратить особое внимание, что разница между этими двумя пунктами в том, что в первом случае обновляется и основная конфигурация и конфигурация поставщика, а при сравнении объединении конфигураций обновляется только основная конфигурация, конфигурация поставщика остается старой. Таким образом наиболее рекомендуемым вариантом является обновление через Обновить конфигурацию. Для обновления через Поддержку конфигурации используются файлы поставки поставщика CF или CFU, которые можно найти поиском, в каталоге шаблонов, указав путь в Интернете, или напрямую указать путь к нужному файлу на жестком диске.

При обновлении конфигурации 1С без возможности внесения изменений обновление после выбора файла обновления происходит в автоматическом режиме, если в конфигурации включена возможность внесения изменений, тогда после выбора файла обновления будет выведено окно сравнения конфигураций. В этом диалоге мы можем увидеть как система предлагает нам обновить нашу нетиповую конфигурацию 1С. В нижней части диалогового окна расположена соответствующая легенда по статусам объектов: "Статусы по соответствиям объектов" обозначают сравнение "Основной конфигурации" и "Новой конфигурации", "Статусы по истории объектов" обозначают сравнение объектов конфигураций с объектами "Старой конфигурации поставщика".

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

Итак, в результате получится список объектов, дважды измененных при доработке типовой конфигурации и в новой конфигурации поставщика. Если согласиться с обновлением, то сделанные ранее доработки в этих объектах будут утеряны. Поэтому по каждому объекту необходимо принять решение о том, каким образом он будет обновлен. На этом этапе следует выполнить предварительное сравнение исключительно для того, чтобы уменьшить объем работ в дальнейшем. Оценка не точная быстрая - "на глазок". Если изменений в объекте больше в новой конфигурации поставщика, то оставляем экземпляр объекта поставщика. Оставляем галочку. Потом нужно будет перенести изменения из рабочей конфигурации. Если изменений в объекте больше в рабочей конфигурации, то оставляем экземпляр объекта рабочей конфигурации. Снимаем галочку. Затем нужно будет перенести изменения из конфигурации поставщика. С модулями можно поступить немного иначе, т.к. есть возможность сравнивать модули попроцедурно.

Т.е. в случае, если в нашей конфигурации 1С и в конфигурации поставщика изменены различные процедуры модуля, то, правильно расставив, галочки мы избавим себя от ручного переноса изменений кода. Чтобы до этого добраться, необходимо нажать кнопку в виде лупы рядом с названием режима объединения модулей:

При выводе меню действий по объекту (например нажатием правой кнопки мыши) мы можем вызвать отчет о сравнении объектов.

Чтобы подтвердить проведенное обновление 1С - нужно выбрать пункт меню Конфигурация/Обновить конфигурацию базы данных.

Чтобы отказаться от обновления 1С – нужно выбрать пункт меню Конфигурация/Вернуться к конфигурации БД.

Несколько правил, которые упрощают будущее обновление конфигураций 1С:

Основное правило обновления 1С: нужно добавлять новые объекты, т.к. при обновлении новые объекты системой не затрагиваются

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

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

Использование типового функционала конфигураций

Программное создание элементов формы (В событии ПриСозданииФормыНаСервере)

Спасибо!

Инструкций по обновлению изменённых типовых конфигураций платформы 1С - очень много. Поэтому, чтобы не увеличивать сущности, не буду полностью описывать весь процесс. К тому же - предполагается, что этот текст для человека, который уже обновлял изменённые конфигурации и знает основные моменты и "подводные камни". Данный метод лишь упрощает этот процесс, по сути предлагая использовать автоматизированное сравнение изменений конфигурации и внесения изменений в модулях на уровне сравнения текстовых файлов. При таком подходе, сильно уменьшается вероятность ошибок ("затирание" обновлением важных изменений из-за невнимательности), связанных с "человеческим фактором".

ЛЮБОЕ обновление конфигурации начинается с выгрузки ИБ. Это "золотое правило", это надо помнить всегда, это надо делать при любом методе (даже если там про это забыли сказать). Далее, можно пойти двумя способами: либо обновлять в тестовой базе, либо обновлять в рабочей базе. Тут важный момент в следующем: обычно изменённые конфигурации обновляют не на каждый релиз (как это можно легко делать с типовыми), а сразу на несколько, поскольку этот процесс трудозатратный. В первом способе (обновлять на тестовой базе) - предполагается итоговый перенос обновления на рабочую базу через загрузку cf-файла. В этом случае могут произойти ошибки, связанные с удалёнными реквизитами (об этом можно найти множество статей). Стало быть - есть некоторые риски, но зато во время обновления (которое может занять целый день и даже дольше), пользователи могут спокойно работать, изменяя базу данных. Во-втором способе (обновлять на рабочей базе) - эти риски исключены, но на всё время обновления ключевые пользователи не смогут работать в этой базе. В форумах есть достаточно обсуждений, какой метод чем хорош и стоит-ли переносить обновление через файл конфигурации. Могу лишь сказать: исходя из опыта работы по первому способу, подобных ошибок не случалось при загрузке cf-файла. В любом случае - по бэкапу можно восстановить базу. Здесь будет рассматриваться именно первый способ, но на суть метода это не влияет и при желании можно действовать по второму способу, используя предложенный метод.

Итак - развернув тестовую базу по свежему бэкапу, производим последовательные обновления релизов до последнего. После каждого релиза запускаем "Отладку", для сохранения изменений в конфигурации и реорганизации данных. Во всех диалоговых окнах жмём ОК/Далее/Принять/Да/Продолжить...

Таким образом, мы обновили конфигурацию на тестовой базе до последнего релиза, но необходимо проверить, не затёрли-ли мы какие-нибудь изменения и если затёрли, то надо их перенести на этот релиз. Теперь начинается самое интересное, поэтому опишу это пошагово. Каждый шаг будет с некоторым пояснением: то есть, сначала описана суть, а далее - более подробное описание. Если суть понятна, то описание можно опускать.

1. Сохраняем в текстовых файлах изменения конфигурации ДО и ПОСЛЕ обновления. Открываем в режиме Конфигуратора рабочую и тестовую базы. Открываем в них конфигурации. И в обеих базах запускаем обработку сравнения конфигурации ("Конфигурация - Сравнить конфигурации..."). ВАЖНО : в обеих базах одинаково выбирать конфигурации:

Причём сохраняем следующим образом: в рабочей базе (где конфигурация ДО обновления) - в файл с окончанием "old", а в тестовой базе (где конфигурация ПОСЛЕ обновления) - в файл с окончанием "new".

2. Внесение утерянных изменений в обновлённую конфигурацию . Переходим к ключевому этапу метода. Поскольку это основной пункт, то для небольшого пояснения происходящего немного мат.части. На платформе 1С 7.7 файл обновления представлял собой полную конфигурацию. И обновление в 1С 7.7 заключалось в загрузке новой конфигурации и реорганизации базы данных под эту конфигурацию. Таким образом, и конфигурация, и обновление по сути были одним и тем же md-файлом. В отличии от платформы 1С 7.7, на платформе 1С 8.x: конфигурация передаётся через cf-файл, а обновление - через cfu-файл. Отличие этих файлов в том, что cf-файл содержит все объекты конфигурации, а cfu-файл - только те, которые изменяются данным обновлением. И, таким образом, при обновлении на платформе 1С 8.x затрагиваются только те объекты конфигурации, которые реально изменились в новом релизе. В результате, если такой объект изменялся нами, то после обновления он полностью заменится на типовой, и нам будет необходимо повторить в нём те изменения, которые были у него до обновления так, чтобы этот объект содержал и наши изменения, и изменения нового релиза, одновременно. Но зато если изменённый нами объект конфигурации не затрагивался обновлением - в нём останутся наши изменения после обновления. Чтобы проще это понять - изображу это в виде схемы:

На данной схеме изображена некоторая типовая конфигурация в процессе изменения и обновления. Строки - это её объекты (документы, справочники, обработки и так далее). Сначала (под номером I) - это просто типовая конфигурация: все объекты без каких-либо изменений. Потом, под номером II, мы уже видим типовую изменённую конфигурацию: некоторые объекты были изменены и эти изменённые объекты обозначены красным цветом. Под номером III - это очередное обновление для типовой конфигурации: по сути оно содержит только затронутые изменениями нового релиза объекты, которые обозначены зелёным цветом, но для наглядности я дорисовал и все остальные объекты. И нам требуется получить обновлённую типовую конфигурацию (изображённую на схеме I), но с изменениями и схемы II, и схемы III. На данном примере - эта конечная конфигурация изображена под номером IV и содержит один объект, который был изменён и нами, и обновлением. Остальные изменённые нами объекты, очевидно, остались нетронутыми данным обновлением. Теперь вопрос: как внести ВСЕ наши изменения в объект, который был затронут обновлением? Очевидно, что нам надо сделать два шага: во-первых, отыскать этот объект, а во-вторых - найти в нём места, где должны быть наши изменения и внести их заново. Замечу, что, естественно, таких объектов может быть несколько и требуется их всех найти и исправить. Итак, приступим к этому последнему этапу обновления. На данный момент, у нас должна быть открыта тестовая база в режиме Конфигуратора. Если там ещё открыт результат обработки сравнения конфигураций или ещё какое-нибудь окно - закроем их всех, чтобы не путаться. Далее - мы открываем рабочую базу в режиме Конфигуратора (на время обновления тестовой базы можно было закрыть её) и запускаем там сравнение конфигураций. И описание последних двух шагов (найти и исправить) я помещу в отдельные подпункты:

2.1. Поиск объекта, с затёртыми обновлением изменениями . Самое время вспомнить про txt-файлики с окончаниями old/new. На самом деле, в этих файлах отражены все изменения конфигурации (относительно типовой) ДО и ПОСЛЕ обновления соответственно. Таким образом, если мы какое-то изменение затёрли обновлением, то оно будет только в файле "ОтчетОСравнении_old.txt". То есть - поиск необходимых объектов конфигурации сводится к сравнению этих двух файлов. Сравнивать эти файлы мы будем с помощью файлового менеджера Total Commander и его встроенных инструментов. Думаю, что здесь не нужно пояснять, что такое Total Commander, где его брать и как им пользоваться... Тем не менее, требуемые этапы его применения здесь кратко буду описывать. Итак, запускаем Total Commander. Если язык интерфейса английский (главное меню и так далее), то можно сменить на русский: "Configuration - Options...", в диалоговом окне выбираем в левом столбике раздел "Language", в списке ищем/выбираем "Russian (Русский)" и жмём "OK". Далее, через Total Commander ищем txt-файлы отчётов, выделяем их ("Insert" или "правым кликом мышки") и запускаем сравнение файлов: "Файлы - Сравнить по содержимому..." (в английском интерфейсе: "Files - Compare By Content..."). В открывшемся окошке слева/справа отображается соответственно содержимое файлов, кнопки "Следующее отличие"/"Предыдущее отличие" позволяют искать различия. Этот инструмент позволит быстро найти интересующие нас объекты.

Замечание : может случиться и обратная ситуация - в конфигурации ПОСЛЕ обновления появились различия, которых не было ДО обновления. Это означает, что релиз обновления удалил из конфигурации соответствующие объекты. В принципе, эти объекты можно просто пропускать в наших исправлениях, посколько в этих объектах не было изменений.

2.2. Внесение изменений в обновлённые объекты. После того, как мы нашли объект с затёртыми изменениями, надо определить, где именно были эти изменения: в модуле (программном тексте), диалоговом окне (на форме) или иных настройках. Здесь я буду разделять два случая: изменение в модуле и все другие изменения. И рассмотрим эти два случая отдельно.

2.2.1. Затёртые обновлением изменения были в модуле. На самом деле, это основной случай (такое встречается намного чаще) и этот случай как раз в нашем примере: изменение удалились в модуле "УчётНДС". Как выше мы уже напоминали, что в Конфигураторе рабочей базы у нас открыто окно сравнения конфигураций. Ищем там необходимый нам объект. На самом деле, его положение в дереве конфигурации описано в нашем текстовом файле, а именно: "ОбщийМодуль.УчетНДС.Модуль". Именно так и ищем в окне сравнения. Разворачиваем дерево подчинённостей пока не найдём нужный модуль - с левого края напротив него должен быть зелёный карандаш, показывающий, что объект изменён по сравнению с конфигурацией поставщика. По найденной строке кликаем правой кнопкой мышки и выбираем "Показать различия в модулях...":

После этого откроется окно сравнения модулей:

Здесь, в верхней части указаны процедуры и функции , в которых имеются изменения (в нашем случае - это одна процедура "ВывестиСчетФактуруВТабличныйДокумент"), а в нижней части - тексты выбранной процедуры или функции с выделенными изменениями. Нам нужно эти изменения перенести в нашу тестовую базу. Но при этом не удалить изменения от обновления. Автоматизировать это можно следующим образом. Устанавливаем курсор в левую нижнюю часть (где текст выбранной процедуры с нашими изменениями) и жмём последовательно Ctrl+A (выделить всё) и Ctrl+C (копировать выделенное в буфер). Затем создаём файл с условным названием "old_izm.txt", открываем в текстовом редакторе и жмём Ctrl+V (вставить содержимое буфера). То же самое делаем для правой нижней части (где текст выбранной процедуры из типовой конфигурации необновлённого релиза) - в результате создаём файл с условным названием "old_type.txt". После этого переходим в Конфигуратор тестовой базы (он должен быть открыт рядом, но без каких-илбо окон внутри, чтобы не путаться в этих двух конфигураторах) - и в конфигурации ищем наш модуль (в данном примере это "ОбщийМодуль.УчетНДС.Модуль") и в нём необходимую процедуру (в данном примере это "ВывестиСчетФактуруВТабличныйДокумент"): выделяем её всю и копируем в новый текстовый файл с условным названием "new_type.txt". Таки образом, у нас появилось три файла ("old_izm.txt", "old_type.txt", "new_type.txt"), на основе которых нам нужно создать четвёртый файл - "new_izm.txt". В этом четвёртом файле как раз должны содержаться наши изменения, но с учётом обновления. Его мы будем формировать последовательно сравнивая имеющиеся три файла. Для начала определим, имеются-ли в этой процедуре следы изменений обновления? Для этого мы сравниваем через Total Commander (см. выше) файл "old_type.txt" и "new_type.txt". Если сравнение показало, что файлы идентичны или различие в количестве пробелов или знаков табуляции - это значит с этим куском изменений нам повезло и перенести изменения можно просто скопировав содержимое файла "old_izm.txt" и вставив в открытый модуль тестовой базы, удалив перед этим соответствующую процедуру (проще говоря - заменив её). Тут важно аккуратно следить за пробелами до и после процедуры, чтобы не было лишнего в дальнейшем сравнении: на функциональность это, конечно, не повлияет, но слегка затруднит проверку. Если же сравнение "old_type.txt" и "new_type.txt" показало, что есть реальные различия - это означает, что в этой процедуре имеются как наши изменения, так и изменения обновления. Чтобы упростить задачу переноса: сначала можно визуально оценить, каких изменений больше - от обновления или наших. Для этого опять же через Total Commander последовательно сравниваем "old_type.txt" с "new_type.txt" и "old_izm.txt". И смотрим, где изменений больше: в сравнении "old_type.txt" и "new_type.txt" или в сравнении "old_type.txt" и "old_izm.txt". Если изменений больше в первом сравнении (обновление сильнее изменило функцию), то легче исправлять файл обновлённый, внося наши изменения, то есть - изменяем "new_type.txt". Условно назовём это первый случай внесения изменений. Если изменений больше во втором сравнении (у нас было больше изменений), то легче исправлять наш файл, внося изменения обновления, то есть - изменяем "old_izm.txt". Условно назовём это вторым случаем внесения изменений. Теперь, как именно быстро и точно перенести изменения. Для этого мы создаём четвёртый файл и, как уже договаривались, называем его "new_izm.txt". С учётом оптимизации переноса исправлений, копируем в этот файл содержимое либо "new_type.txt", либо "old_izm.txt" (соответственно, для первого или второго случая внесения изменений).
Теперь открываем сразу два окна сравнения файлов. Для первого случая внесения изменений - это сравнения для файлов "new_izm.txt"/"old_izm.txt" и "old_type.txt"/"old_izm.txt". Для второго случая - это сравнения файлов "new_izm.txt"/"new_type.txt" и "old_type.txt"/"new_type.txt". В окне сравнения есть кнопка "Редактирование": нажмём её в сравнении первой пары. Теперь поясним, что мы видим. В первой паре сравнения видны объекты и от нашего изменения, и от обновления. В соответствии, какой у нас случай, нам надо перенести изменения только наши, либо только обновления. Во втором окне сравнения - как раз видны только те изменения, которые мы должны перенести. Если обратить внимание - в обоих случаях, второй файл и первого, и второго сравнения - один и тот же. Поэтому мы ориентируемся на строки в этом файле, и по строкам во втором сравнении, вносим изменения в окне первого сравнения: нажатая кнопка "Редактирования" как раз позволит нам это сделать.

Для "наглядности" изобразим графически действия при переносе в первом случае (изменяем обновлённый файл, внося наши изменения):

Действия во-втором случае - абсолютно аналогичны и принцим действия ровно такой-же.

Самый сложный и неприятный случай - когда наши изменения и изменения обновления - в ОДНОМ месте. То есть реально на одном сегменте кода были два изменения. В таком случае требуется вмешательство программиста. Так же вмешательство программиста, но в меньшей степени, требуется, если, например, обновлением изменены имена переменных, которые используются в наших изменениях. Стоит заметить так же, что в файле "old_type.txt", либо "old_izm.txt" могут быть пустые строки - это "следа" наших измений. Переносить надо так, чтобы в конечном файле их не было. На функциональность это не влияет, но в дальнейших сравнениях (при последующих обновлениях) - это немного затруднит анализ действий. Итак, после того, как мы сформировали четвёртый файл, перенеся все изменения - надо его содержимое скопировать в конфигурацию. В Конфигураторе тестовой базе, должен быть открыт нужный модуль на новом месте: удаляем существующую процедуру и вставляем содержимое нашего конечного файла, с учётом всех пробелов между предыдущими/последующими функциями. Таким образом мы перенесли изменения ОДНОЙ процедуры найденного объекта. У нас (рис. 6) эта процедура действительно одна. Если таких процедур несколько - описанные действия надо проделать для каждой. Если процедура новая (только в левой половинке) - то просто добавить её в соответствующий модуль в тестовой базе (для корректности дальнейшего сравнения - нужно сохранить порядок процедур, как в соответствующем модуле рабочей базы, где ещё старый релиз).

2.2.2. Затёртые обновлением изменения были НЕ в модуле. Для переноса таких изменений подобное сравнение никак не упростит работу, поэтому переносятся изменения просто визуальным сравнением объектов в рабочей и тестовой базах.

Таким образом - переносим изменения для каждого объекта, где наши изменения затёрлись обновлением. Чтобы проверить, насколько мы верно перенесли все изменения - сохраняем конфигурацию в тестовой базе, выгружаем сравнение конфигураций в файл "ОтчетОСравнении_new2.txt" и сравниваем с файлом "ОтчетОСравнении_old.txt". Если всё идиально, то будет сообщение "Файлы идентичны". Если обновлением были удалены какие-то объекты - то при правильном переносе изменений будут видны только эти объекты в различии. Правильным будет если в сравнении будут видны только пробелы/пустые строки/табуляции, но в таком случае лучше это вычищать и добиваться сообщения "Файлы идентичны". Таким образом, после сохранения изменений в тестовой базе, выгружаем сравнение в файл и сравниваем с изменениями в старом релизе - повторяем это до тех пор, пока сравнение не покажет, что мы перенесли все требуемые изменения.

3. Переносим обновлённую конфигурацию из тестовой в рабочую базу . На предыдущих этапах мы обновили тестовую базу до последнего релиза, проверили и перенесли необходимые изменения и сохранили полученную конфигурацию. Теперь мы её выгружаем в cf-файл и загружаем в рабочую базу. Перед загрузкой - необходимо сделать копию рабочей базы и снять с поддержки конфигурацию. ВСЁ. Пользователи "бездельничали" только в начале, когда мы выгружали базу, и в конце, когда мы снова выгружали базу и загружали конфигурацию.

На этом обновление полностью завершено.

Оригинал статьи находится на сайте

В этой статье будет рассказано про обновление нетиповой конфигурации 1С (редакций 8.2 и 8.3), с сохранением всех изменений внесенных вами (или другими разработчиками) в типовую конфигурацию 1С 8.

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

Обновление нетиповой конфигурации 1С пошаговая инструкция

Рассмотрим по шагам алгоритм обновления конфигурации 1С 8. Данный алгоритм является универсальным, первые одиннадцать его шагов описывают процесс обновления любой типовой конфигурации 1С 8, а все пункты в совокупности описывают обновление нетиповой конфигурации 1С 8:

• Скачайте файл обновления конфигурации с сайта users.v8.1c.ru или получите его из любых других доступных источников(например с диска ИТС);
• Распакуйте и установите файл с обновлением 1С 8 в любую папку на жестком диске;
  
• В папке с номером релиза 1С 8 найдите файл 1cv8.cfu — именно этот файл содержит обновления конфигурации;
  
  
• Запустите 1С:Предприятие в режиме Конфигуратор ;
• Перейдите в меню Конфигурация -> Поддержка -> Обновить конфигурацию .
  
  
• В открывшемся окошке «Обновление конфигурации» устанавливаем флаг на пункте Выбор файла обновления и жмем кнопку Далее (если хотите то можно воспользоваться и первым пунктом Поиск доступных обновлений и поискать файлы обновлений в автоматическом режиме);
• В поле «Укажите файл обновления» выберите.cfu файл из папки с номером релиза. Заметьте, что обновить конфигурацию базы 1С 8 можно не на любой релиз. Для каждого файла обновления существует список релизов для которых оно предназначено. Поэтому возможно придется устанавливать несколько файлов обновления последовательно;
• В следующем окне вы увидите описание данного обновления. Также в нем можно посмотреть для обновления каких версий конфигурации предназначен данный файл. Нажмите кнопку Продолжить обновление ;
• Если данную версию конфигурации невозможно обновить выбранным файлом, то вам будет выдано окошко с подсказкой, какие релизы следует установить;
• Если выбранный файл подходит для обновления конфигурации, то появится окно с данными о версии обновления. Для продолжения обновления нажмите кнопку ОК;
  
• После этого запустится процесс обновления. Если ваша конфигурация типовая, то по его завершении останется только согласится изменить текущую конфигурацию и запустить 1С 8 в режиме Предприятие;
• Если же вы обновляете конфигурацию с изменениями (нетиповую), то после завершения процесса обновления появится окно сравнения-объединения старой и новой конфигурации.

Обновление нетиповой конфигурации 1С разбор примера

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

В данном окне присутствует две колонки, каждая из которых содержит дерево метаданных. В первой показаны метаданные текущей конфигурации базы данных, а во второй обновленные метаданные конфигурации поставщика (обновленная типовая конфигурация). Зелеными карандашиками отмечены измененные объекты, в первом столбце помечены измененные вами типовые объекты метаданных, а во втором измененные обновлением типовые объекты метаданных. Таким образом, чтобы произвести правильное обновление нетиповой конфигурации 1с, нужно найти все объекты метаданных, которые изменены и вами и обновлением (то есть дважды измененные).

Для это нажмите расположенную внизу окна кнопку Фильтр , в открывшемся окне установить флаг и нажмите ОК.

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

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

Обновление общего модуля.

• Рассмотрим пример: В общий модуль КонтрольВерсииКонфигураци вы внесли следующие изменения:
  • В процедуре ПроверитьВерсиюКонфигурации() закомментировали строку: //ОткрытьФормуМодально("ОбщаяФорма.НерекомендуемаяВерсияКонфигурации", Параметры);
  • Добавили в модуль свою процедуру с именем МояТестоваяПроцедура().

  При обновлении этот модуль изменился, поставив в окне сравнения фильтр по дважды измененным мы увидим, что он попал в список.
  
  Рассмотрим подробнее данное окно, и поймем какую информацию из него мы сможем почерпнуть. Во-первых, мы видим, что общий модуль изменен и в основной конфигурации и в обновленной конфигурации поставщика, об этом говорят зеленые карандашики в обоих столбцах. Во-вторых, в первом столбце мы видим установленный флажок возле имени общего модуля, он говорит о том, что будет произведено объединение модулей (того, что изменен нами и типового обновленного). В-третьих, в последнем столбце мы видим в каком режиме произойдет объединение модулей. В данном случае установлено значение: Взять из новой конфигурации поставщика, это означает, что наши изменения будут полностью затерты, а изменения внесенные обновлением будут полностью применены.

  Другие режимы объединения предлагают частичное объединение модулей, с различными приоритетами. Но я вам настоятельно рекомендую не использовать эти режимы, так как после этого в вашем модуле может получиться натуральная «каша»: некоторые ваши изменения будут затерты, а некоторые типовые изменения не применятся. Поэтому изменять значения в столбце Режим объединения… мы никогда не будем. В-четвертых, если снять галку установленную в первом столбце напротив модуля, то объединение производиться не будет и модуль останется в том виде в котором он был до обновления.Исходя из перечисленных пунктов есть два способа обновить общий модуль:

  • Затереть ваши изменения установив типовые. После чего вручную внести затертые изменения в обновленный модуль;
  • Не обновлять модуль и внести типовые изменения вручную.

  Механизмы сравнения конфигураций

  Для сравнения изменений в модуле можно воспользоваться следующими встроенными механизмами окна сравнения-объединения конфигураций:

  • Просмотр различий в модулях . Для этого в окне сравнения щелкните на модуле правой кнопкой мыши выберите пункт Показать различия в модулях… После чего откроется окно сравнения модулей, в котором можно увидеть, какие именно процедуры в обновленном и измененном вами модуле различаются. Верхняя часть экрана разделена на две колонки: в левой представлен список процедур основной конфигурации, которые были изменены, а в правой аналогичный список процедур обновленной типовой конфигурации. Нижняя часть окна также разделена на две части, по тому же принципу. В ней отображается код выделенных процедур. Строки, которые присутствуют только в основной конфигурации выделены синим цветом. Строки, которые присутствуют только в обновленной типовой конфигурации выделены зеленым цветом. Строки, которые присутствуют в обоих конфигурациях, но не совпадают между собой, выделены красным цветом.
    
    
    
    
    
    
    
  • . Для сравнения модулей также можно использовать отчет о сравнении объектов. Чтобы вызвать его в окне сравнения щелкните на модуле правой кнопкой мыши выберите пункт В открывшемся окне, в области Формат, установите флаг Подробно. В открывшемся отчете можно увидеть, какие строки модуля изменены и как они выглядят в обоих конфигурациях.
    
    
    Не смотря на то, что данный отчет предоставляет всю информацию о изменениях, он не удобен в работе (по крайней мере при обновлении модулей). Гораздо более интересны две его модификации: Отчет о сравнении объектов основной конфигурации со старой конфигурацией поставщика (в этом отчете видны только изменения внесенные вами) и (в этом отчете видны только только изменения внесенные в модуль обновлением).
    
    
    
    При помощи первого отчета можно увидеть во скольких местах внесены ваши изменения в модуле, это позволит быстро найти их в окне Просмотра различий в модулях. Во втором же отчете можно увидеть во скольких местах типовое обновление внесло свои изменения.

  Мы разобрали все инструменты необходимые для обновления модуля. Для того, что бы показать их практическое применение рассмотрим по шагам процесс обновления модуля КонтрольВерсииКонфигураци с перечисленными выше изменениями. Обновим модуль двумя способами:

  • Обновим модуль, затерев внесенные в него изменения. Внесем их вручную после обновления;
  • Не будем обновлять модуль. Изменения полученные в обновлении внесем после.

  Первый способ:

  • • Перед описанием алгоритма замечу, что мы рассматриваем очень простой пример обновления, для того чтобы описание не заняло очень много места, но процесс обновления в сложном случае состоит из точно таких этапов, хотя и требует большей сосредоточенности и внимательности;
    • Перед обновлением конфигурации создадим текстовый документ. В него мы будем записывать изменения, которые необходимо будет внести вручную, после обновления. Данные в текстовом документе должны быть представлены максимально понятным образом, то есть быть структурированы. В нашем примере будем писать так: 1. Общие модули 1.1 КонтрольВерсииКонфигураци
    • Найдем общий модуль КонтрольВерсииКонфигураци Модуль. Кликнем по нему правой кнопкой мыши и в контекстном меню выберем пункт Отчет о сравнении объектов основной конфигурации со старой. В открывшемся окне поставим флаг Подробно. Также я устанавливаю флаг Выводить в Текстовый документ , потому что так удобней смотреть изменения, но это уже дело привычки. Нажмем кнопку ОК. Открывшийся отчет будет иметь следующий вид:
      
      
    • Из отчета видно, что в модуль внесено два изменения (перед каждым новым изменением пишутся номера строк, в которых оно внесено):
      • Изменена строка 34, в основной конфигурации она закомментирована, а в старой конфигурации поставщика нет;
      • Добавлена процедура, в старой конфигурации поставщика на ее месте пусто, а в основной конфигурации она есть. Отчет не закрываем, он нам пригодится;
    • Теперь найдем первое отличие в окне сравнения модулей. Для этого снова кликаем правой кнопкой мыши по ветке Модуль и в контекстном меню выбираем пункт Показать различия в модулях… Так как в окне сравнения модулей не видно номеров строк (глобальной нумерации), то для того чтобы найти первое изменение пролистаем все процедуры в верхней половине окна. Также из отчета мы знаем, что первое изменение связано с изменением строки, поэтому ищем текст выделенный красным цветом. Измененная строка найдется в процедуре ПроверитьВерсиюКонфигурации().
      
      
    • Откроем текстовый документ, созданный для записи изменений. Пунктом «1.1.1» запишем там название процедуры, в которой находится изменение. После этого нам надо вписать в него найденное изменение так, что бы мы легко могли найти его в тексте модуля. Для этого я обычно копирую в документ не одну, а сразу несколько строк процедуры, до и после изменений. Но в данном случае процедура маленькая и поэтому достаточно скопировать саму измененную строку. Получится следующая запись: 1. Общие модули 1.1 КонтрольВерсииКонфигураци 1.1.1 ПроверитьВерсиюКонфигурации //ОткрытьФормуМодально("ОбщаяФорма.НерекомендуемаяВерсияКонфигурации", Параметры);
    • Теперь снова откроем отчет о сравнении конфигураций, посмотрим следующее изменение и также найдем его в окне сравнения модулей. На этот раз это добавленная новая процедура. Так как данная процедура полностью отсутствует в старой конфигурации поставщика, то ее текст будет выделен синим шрифтом:
      
      
    • Снова откроем текстовый документ, созданный для записи изменений. В пункт «1.1.2» запишем название добавленной процедуры. После этого скопируем туда весь текст добавленной процедуры. 1.1.2 МояТестоваяПроцедура Процедура МояТестоваяПроцедура() Экспорт //Текст процедуры КонецПроцедуры
    • КонтрольВерсииКонфигураци установлен флаг, означающий, что данный модуль следует обновить, затерев все внесенные изменения;
      
    • Далее необходимо записать в текстовый документ изменения других дважды измененных объектов метаданных. Но так как в данном примере мы рассматриваем конкретный общий модуль, то пропустим этот этап;
    • После того, как работа над дважды измененными объектами выполнена, в окне сравнения / объединения нажимаем кнопку Выполнить;
    • Если появится окно с текстом «Существуют объекты, измененные в основной конфигурации…», нажимаем кнопку Да ;
      
      
    • В следующем окне Настройка правил поддержки не меняем никаких настроек, а просто нажимаем кнопку Да ;
      
      
    • Последним появится сообщение: «Объединение конфигураций завершено». Жмем кнопку ОК ;
      
    • Сохраним конфигурацию при помощи меню Файл -> Сохранить , пиктограммы Сохранить (синяя дискета) или сочетания клавиш Ctrl + S ;
    • После того как конфигурация сохранена, восстановим затертые изменения модуля. В дереве метаданных найдем и откроем модуль КонтрольВерсииКонфигураци;
    • Откроем текстовый документ в который занесены изменения данного модуля;
    • В пункте «1.1.1» указана процедура ПроверитьВерсиюКонфигурации, найдем ее в модуле и раскроем;
    • В текстовом документе указано, что следует закомментировать строку: ОткрытьФормуМодально("ОбщаяФорма.НерекомендуемаяВерсияКонфигурации", Параметры);

      Найдем ее в модуле и установим комментарий;

    • В пункте «1.1.2» указана процедура МояТестоваяПроцедура, которую необходимо добавить в модуль. Копируем ее из текстового документа и вставляем в конец модуля;
    • Сохраняем конфигурацию одним из указанных выше способов;
    • Обновление конфигурации на этом завершено, осталось только обновить конфигурацию, воспользовавшись клавишами F5 или F7 или соответствующими пиктограммами, и в режиме 1С:Предприятия подтвердить легальность обновления;
      
      
  • Второй способ:
    • Второй способ полностью повторяет первый, за исключением того, что действует он от обратного. Поэтому опишу его кратко;
    • Создаем текстовый документ с такой же структурой;
    • Сформируем отчет Отчет о сравнении объектов новой конфигурации поставщика со старой конфигурацией поставщика;
    • Используя сформированный отчет и окно сравнения модулей выпишем в текстовый документ изменения внесенные новой конфигурацией поставщика;
    • В окне сравнения / объединения конфигураций проверяем, что возле модуля КонтрольВерсииКонфигураци СНЯТ ФЛАГ. Это означает, что данный модуль не будет обновляться;
    • Обновляем конфигурацию, вносим изменения из текстового документа в модуль КонтрольВерсииКонфигураци.

Обновление плана обмена.

Рассмотрим пример: в состав плана обмена ПоОрганизации вы включили справочник ВнешниеОбработки. При обновлении нетиповой конфигурации 1с состав данного плана обмена изменился и перед нами стоит задача правильно обновить план обмена, не затерев ни типовые изменения, ни свои. Инструменты используемые для сравнения измененных объектов метаданных были подробно описаны в предыдущих пунктах, поэтому для данного случая все будет описано кратко.

Рассмотрим по шагам обновление состава плана обмена ПоОрганизации с указанными изменениями:

• В созданный при обновлении общего модуля текстовый документ добавим новые строки: 2. Планы обмена 2.1 ПоОрганизации
• Найдем план обмена ПоОрганизации в окне сравнения / объединения, раскроем его до ветки Состав. Замечу, что в плане обмена вами может быть изменен и модуль, его надо обновлять по правилам описанным для общего модуля. В данном случае нас интересует именно обновление состава плана обмена;
  
• Как и в случае с общим модулем, состав плана обмена можно либо обновить, после этого добавив свои изменения вручную, либо не обновлять, добавив типовые изменения вручную. Если ваших изменений в составе больше, чем типовых, то обновлять лучше вторым способом, если меньше то первым. Посмотреть каких изменений больше можно при помощи все тех же отчетов:
  
• В нашем примере типовых изменений больше, поэтому выпишем в текстовый документ наши изменения: 2. Планы обмена 2.1 ПоОрганизации - ***Справочники - -->Справочник.ВнешниеОбработки
• Проверяем, что в окне сравнения / объединения установлена галочка возле плана обмена ПоОрганизации;
• Сохраняем конфигурацию;
• После того как конфигурация сохранена, восстановим затертые изменения плана обмена. В дереве метаданных найдем и откроем план обмена ПоОрганизации;
• В пункте «2.1» текстового документа указан справочник ВнешниеОбработки, найдем его в дереве метаданных состава плана обмена и установим флаг, означающий участие справочника в обмене;
  
  
• Сохраним и обновим конфигурацию;

Обновление подписки на событие.

Рассмотрим пример: в источник подписки на событие ПередУдалениемСправочникаДляОбменаПоОрганизации вы включили справочник ВнешниеОбработки. При обновлении состав источников изменился, задача аналогичная предыдущим — выполнить обновление нетиповой конфигурации 1с правильно.

Рассмотрим по шагам обновление состава источников подписки на событие с указанными изменениями:

Обновление ролей в 1С

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

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

Рассмотрим обновление роли по шагам:

• Найдем роль Бухгалтер в окне сравнения / объединения, раскроем ее до ветки Права ;
  
• В данном примере в роли всего одно изменение, но обычно бывает не так. Поэтому роль намного проще не обновлять, а типовые изменения вносить вручную;
• Сформируем Отчет о сравнении объектов новой конфигурации поставщика со старой конфигурацией поставщика . Обычно в нем очень много информации, но далеко не вся нужна для обновления:
  
• Остаются либо добавленные новые объекты метаданных, либо изменения прав для старых:
  • Добавленные объекты выглядят так: - -->

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

  • Измененные объекты выглядят так: - ***Справочники - ***НалоговыеОрганы - ***Права - ***Чтение - ***Значение -->Разрешено <--Запрещено - ***Просмотр - ***Значение -->Разрешено <--Запрещено

    При этом подробно указано, какие права изменились;

• В нашем примере из полезной информации в отчете о сравнении находится лишь одна строка, добавляем ее в текстовый документ: 4. Роли 4.1 Бухгалтер - -->Объект - РегламентированныйОтчетСтатистикаФорма11НА

  При этом можно указать какой это объект метаданных, но в данном случае и так видно, что отчет;

• В окне сравнения / объединения снимем галочку возле роли Бухгалтер;
• После этого необходимо записать в текстовый документ изменения других дважды измененных объектов метаданных и выполнить обновление (процесс подробно описан выше);
• Сохраняем конфигурацию;
• После того как конфигурация сохранена, необходимо внести типовые изменения в роль Бухгалтер . В дереве метаданных найдем и откроем данную роль;
• В пункте «4.1» текстового документа сказано, что в роль добавлен объект РегламентированныйОтчетСтатистикаФорма11НА, найдем его в дереве метаданных роли, установим галочки на правах Использование и Просмотр;
  
  
• Сохраним и обновим конфигурацию.

На этом статья про Обновление нетиповой конфигурации 1С завершена. Если после прочтения у вас остались вопросы — смело задавайте их в комментариях! По желанию читателей в следующей статье я могу рассказать о других интересных и сложных аспектах обновления нетиповой конфигурации 1С 8.