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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создание "старого" файла поставщика для текущей конфигурации. Файл 1cv8.cf можно взять из дистрибутива поставщика или сохранить из рабочей базы, если конфигурация находится на поддержке. Для сохранения файла 1cv8.cf из рабочей базы необходимо в меню «Конфигурация» U94; «Поддержка» U94; «Настройка поддержки...» нажать кнопку «Сохранить в файл» и указать каталог и имя файла. Например, на рабочий стол.

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

Создание файла "новой" конфигурации поставщика. Для этого выбираем пункт в меню «Конфигурация» U94; «Сохранить конфигурацию в файл...». Уточняем расположение и имя файла 1cv8.cf . Нажимаем «Сохранить».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аналогичным образом сравниваем старую конфигурацию поставщика с новой . Для сравнения нам понадобится файл новой конфигурации поставщика . Если такого файла нет, то теперь его можно получить из основной базы. Для сохранения в файл новой конфигурации поставщика в основной базе в меню «Конфигурация» U94; «Поддержка» U94; «Настройка поддержки:» нажимаем кнопку «Сохранить в файл». (Рисунок 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, выбрав пункт меню «Конфигурация» U94; «Сохранить конфигурацию в файл…».

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

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

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

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

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

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

Что делать, если конфигурация нетиповая? Или типовая, но в ней выполнены доработки – добавлен справочник, пару реквизитов, отчет?

Ответ на этот вопрос мы узнаем сегодня.

Что такое нетиповая конфигурация 1С

Нетиповая конфигурация 1С, это когда:

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

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

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

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

Посмотрим на пример измененной конфигурации, которую мы хотим обновить. Это типовая конфигурация 1С Бухгалтерия (слева), в которую внесены изменения (справа):

4) В справочнике «Физические лица», в модуле формы, в функции ПрочитатьМестоРождения() добавили строчку программы

Как сработают все эти изменения в момент обновления 1С нетиповой конфигурации 1С?

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

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

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

Файлы обновления 1С могут быть следующего вида:

файл с расширением CF – содержит полностью новый вид конфигурации
файл с расширением CFU – содержит только изменения от предыдущей версии.

Оба файла хранятся в каталоге обновлений 1С, в папке с наименованием версии.

Будьте внимательнее при использовании файла CFU – он позволяет обновить только с !

Итак, для обновления 1С выберите один из вариантов пунктов меню:

Конфигурация/Сравнить объединить с конфигурацией из файла – для файлов CF
Конфигурация/Поддержка/Обновить конфигурацию/Выбор файла обновления 1С – для файлов CF или CFU.

Первым делом 1С сравнит две конфигурации. Конфигурация Вашей базы данных называется «Основная конфигурация», а конфигурация из обновления – «Конфигурация из файла».

1С отобразит все различия в виде привычного дерева , где справа отображены изменения.

Посмотрите – на нашем примере, выделены справочники, которые были изменены или добавлены.

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

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

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

Рассмотрим обнаруженные платформой различия внимательно.

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

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

В кнопке «Настройка» НЕ УСТАНАВЛИВАТЬ галочку «Разрешить удалять объекты основной конфигурации»
Если галочка все же установлена, то снять галочку на против данного реквизита. На картинке галочки напротив реквизита нет, так как удалять объекты не разрешено.

Также у справочника Номенклатура была изменена форма. 1С это увидела и показывает нам в списке измененных объектов форму справочника тоже.

Чтобы посмотреть какие изменения сделаны на форме, можно сделать следующее (варианты):

Нажать правой кнопкой сначала на форму в левой колонке и выбрать пункт меню «Открыть форму», а потом в правой. Визуально сравнить две формы.
Нажать правой кнопкой на форме и выбрать пункт меню «Отчет о сравнении объектов» (подробно, табличный документ)

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

В списке изменений мы видим наши изменения – изменения надписи и замену поля.

Мы можем согласиться или отказаться от изменения формы выбором галочки возле нее. Это влечет за собой следующие последствия:

а) если мы ставим галочку

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

б) если мы не ставим галочку

форма будет оставлена старой
наши изменения остаются
новые изменения из обновления 1С не применяются
далее вручную будет необходимо добавить изменения из обновления 1С.

Можно использовать третий вариант. Раскройте ветку Форма до конца и в колонке «Режим объединения» выберите «Объединить».

в) если мы выбрали «Объединить»

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

2) В справочнике «Физические лица», в модуле формы, в функции ПрочитатьМестоРождения() добавили строчку программы

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

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

Другой способ – это использовать кнопку лупы в этой строчке.

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

3) В справочнике «Электронные представления..» удалили несколько реквизитов

1С определила, что мы удалили реквизиты типового справочника и предлагает нам их восстановить.

Справочник же, нами добавленный, 1С предлагает удалить. В этом случае действует то же правило, что и в случае с добавленным нами реквизитом (см. ранее).

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

Обратите внимание, что если Вы удалили реквизит в результате обновления 1С, то удалили и данные, которые были в него внесены пользователями, а значит повторное добавление того же реквизита не восстановит эти данные.

Если в конфигурации есть несколько связанных объектов – например реквизит и форма; при этом Вы разрешили обновление 1С формы, но сняли галочку с реквизита, то наступает противоречие.

После нажатия кнопки Выполнить, 1С находит такие ситуации и сообщает от них.

После нажатия на кнопку Выполнить у Вас остается еще одна возможность подумать.

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

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

Третий вариант (указана последовательность пунктов меню):

Выбрать Файл/Сохранить
Конфигурация/Сохранить конфигурацию в файл
Конфигурация/Конфигурация базы данных/Вернуться к конфигурации БД.

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

Оставьте свое имя и номер телефона, оператор свяжется с Вами в рабочее время в течение 2 часов.

Москва Санкт-Петербург Самара

Пошаговая инструкция с фото

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

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

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

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

Первый этап полностью совпадает с обновлением типовой конфигурации 1С. Запускаем режим «Конфигуратор», который доступен только пользователям с полными правами доступа. Во вкладке «Конфигуратор» выбираем пункт «Поддержка» и нажимаем «Обновить конфигурацию».

В следующем диалоговом окне необходимо установить галочку на пункте пункта «Искать обновления в каталогах». Нажмите кнопку «Далее».

Внимание: Обновления 1С доступны только пользователям лицензионных программ «1С:Предприятие», для получения обновлений пользователям ПРОФ версий необходимо дополнительно заключить договор 1С:ИТС (Информационно-технологического сопровождения). Также необходимо зарегистрироваться на сайте технической поддержки пользователей https://users.v8.1c.ru/. Зарегистрироваться на сайте пользователи лицензионных программ 1С могут либо самостоятельно, с помощью инструкции входящей в комплект поставки программы, либо с помощью наших менеджеров.

Внимание: Для многих конфигураций существуют несколько реакций программы (например, Бухгалтерия 2.0 и Бухгалтерия 3.0). При выборе обновления обращайте внимание, на какую редакцию будет выполнено обновление.

В появившемся окне проверьте верность выбранного обновления. Если все данные верны и вы согласны с ними - нажмите кнопку «ОК».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо!