Правильное обновление нетиповой (измененной) конфигурации 1С 7.7

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

Что делать?

Необходимый софт

Порядок обновления

 

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

Часто ли Вас просит заказчик, например, изменить форму документа, добавить пару реквизитов или расширить длину наименования? Что мы при этом говорим: обновлять такую конфигурацию нам нужно будет вручную, осторожно и внимательно, т.к. можно потерять некоторые или все внесенные изменения. И, конечно, это будет стоить «немножко» дороже. Один раз, в далеком 2009-м году я увидел: почему «дороже»: обновлять измененную конфигурацию штатными средствами 1С – это ад.

Ну а изменения в плане счетов чего стоят? Например, счет 631 сделать группой и подчинить под него штук пять субсчетов для учета различных видов деятельности. При обновлении это ведь катастрофа: 1С 7.7, в отличие от восьмёрки, не имеет удобного штатного механизма для объединения изменений и все «доработки» нужно переносить ручками. Кроме того, во всех модулях проведения и модулях формы, где используется счет 631, его нужно заменить на 6311 (например). Допустим, в режиме объединения можно получить куски кода в виде комментариев, а потом вручную принять решение – что оставлять. Но что же будет, если Приходную Накладную обновят и поставщики конфигурации и мы? А что, если мы добавим пару реквизитов шапки и выведем их на форму? Штатный механизм объединения 1С нервно курит в сторонке. Ибо то, что я опишу, избавит от необходимости документировать в текстовых файликах свои доработки и изменения.

Что делать?

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

Необходимый софт

1. gcomp для разборки и сборки файла MD. Огромная благодарность Федору Езееву за столь полезную утилиту.

2. kdiff3 для объединений изменений

3. correct_dlg.pl, входящий в джентельменский набор gcomp

Порядок обновления

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

В рабочей базе идем в константы – номер релиза и смотрим номер.

Также сразу обратим внимание, были ли корректно установлены предыдущие обновления (исправление ошибок неграмотных обновлений – тема для отдельной статьи). Номер релиза в наименовании и в значении должен совпадать.

Значит, у нас есть релиз 7.70.040. Нам нужно обновить его до текущего (7.70.041). Это может быть и на 5-10 релизов позже, не обязательно обновлять по одному. Но в любом случае нам нужно иметь оба релиза поставщика – 040 и 041. Вероятно, может пригодиться подборка всех МД поставщика, выпущенных в последние пару лет.

Следовательно, исходные данные:

Конфигурация 040 – А – папка 040

Конфигурация наша рабочая (доработанная 040) – В – папка 040MY

Конфигурация 041 – С – папка 041

1. Сложим все три МД в соответствующие папки.

2. Разобрать А, В и С на текстовые файлы при помощи gcomp

На выходе получим для каждой конфигурации папки Src.

3. Обработать скриптом correct_dlg.pl (в составе gcomp) все три версии, если разработчики имеют разные темы рабочего стола / разные версии ОС (7 и ХР).

Запуск скрипта:

perl correct_dlg.pl -h

покажет описание параметров

perl correct_dlg.pl -d SRC

исправит все диалоговые формы в каталоге SRC.

И получим примерно такой результат работы скрипта:

4. Загрузить А, В и С в kdiff3, результат объединения – R. Выглядит это примерно так:

Жмем Ок и смотрим, как легко kdiff3 обходит одиночные конфликты самостоятельно. Я бы не сказал, что моя конфигурация «немного» изменена: скорее, в ней не осталось живого места без доработок.

Но с шестью-то конфликтами нам надо будет справиться самостоятельно.

5. Файлы GUIData и Tagstream указать из папки В

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

Жмем F7 и…

По каждому конфликтному файлу увидим сообщение с количеством решенных/нерешенных конфликтов.

Как происходит слияние? Об этом наглядная картинка с конфликтом:

В конфигурациях А и В одинаковы строки, а в С поставщик внес изменения. Эти изменения и переходят в результат, ибо два равны/третий с различиями.

Аналогично, и мои доработки перейдут в результат:

Жмем Ок, проверяем изменения и идем дальше по F7.

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

А вот и пример конфликта:

Сразу отмечу, поле «Является основанием для:» можно смело принимать из любого источника, например, ставить из В. Главное – ссылки.

7. Весьма интересный объект – ИдентификаторыКонфигурации. Я тут всегда выбираю наибольший номер Ид.

8. Файл ОбъектыМетаданных нужно объединить так, чтобы туда вошли все новые объекты В и С. Приоритет кодов Ид отдаем конфигурации В.

9. Выписать список дважды измененных таблиц (А-В есть изменения + А-С тоже есть изменения), с ними работа отдельно. Единственный геморрой на минут двадцать.

10. Собрать МД из папки R. Устранить дубли числовых кодов (максид+1), строки с дублями текстовых кодов удалить.

11. В копии конфигурации a выполнить объединение с R, после удалить удаленные разработчиками объекты. Список удаленных объектов можно получить, объединив назад R с a – в отчет (кратко).

Копируем проще простого:

И объединяем штатной 1С также просто:

И сразу жмем Ок – ведь мы уже объединили все наши доработки.

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

Сообщение об отсутствии ошибок не может не радовать:

12. Вручную объединить дважды измененные таблицы, открыв все три версии в конфигураторе А. Чуть позже расскажу, как пользоваться 1cv81fv – поможет с таблицами.

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

14. Залить через Загрузить измененную в рабочую копию.

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

В общем, вместе с написанием этой статьи, на обновление я потратил два часа. А сколько Вы берете с заказчика за два часа такой работы?

Чего желательно избежать:

1. Удаления объектов, т.к. их трудно искать при объединении с А: механизм объединений 1С не отслеживает переименований.

2. Переименования объектов, так как это будет удаление и создание.

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

4. Объединения изменений без достаточного тестирования В или С.

Не по зубам?Обращайтесь к нам. Берем оплату за проделанный объем работы, а не за просиженные часы у заказчика.

Мухлынин С.М.

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