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

Для обновления я использую две одинаковые копии базы данных старого релиза. В одной из них выполняю подготовку *.cf для обновления, назовем ее, например, for_ updating . Другая база остается не тронутой и служит только как вспомогательная, для сравнения конфигураций, назовем ее base . В принципе, в качестве вспомогательной может использоваться конфигурация рабочей базы.

В базе for_updating выполняем *.cfu нового релиза. Начинается процедура обновления, в результате которой появляется окно обновления.

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

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

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

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

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

Выполняем «Конфигурация » - «Поддержка » - «Настройка поддержки ». В открывшемся окне выбираем «Сохранить в файл » и сохраняем в *.cf конфигурацию поставщика нового релиза.

Основная конфигурация в том виде, в котором она на данный момент имеется, нам не нужна. Закрываем конфигурацию. «Конфигурация » - «Закрыть конфигурацию ». Отказываемся от сохранения изменений.

В конфигурации для сравнения base запускаем сравнение конфигурации поставщика (старый релиз) и конфигурации поставщика из файла (новый релиз).

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

В базе for_updating снова запускаемобновление конфигурации через поддержку «Конфигурация» - «Поддержка» - «Обновить конфигурацию» , в открывшемся окне выбираем *.cfu нового релиза. Начинается процедура обновления, в результате которой появляется окно обновления.

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

При обновлении без нашего вмешательства происходит следующее:

• - объект не изменен нами, изменен в новом релизе - обновляется из нового релиза;
• - объект изменен нами, не изменен в новом релизе - остается наш объект;
• - объект изменен нами, изменен в новом релизе - это и есть дважды измененный объект, если ничего не менять - он загрузится из нового релиза.

Таким образом, наиболее пристальное внимание следует уделить именно дважды измененным объектам, их и будем рассматривать.

В данном примере изменено несколько общих модулей, в том числе и общий модуль « УчетНДС ».

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

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

Если же сравнить эти модули в базе для сравнения base , то картина будет другая:

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

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

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

Например, так:

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

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

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

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

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

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

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

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

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

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

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

Причина тому, добавление справочника «ОсновныеСредства » в план видов характеристик «СвойстваОбъектов ». Если обновить форму элемента справочника «ОсновныеСредства » мы получим неразрешимые ссылки, о чем и будет свидетельствовать окно:

В данном случае самым лучшим вариантом будет не обновлять форму элемента справочника «Основные средства » и уже потом добавить необходимый код в модуль формы элемента. В этом случае окно «Неразрешимые ссылки » при обновлении появляться не будет.

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

В этом случае в процессе объединения появилось бы окно «Неразрешимые салки ». Вариантов выбора в данном окне два: 1) «Пометить все для объединения» ; 2) «Продолжить ».

На мой взгляд, правильнее выбирать «Пометить все для объединения ».

В этом случае план видов характеристик «СвойстваОбъектов » будет добавлен как объект для объединения в дереве во вновь открывшемся окне «Обновление …»

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

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

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

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

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

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

Пример не имеет отношения к данному обновлению конфигурации, но показателен, поэтому рассмотрим его.

В справочник «Контрагенты » добавлено несколько реквизитов, и они помещены на форму элемента.

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

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

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

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

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

В данном случае диалог формы элемента полностью приводится в соответствие с диалогом формы элемента поставщика.

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

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

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

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

После того как проработали все дважды измененные объекты в окне обновления нажимаем «Выполнить »

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

В открывшемся окне «Настройка правил поддержки » проверяем, установленные флаги, хотя по умолчанию должны стоять правильно, нажимаем «ОК ».

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

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

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

В базе for_updating сделаем тоже самое. Контролируем дважды измененные объекты, различий быть не должно.

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

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

09.11.2018

Технология обновления нетиповой (измененной) конфигурации 1С

Инструкция расскажет, как по шагам обновить нетиповую конфигурацию 1С.

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

Технология обновление на примере нетиповой конфигурации УПП с 1.3.95.1 до 1.3.97.3

1. Создать пустую базу и загрузить туда рабочую конфигурацию: «Конфигурация>Загрузить конфигурацию из файла» :

На вопрос об обновлении нажать «Да »:

В окне реорганизации нажать «Принять »:

2. Проверить, стоит ли конфигурация на поддержке: «Конфигурация>Поддержка>Настройка поддержки» :

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

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

Необходимо проверить, что среди поддержек есть та конфигурация, которую необходимо будет обновить (в данном случае «УправлениеПроизводственнымПредприятием ») и у нее правильная версия (в данном случае «1.3.95.1 »). Нужную версию можно узнать, нажав кнопку «О программе ».

Если в списке поддержек нет нужной конфигурации, то нужно поставить конфигурацию на поддержку старой типовой и затем перейти к п.3.

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

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

3. Когда конфигурация стоит на поддержке правильной версии, можно приступать к обновлению. Для этого нужно выбрать «Конфигурация>Поддержка>Обновить конфигурацию» :

В появившемся окне нужно переключиться на «Выбор файла обновления » и нажать «Далее ».

Далее появится окно с информацией о версиях, в нем просто нажать «ОК ». Если вместо этого появилось окно с текстом «Файл не содержит доступных обновлений », значит, была допущена ошибка либо при постановке на поддержку (см. п.2), либо при выборе файла обновления.

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

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

На платформе 8.3.8 и выше нужно в нижней части окна переключить фильтр на «Показывать только дважды измененные свойства »:

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

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

Пример. Дерево после применения фильтра выглядит следующим образом:

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

• Подсистема РегламентированнаяОтчетность – состав
• Общий модуль УправлениеЗапасамиПартионныйУчет
• Общий модуль УчетНДС
• Обработка КлиентБанк – модуль объекта

Формат списка может быть произвольным, главное, чтобы он оставался понятным.

5. Нажать кнопку «Выполнить ».

Если были дважды измененные объекты, то появится предупреждение об их замещении. На него нужно ответить «Да».

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

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

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

В появившемся окне выбрать тип конфигурации «Файл » и указать пути к старой типовой (сверху) и рабочей конфигурации (снизу), затем нажать «ОК ».

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

7. Обновление почти завершено!

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

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

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

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

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

Выгрузка информационной базы завершена:

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

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

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

Окно со справочной информацией, инструкцией и очередностью обновлений:

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

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

Остались только объекты, подходящие под это условие:

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

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

*Давайте разберемся в терминологии:

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

Настраиваем форму отчета и выгружаем его. Список внесенных ранее изменений зафиксирован:

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

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

Принимаем список изменений:*

*Если кнопка «Принять» неактивна, следует запустить «Тестирования исправлений»:



Запускаем через F5 отладку и получаем подтверждение легальности обновлений:

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

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

Определение типа конфигурации

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

Стандартная (типовая) конфигурация – подготовка к обновлению

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

Третий способ происходит чуть позже, на этапе обновления через интернет. Можно все сделать через диск ИТС, которые поступают на предприятие ежемесячно, также этот диск можно взять у сотрудника, имеющего договор с ИТС, только нужно проследить за совпадением конфигураций. В противном случае все выполняется через интернет. Есть важный нюанс: пакеты обновления устанавливаются строго последовательно, и какие-то релизы были пропущены, то система потребует установить вначале их. содержится в меню Справка, где понадобится нажать раздел О программе.
Если с интернетом все в порядке, то требуется зайти на сайт usersv8.1c.ru, в котором вводится логин и пароль. Далее выбираются нужные конфигурации, находящиеся по ссылке Скачать обновления. Следующий шаг – это выбор конкретных релизов, с учетом самых первых и тех, которые выходили недавно. Все файлы по очереди сохраняются на компьютере. Перед обновлением требуется открыть всех архивные файлы, и установить каждый релиз. Релизы можно загрузить, как было описано, и из диска ИТС. Теперь нужно заходить в режим Конфигуратора, после чего слева должны отображаться объекты, если же их нет, то потребуется нажать вкладку Открыть конфигурацию.
Для обновления пользователь переходит в Конфигурация-Поддержка-Обновить конфигурацию. В новом окне нажимается Поиск.

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

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

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

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

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

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

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

Возможные при обновлении 1С

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

Для решения проблемы потребуется:
— менять количество символов в кодах;
— менять коды в информационной базе;
— менять свойство контроля уникальности во всех справочниках.

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

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

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