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), при необходимости нажав «Принять » в окне реорганизации, и выгрузить обновленную конфигурацию: «Конфигурация>Сохранить конфигурацию в файл» .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как в нетиповой конфигурации 1С выполнить обновление.

Общие понятия

При обновлении (update, англ.) нетиповой платформы изменения всегда затрагивают элементы типовой конфигурации (configuration, англ.) поставщика.

В базе данных (БД) содержится до трёх разновидностей конфигураций:

• непосредственно база данных - с ней работают логические алгоритмы;
• рабочая (так называемая основная, КонфигОР) - которую мы периодически изменяем;
• конфигурация поставщика (КонфигП - на её основе создаются пользователем и рабочая, и конфигурация БД.

Если программа сбрасывается с поддержки - от поставщика её уже не будет. Однако тогда неизбежно повышение трудозатрат на обновление. Рассмотрим обновление нетиповой конфигурации 1С. Примером будет платформа УПП (Управление производственным предприятием).

Сведение

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

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

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

При совпадении номеров можно переходить к разделу Получение файла через обновление.

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

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

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

Получение файла поставщика

Для сведения КонфигОР с КонфигП нужен cf-файл из дистрибутива поставщика (той же версии). По умолчанию он будет в C:/Program Files/1cv81/tmplts. Проверим наличие нужного cf-файла в таблице шаблонов. Что делать, если нет нужного файла требуемой версии конфигурации поставщика? Тогда нужно сформировать пустую БД из старой, обновить её до требуемой версии и уже потом использовать.

Получение файла через обновление

Для выполнения update cf-файла КонфигП выбирается в меню команда: «Конфигурация/Поддержка/Обновить…/Выбор файла/Готово/Выполнить» (Последовательно на картинках):

Для решения её нужно снять пометку на удаление с объекта в configuration поставщика. Потом после удаления повторно выполняем сравнение - нажимаем кнопку «Обновить» в окошке обновления.

Восстановление настроек

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

Сохранение и корректировка

Для сохранения КонфигОР и обновления базы данных в пункт меню «Конфигурация» выбираем «Обновить…БД». Здесь встречаем новую проблему:

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

Роли можно просто удалить, т. к. они не изменялись. Реквизит же необходимо переименовать, к примеру, на ЗаказРезерв1. А после обновления внести значения из переименованного в созданный. Ещё одна ситуация при обновлении. Как быть с формами?

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

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

Сохранение изменений рабочей и обновление конфигурации БД: «Конфигурация/Обновить…БД». Перенос значения реквизита ЗаказРезерв1 на ЗаказРезерв осуществляется внешней обработкой режима 1С:Предприятие.

Подготовка баз

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

Сравнение

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

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

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

Проведём предварительную оценку только лишь для уменьшения работ в последующем. Если изменений элемента больше содержится в новой КонфигП - оставляем объект поставщика. Ставим галочку. Переносим изменения из КонфигОР. Если изменений элемента больше содержится в рабочей configuration - оставляем экземпляр объекта КонфигОР. Снимаем галку. Перенесём изменения из КонфигП. Модули нужно сравнивать попроцедурно. Для этого нажимаем кнопку как на рисунке:

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

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

Последующие сравнения выполняем снова во вспомогательной базе. Находим ранее внесённые изменения дополнительным сравнением старой КонфигП с КонфигОР - «Конфигурация/Сравнить…»:

Аналогично сравниваем старую КонфигП с новой. Если файла новой нет, - его теперь можно взять из основной базы.

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

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

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

В сравнительном отчёте различающиеся данные даются в виде списка, из которого не видно какие типы данных добавлялись/удалялись. Если количество строк отчёта достигает двухсот, то процесс «ручного» сравнения представляется довольно трудоёмким (около пятидесяти часов).

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

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

Дальнейшая инструкция действий выглядит так.

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

Работаем с 1С 7.7

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

Также сложностей нет, если в платформу добавлены дополнительные элементы учёта (справочники, константы, отборы, отчёты, регистры, журналы расчётов, пр.). Они уложатся при объединении платформ. Добавленные документы тоже не внесут дисгармонии, если не было изменений признаков для ввода «на основании» таких добавленных документов.

Рекомендуется выполнять update на быстродействующем ПК с большим объёмом оперативки. При её недостатке 1С может отказаться отрабатывать часть функций и «зависнуть». Большой объём виртуальной памяти эту проблему не решает.

Создание архивной копии

Для этой цели нужно воспользоваться опцией: «Администрирование/Сохранить данные…». Удобно указывать имя архива, совместив его с датой создания (например, ГГММДД.zip).

Подготовка каталогов

Для работы потребуется шесть файлов конфигураций (1cv7.md):

1. «РабочийНовый» для подготовки обновления (результирующий md-файл);
2. «РабочийСтарый» по отслеживанию изменений при сравнении и для переноса настроек в ТипНовый_2;
3. Типовая (старая) «ТипСтарый_1». На её основе ранее была создана рабочая.
4. Типов. (прежняя) «ТипСтарый_2». Для отслеживания изменений фирмы 1С в новой типовой версии;
5. Тип. (новая) «ТипНовый_1». Доработки фирмы 1С в новой версии;
6. «ТипНовый_2» для сложных объектов.

И пять запущенных конфигураторов (все кроме «ТипНовый_1»).

Первоначально каталоги попарно одинаковы:

• «РабочийНовый» и «РабочийСтарый»;
• «ТипСтарый_1 и ТипСтарый_2»;
• «ТипНовый_1» и «ТипНовый_2».

Объединение элементов

Сперва проводим сравнение между 3 и 2, 4 и 5, 1 и 6. Для этого каждой из первых в паре выбрать пункт «Конфигурация/Объединение…» и указать файл метаданных 1cv7.md второго в паре. На экране отразится форма с деревом изменённых элементов. Далее необходимо провести анализ результатов попарного сравнения 3 с 2 и 4 с 5. Оставить для объединения элементы в обновляемых платформах (1 и 6), в которых были изменения от фирмы 1С (4 с 5), но не были отражены в 3 и 2. 1 и 4 нужно объединить в режиме замещения.

Прочие

Сюда можно отнести план счетов и пользовательские интерфейсы . Если в плане счетов были изменения, то его нужно обновлять в режиме «Объединение объектов» РабочийНовый вместе с ТипНовый_2. После объединения интерфейса проверяется наличие ошибок: дублирование пунктов меню, дублирование панелей инструментов, установка признаков для панелей инструментов «Расположение с новой строки».

Загрузка выполняется по сети или на сервере (предпочтительнее). Сначала монопольно обеспечивается доступ к БД. А через режим конфигуратора потом загружается база. Перед проведением загрузки и после неё выполняется архивация данных (как описано в самом начале раздела). Далее нужно следовать инструкциям файла UPDATE.TXT. После окончания загрузки все каталоги, кроме РабочийНовый, можно удалить.

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

Оставляйте комментарии, пишите о своём опыте в обновлении 1С.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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