1с обновление нетиповой конфигурации 8.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.

Это довольно старая моя статья, но она до сих пор является актуальной. Поэтому я решил, что будет целесообразно опубликовать её на www..

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

Возможно, вы заметили, что при каждом очередном обновлении количество объектов, требующих вашего внимания, только увеличивается. При этом вы точно знаете, что изменен, например, только один документ, а при обновлении выдается список из нескольких десятков измененных объектов. Конечно, можно воспользоваться методикой описанной в моей статье «Технология обновления нетиповых конфигураций 1С:Предприятия 7.7» от 27.06.2003. Да, это будет работать. Многие именно так выполняют обновления. Но я считаю данный подход неэффективным и трудоемким при обновлении конфигураций на платформе 1С:Предприятия 8. В отличие от платформы 1С:Предприятия 7.7 платформа 1С:Предприятия 8 позволяет открывать одновременно несколько конфигураций (файлы *.cf) и выполнять несколько сравнений конфигураций в одной копии конфигуратора. Исключение составляют, пожалуй, только конфигурации построенные на УПП (Управление производственным предприятием) - они слишком тяжелые, платформа падает.

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

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

Следует обратить внимание на то, что база данных может содержать до трех видов конфигураций:

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

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

Рассмотрим процесс обновления и разберем возможные ошибки на примере обновления конфигурации УПП (поставщик типовой конфигурации - фирма «1С», доработки компании Информ Сервис). Изначально обновление данной конфигурации выполнялось не по описанной в данной статье технологии, поэтому рассматриваемые в статье ошибки являются наиболее часто встречающимися на практике. Обновление будет выполняться с версии 1.2.6.2 на версию 1.2.14.1.

Этап 1. Подготовка.

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

Этот этап можно пропустить, если последнее обновление прошло через «поддержку» (Меню «Конфигурация» → «Поддержка» → «Обновить конфигурацию») или было выполнено по описанной в данной статье методике.

Несоответствие версий рабочей конфигурации и конфигурации поставщика может возникнуть при использовании для обновления *.cf файлов, не из дистрибутива поставщика или при использовании методов обновления отличающихся от описанных в данной статье. Напрмер, объекты добавлялись в рабочую конфигурацию копированием через буфер обмена или Drag&Drop.

1. Сравнение версий.

Проверим номера версий рабочей конфигурации и конфигурации поставщика . Номер рабочей конфигурации смотрим в меню «Конфигурация» → «Открыть конфигурацию» меню «Правка» → «Свойства». В блоке «Разработка» пункт «Версия». (Рисунок 1).

Номер конфигурации поставщика смотрим в меню «Конфигурация» → «Поддержка» → «Настройка поддержки…» пункт «Версия». (Рисунок 2).

Если номера совпадают, то переходим к следующему этапу. См. .

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

2. Сохранение рабочей (основной) конфигурации.

Сохраним рабочую конфигурацию в файл, например work.cf . Для этого выберем пункт меню «Конфигурация» → «Сохранить конфигурацию в файл…».

3. Получение файла обновления для конфигурации поставщика.

Для приведения в соответствие конфигураций нам понадобится файл *.cf из дистрибутива поставщика с тем же номером версии, что у рабочей конфигурации (Рисунки 3 и 4). Данный файл можно получить при установке соответствующего дистрибутива. По умолчанию установка дистрибутива конфигурации выполняется в каталог C:/Program Files/1cv81/tmplts. Подробнее об установке шаблонов конфигураций см. документацию.

Проверим каталог шаблонов. Если в каталоге шаблонов есть *.cf файл нужной версии, то переходим к .

Что можно сделать, если нет *.cf файла нужной версии конфигурации поставщика ? В этом случае можно воспользоваться файлами *.cfu и повторив описанную в Этапе 1 процедуру несколько раз последовательно поднять номер версии до требуемого релиза, в данном случае до 1.2.6.2. Следует отметить, что использование файлов *.cfu может не вскрыть ошибки, допущенные ранее при обновлении. Что, согласитесь, довольно странно, учитывая тот факт, что вначале собирается файл поставщика на основе и *.cfu файла, а затем выполняется обновление. Возможно это связано с тем, что в сравнении почему-то участвуют не все объекты конфигурации. Поэтому предлагаю использовать возможно более длинный путь, но и более надежный.

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

  1. Создание "старого" файла поставщика для текущей конфигурации. Файл 1cv8.cf можно взять из дистрибутива поставщика или сохранить из рабочей базы, если конфигурация находится на поддержке. Для сохранения файла 1cv8.cf из рабочей базы необходимо в меню «Конфигурация» → «Поддержка» → «Настройка поддержки...» нажать кнопку «Сохранить в файл» и указать каталог и имя файла. Например, на рабочий стол.
  2. Создание базы данных с новой конфигурацией поставщика. Базу данных можно создать, используя дистрибутив поставщика с диска ИТС или используя полученный ранее 1cv8.cf с рабочего стола. В первом случае следуем инструкции входящей в дистрибутив. Во втором случае для создания базы из расположенного на рабочем столе файла, создаем новую информационную базу без конфигурации и запускаем конфигуратор. В меню «Конфигурация» → «Загрузить конфигурацию из файла...» указываем файл, сохраненный ранее на рабочем столе. Открываем конфигурацию через меню «Конфигурация» → «Открыть конфигурацию» и обновляем до нужного релиза через меню «Конфигурация» → «Поддержка» → «Обновить конфигурацию» используя файлы *.cfu.
  3. Создание файла "новой" конфигурации поставщика. Для этого выбираем пункт в меню «Конфигурация» → «Сохранить конфигурацию в файл...». Уточняем расположение и имя файла 1cv8.cf . Нажимаем «Сохранить».

4. Приведение в соответствие рабочей конфигурации и конфигурации поставщика через обновление.

Используя полученный *.cf файл конфигурации поставщика выполним обновление. Для этого выберем пункт меню «Конфигурация» → «Поддержка» → «Обновить конфигурацию», «Выбор файла обновления», «Готово» (Рисунок 5), «Выполнить» (Рисунок 6).

Варианты решения:

  • снять пометку с объекта, которыйв конфигурации поставщика;
  • удалить ссылку на объект, которыйв конфигурации поставщика.

Исходя из того, что ссылка в добавленном интерфейсе «РуководительОтдела» выполнена на объект конфигурации поставщика , поддержка с которого снята поставщиком (возможно в связи с изменением методики учета), то правильным решением в данной ситуации будет удаление ссылки на этот отчет из интерфейса «РуководительОтдела». Окно сравнения конфигураций не закрываем, ссылку на отчет «ОплатаЗаказов» в интерфейсе «РуководительОтдела» удаляем. После удаления ссылки выполним повторное сравнение конфигураций. Для этого нажмем кнопку «Обновить» в окне обновления (Рисунок 6).

5. Восстановление настроек частично утерянных на предыдущем этапе.

Для восстановления частично утерянных настроек выполним объединение с ранее сохраненным файлом рабочей конфигурации work.cf . Для этого выберем пункт меню «Конфигурация» → «Сравнить, объединить с конфигурацией из файла…».

6. Сохранение результатов обновления.

Сохраним изменения рабочей конфигурации и обновим конфигурацию базы данных . Для этого выберем пункт меню «Конфигурация» → «Обновить конфигурацию базы данных».

Здесь нас поджидает очередная проблема (Рисунок 8).

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

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

Рассмотрим еще одну ситуацию, аналогичную предыдущей, но возникшую при обновлении 1С:Бухгалтерии предприятия 8.1. Что делать с формами? (Рисунок 9)

На рисунке мы видим, что ФормаСписка была удалена у поставщика, а затем добавлена поставщиком новая форма с тем же именем. Соответственно необходимо пометить обе формы для обновления и нажать кнопку «Выполнить».

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

Сохраним изменения рабочей конфигурации и обновим конфигурацию базы данных «Конфигурация» → «Обновить конфигурацию базы данных».

Если необходимо, перенесем значения реквизита ЗаказРезерв1 в ЗаказРезерв с помощью внешней обработки в режиме 1С:Предприятие.

Этап 2. Обновление.

После проведения подготовительных работ на Этапе 1 переходим к обновлению основной конфигурации и переносу ранее сделанных доработок типовой конфигурации поставщика.

Для обновления конфигурации нам понадобится файл *.cfu или файл *.cf из дистрибутива поставщика. Подробнее о способах их получения можно почитать .

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

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

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

1. Подготовка баз данных.

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

2. Трёхсторонее сравнение конфигураций.

Откроем обе базы в режиме Конфигуратор и выполним трёхсторонее сравнение конфигураций в обеих базах, используя имеющийся файл новой конфигурации поставщика. Для этого в обеих базах выберем пункт меню «Конфигурация» → «Поддержка» → «Обновить конфигурацию», «Выбор файла обновления», «Готово» (Рисунок 10).

В результате сравнения трех конфигураций (старая конфигурация поставщика , новая конфигурация поставщика и рабочая конфигурация ) получаем список измененных объектов. Устанавливаем фильтр «Показывать только дважды измененные свойства» (Рисунки 11 и 12).

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

На этом работу во второй (вспомогательной) базе приостанавливаем и продолжаем в основной. Кнопку «Выполнить» во вспомогательной базе не надо нажимать. Нам эта база нужна именно в таком виде до окончания процесса обновления.

Итак, в результате получаем список объектов, дважды измененных при доработке типовой конфигурации и в . Если согласиться с обновлением, то сделанные ранее доработки в этих объектах будут утеряны. Поэтому по каждому объекту необходимо принять решение о том, каким образом он будет обновлен (Рисунок 13). На этом этапе выполняем предварительное сравнение исключительно для того, чтобы уменьшить объем работ в дальнейшем. Оценка не точная быстрая - «на глазок».

новой конфигурации поставщика , то оставляем экземпляр объекта поставщика. Оставляем галочку. Затем перенесем изменения из рабочей конфигурации .

Если изменений в объекте больше в рабочей конфигурации , то оставляем экземпляр объекта рабочей конфигурации . Снимаем галочку. Затем перенесем изменения из конфигурации поставщика .

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

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

Далее все сравнения выполняем во вспомогательной базе. Одно сравнение у нас уже есть - трехстороннее. Для определения ранее внесенных изменений выполняем дополнительное второе сравнение старой конфигурации поставщика с основной конфигурацией . Для этого выберем пункт в меню «Конфигурация» → «Сравнить конфигурации:», выберем для сравнения «Конфигурация поставщика » и «Основная конфигурация

Аналогичным образом сравниваем старую конфигурацию поставщика с новой . Для сравнения нам понадобится файл новой конфигурации поставщика . Если такого файла нет, то теперь его можно получить из основной базы. Для сохранения в файл новой конфигурации поставщика в основной базе в меню «Конфигурация» → «Поддержка» → «Настройка поддержки:» нажимаем кнопку «Сохранить в файл». (Рисунок 2). Указываем имя файла, например, new.cf. Далее делаем третье сравнение конфигураций и при сравнении в качестве второй конфигурации указываем файл new.cf.

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

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

Сравнение форм, таблиц, и модулей объектов в конфигурации выполняется с достаточной степенью детализации (Рисунок 17). Этого вполне достаточно для принятия решений.

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

Для снижения трудоемкости работ при сравнении объектов можно воспользоваться обработкой «Сравнение ячеек», разработанной компанией Информ Сервис. Примерно в 20 раз может выть снижена трудоемкость работ при сравнении составных объектов.

Обработка «Сравнение ячеек» запускается в режиме 1С:Предприятие и позволяет представить информацию из отчета о сравнении объектов в наглядном виде (Рисунки 18 и 19). Для сравнения используются возможности 1С:Предприятия 8.

Схема работы обработки проста. В конфигураторе создаем отчет о сравнении объектов (Рисунок 17) и сохраняем в файл, например ОтчетОСравнении.mxl. Открываем 1С:Предприятие и в диалоге (Рисунок 18) выбираем сохраненный файл и указываем сравниваемые ячейки. Для этого дважды щелкаем правой клавишей мыши на выбранной ячейке табличного документа. По кнопке «Сравнить» получаем результат сравнения, в котором различающиеся позиции выделены цветом (Рисунок 19).

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

Особо пристальное внимание следует уделить шаблонам RLS по измененным ролям пользователей.

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

Этап 3. Сдача работ.

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

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

Если в рабочей базе данных заказчика во время подготовки обновления не проводились работы по изменению конфигурации, а обновление готовилось на актуальной копии рабочей базы данных, то для переноса настроек сохраним рабочую конфигурацию в файл, например work_2.cf, выбрав пункт меню «Конфигурация» → «Сохранить конфигурацию в файл…».

  • используя файл work_2.cf, переносим изменения. Для этого выберем пункт меню «Конфигурация» → «Загрузить конфигурацию из файла…»;
  • на вопрос об обновлении конфигурации базы данных ответим согласием.

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

Если обновление готовилось не на актуальной копии рабочей базы данных, то для переноса настроек воспользуемся методикой использованной на первом этапе. Для этого нам понадобится файл *.cf типовой конфигурации поставщика (1.2.14.1) и результат обновления в виде также *.cf файла. Для этого сохраним рабочую конфигурацию в файл, например work_2.cf, выбрав пункт меню «Конфигурация» → «Сохранить конфигурацию в файл…».

Дальнейшие действия на стороне заказчика будут следующие:

  • создать резервную копию базы данных;
  • используя файл *.cf типовой конфигурации поставщика, выполним обновление. Для этого выберем пункт меню «Конфигурация» → «Поддержка» → «Обновить конфигурацию», «Выбор файла обновления», «Готово» (Рисунок 10), «Выполнить»;
  • используя файл work_2.cf, переносим изменения. Для этого выберем пункт меню «Конфигурация» → «Сравнить, объединить с конфигурацией из файла…»;
  • сохраним изменения рабочей конфигурации и обновим конфигурацию базы данных. Для этого выберем пункт меню «Конфигурация» → «Обновить конфигурацию базы данных».

Правильное выполнение данного этапа позволит в дальнейшем избежать работ, описанных в Этапе 1.

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

Обновлять конфигурацию сразу на несколько релизов весьма опасно. Дело в том, что после каждого обновления конфигурации запускается обновление информационных баз в режиме "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 - пример после обновления.

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

Рассмотрим, как проще всего и без ошибок сделать нетиповое обновление, на примере конфигурации 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 - пример после обновления.