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

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

Начало любого обновления описано в статье . Мы же будем рассматривать только самое главное — нюансы нетипового обновления.

Немного теории о нетиповых конфигурациях:

• Конфигурация без поддержки содержит 2 конфигурации: конфигурацию базу данных и основную конфигурацию.
• Конфигурация на поддержке без возможности редактирования содержит в себе 2 конфигурации: конфигурацию базу данных и основную конфигурацию (она же поставщика).
• Конфигурация на поддержке с возможностью изменения содержит в себе уже 3 конфигурации: конфигурацию базу данных, основную конфигурацию и конфигурацию поставщика.

1. Подготовка к обновлению

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

Первым делом я разворачиваю 2 базы с первоначальной конфигурацией. Одну для внесения изменения, вторую для сравнения с новой.

Получите 267 видеоуроков по 1С бесплатно:

Если Ваша конфигурация не типовая, то по нажатию кнопки «обновить» в конфигураторе система начнет сравнение основной и новой конфигурации поставщика:

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

После фильтрации мы видим, что измененных объектов стало гораздо меньше:

Мы получили список объектов, над которыми будем работать. В нашем случае оказался всего один сложный объект — документ ЗаписьКУДиР.

2. Перенос изменений обновления 1С

Для переноса изменений я открываю 2 конфигуратора — в одном запускаю сравнения и забираю изменения, а во втором — произвожу доработки.

Следующий этап — непосредственно перенос изменений. Рассмотрим основные приемы при обновления нетиповых конфигураций.

3. Различия в модулях

Достаточно простая, но очень ответственная операция — мы просто переносим модули из нового релиза в старый. Если код комментируется, то проблем быть не должно:

4. Сравнения форм и макетов

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

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

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

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

Личный опыт: как быстро и без лишних затрат обновить измененную конфигурацию

Обновлять конфигурацию сразу на несколько релизов весьма опасно. Дело в том, что после каждого обновления конфигурации запускается обновление информационных баз в режиме "1С:Предприятие". Поэтому если актуализировать только последний релиз, информационные базы могут не соответствовать последней конфигурации. В статье Дмитрий Рудаков, специалист компании ЗАО "Сибирская Аграрная Группа", делится личным опытом по единовременному обновлению конфигурации на 12 релизов.

Проверка режима изменения конфигурации

Представим себе такую ситуацию. Разработчики "Управления производственным предприятием" (далее - УПП) в релизе 1 (номера релизов здесь и далее присвоены условно) измерению (показателю) регистра расчета назначили тип "СправочникСсылка.ФизическоеЛицо" с наименованием "ФизЛицо". В релизе 2 они добавили еще одно измерение - "Сотрудник" с типом "СправочникСсылка.Сотрудники". При запуске "1С:Предприятие" включается обработка, которая заполняет измерение "Сотрудник", соответствующим измерению для "ФизЛица" образом. И потом в релизе 3 разработчики "1С" удалили измерение "ФизЛицо" и оставили только "Сотрудник". Если обновить конфигурацию с релиза 1 сразу до релиза 3, то можно очистить весь регистр расчета.

А если конфигурация стоит на поддержке с возможностью изменения, и в этой же базе данных формируется регламентированная отчетность, то необходимо обновлять конфигурацию на каждый релиз, что может быть очень дорого в человеко-часах. Например, обновление сильно измененной "УПП" на 1 релиз может занять 30 часов рабочего времени опытного специалиста.

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

Рис.1. Вызов окна настройки поддержки конфигурации

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

Рис. 2. Типовая конфигурация без возможности изменений

Рис. 3. Типовая конфигурация с включенной возможностью изменения

Рис. 4. Конфигурация, снятая с поддержки

Алгоритм обновления измененных конфигураций

Недавно передо мной встала задача обновления измененной конфигурации "Управление торговлей", релиз 10.3.13.2. Конфигурация была изменена в результате объединения с отраслевым решением "БИТ: Управление автосервисом 8" и непрерывно дорабатывалась в течение двух лет. Теперь конфигурацию нужно было обновить до релиза 10.3.25.1, то есть на 12 релизов. Я разбил всю процедуру обновления на несколько этапов.

Этап 1. Оценка стоимости и сроков процедуры обновления

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

Отчет по итогам оценки стоимости и сроков проведения обновления конфигурации:

Конфигурация: Управление торговлей, редакция 10.3
Текущая версия конфигурации: 10.3.13.2
Обновление до версии: 10.3.25.1
Количество обновляемых модулей: 1 847
Количество контрольных релизов: 8

Результаты оценки меня удивили, поскольку на сайте компании была указана стоимость по акции - 1000 руб. за обновление на один релиз. Комментарий "1С-ИжТиСи":

"Стоимость обновления на каждый пропущенный релиз у нас не выше 2000 рублей. Сейчас проходит акция, поэтому стоимость не превышает 1000 руб. Но окончательная цена услуг определяется по результатам оценки трудозатрат на обновление и может быть ниже 1000 руб./релиз".

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

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

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

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

Сильно измененные объекты. Это объекты, в которых изменено много типовых свойств. Корректировки имеют комплексный характер. Реквизиты объекта добавлены в табличную часть, выведены на форму объекта и на форму списка. Дописаны обработчики добавленных реквизитов в формах. Изменен типовой механизм проведения документа или записи набора движения для регистра.

Сильно измененные документы:
"Заказ поставщику";
"Перемещение товаров";
"Требование-накладная";
"Поступление товаров и услуг".

Сильно измененные регистры:
"Партии товаров на складах";
"Товары на складах".

Значительно измененные объекты. Объекты, в которых добавлены реквизиты, изменены либо формы объектов, либо модули объекта (как правило, проведение документа нетиповое).
Документ "Приходный кассовый ордер";
Регистр сведений "Комплектующие номенклатуры";
Регистр сведений "Списанные товары";
Общие модули.

Незначительно измененные объекты. В объектах изменены только формы и добавлены реквизиты.

Справочники:
"Виды номенклатуры";
"Договоры контрагентов";
"Контрагенты";
"Номенклатура";
"Типы цен номенклатуры";
"Ряд регистров сведений".

В разделе "Общие" изменены подписки на события, макеты, роли, общие модули. Почти все было изменено отраслевым решением.

Этап 2. Удаление конфиденциальной информации

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

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

Обработка ИзменениеКонфиденциальнойИнформации.epf есть на диске ИТС в каталоге 1CIts\EXE\EXTREPS\UNIREPS81\UpdatePrivateInformation. Также данную обработку можно скачать по ссылке: http://its.1c.ru/db/metod81#content:1644:1.

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

• Справочники: Физические лица, Контактные лица, Контактные лица контрагентов, Контрагенты, Типы цен.
• Регистры сведений: Паспортные данные физического лица, ФИОФизЛиц.

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

Этап 3. Получение результатов обновления

Через три дня мне предоставили cf-файлы и исчерпывающие инструкции по их установке. Для контрольных релизов предоставляются cf-файлы, которые нельзя использовать для работы пользователей, так как в них обновлены только метаданные. Они предназначены только для корректного обновления на последнюю версию.

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

В результате обновления я выделил две небольшие задачи для самостоятельного решения.

Первая. В силу того, что обновление проводится с использованием механизма "Сравнение, объединение", конфигурация БД действительно обновляется, и обновляется правильно, без технических рисков благодаря учету контрольных релизов. Однако не обновляется конфигурация поставщика. Разумеется, технически грамотный специалист без проблем дополнит данную работу, однако я попросил "1С-ИжТиСи" выслать более полную инструкцию по обновлению. В соответствии с ней, обновление сможет произвести даже неопытный специалист.

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

Кроме двух названных задач, был обнаружен один небольшой недочет, который, в принципе, не влияет на качество обновления и редко проявляется. В результате обновления строки кода исходной конфигурации и обновленной визуально совпадают, но в конце строк по каким-то причинам добавлены пробелы. Это является недостатком, так как несколько увеличивает объем измененного кода. И в случае дальнейшего ручного обновления было бы лучше не иметь таких участков кода. На рис. 6 приведен пример до обновления, а на рис. 7 - пример после обновления.