Обновление конфигурации. Как избавить себя от лишних проблем::Журнал СА 4.2009

Андрей Луконькин

Обновление конфигурации.
Как избавить себя от лишних проблем

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

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

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

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

Узнать номер релиза рабочей базы (пусть это будет 1.2.20.2).
Установить типовую конфигурацию такой же версии и сохранить конфигурацию в файл (меню «Конфигурация -> Сохранить конфигурацию в файл»), назовем его «типовая 1_2_20_2.cf».
В конфигураторе рабочей базы провести сравнение (меню «Сравнить, объединить с конфигурацией из файла») с сохраненным нами файлом «типовая 1_2_20_2.cf».
Если получили сообщение «Конфигурации идентичны», значит, нам повезло, используется полностью типовая база и обновить ее можно через меню «Конфигурация -> Поддержка -> Обновить конфигурацию». Если же появилось окно сравнения с указанием отличающихся объектов, то нужно приступать к следующему этапу работы.

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

Обычно я использую режим «4 конфигуратора» (см. рис. 1).

Рисунок 1. Для «тонкого» обновления одновременно используется 4 окна

Что же это такое?

1-е окно конфигуратора: наша рабочая база (номер релиза 1.2.20), которую необходимо обновить. Здесь мы будем частично объединять с типовым релизом, частично вносить что-то руками в модули и править формы.
2-е окно конфигуратора: в нем открыто окно сравнения нашей рабочей базы с типовым релизом той же версии (1.2.20). Таким образом, мы выявим, какие объекты нельзя обновлять автоматически, т.к. они отличаются от типовых. Назовем это «Список».
3-е окно конфигуратора: сравнение типового релиза 1.2.20 и нового типового 1.2.21. Здесь наглядно будут видны все изменения, которые предлагает фирма «1С».
4-е окно конфигуратора: типовая конфигурация нового релиза 1.2.21, чтобы отсюда можно было копировать объекты, процедуры или отдельные куски кода программы.

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

Затем начинается самое интересное – аккуратно вручную обновляем измененные объекты. То есть в 1-м конфигураторе вносим изменения, которые видим в окне сравнения 3-го конфигуратора. Чем 8-я версия платформы выгодно отличается от 7.7, так это тем, что есть возможность видеть различия в модулях с разбивкой по процедурам. То есть выводится не один огромный текст (например, глобальный модуль в 7.7), в котором найти одну-единственную измененную строчку достаточно проблематично, а только те процедуры, в которых были корректировки (см. рис. 2).

Рисунок 2. Окно сравнения модулей. Отображаются только отличающиеся части модуля

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

Как можно облегчить себе жизнь, если часто вносятся изменения в базу?

Для этого, во-первых, в номере релиза измененной базы ставится отличительный знак, например «*». Это будет означать, что конфигурация отличается от типовой, и тогда не придется ломать голову в попытках вспомнить «меняли мы тут что-то или нет».

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

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

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