gifts2017

Обновление изменённой типовой конфигурации 1С 8.2/8.3

Опубликовал Джо Неуловимый (get-start) в раздел Программирование - Практика программирования

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

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


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


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

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


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

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

 

 

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


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

Рис. 3: Перенос изменений в обновлённую конфигурацию

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


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

Рис. 4: Сравнение изменений конфигураций ДО и ПОСЛЕ обновления

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


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


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

Рис. 5: Показать различия в модулях.

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

Рис. 6: Сравнение модулей.

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

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

Рис. 7: Перенос изменений

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

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


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

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


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


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

 

Оригинал статьи находится на сайте  get-prog.ru

См. также

Подписаться Добавить вознаграждение

Комментарии

1. softcom (softcom_1c) 30.12.15 18:58
Зачем же так сложно? Использовать "Поддержка/ Обновить конфигурацию" и анализировать расхождения нового релиза с текущей конфигурацией (зеленые карандашики и фильтр "дважды измененные" не просто так) - гораздо быстрее и проще.
fomstas; angur; CratosX; IgorS; fancy; alest; alexstav; Batman; Натц; mpudy; Infector; paybaseme; freez1301; 32ops; mrXoxot; echo77; +16 Ответить 2
2. Джо Неуловимый (get-start) 31.12.15 07:57
(1) softcom_1c, я "вырос" на конфигурациях семёрки и, соответственно, методы, к которым я привык, именно "от туда"... насколько я знал, варианты при обновлении в восьмёрке лишь "приоритетные" (либо одно изменение, либо другое). про анализ/сопоставление - не знал. спасибо за информацию, если оно так на самом деле: попробую/проверю
3. Albert A (albert) 31.12.15 11:15
Это больше похоже на текст из серии "Вредные советы" !
Хотя бы изучили, какие уже материалы есть здесь http://infostart.ru/public/18562/ , http://infostart.ru/public/283282/ и т.п.
4. Влад Кайзер (Torin) 31.12.15 14:02
(2) Не проще ли свою поставку сделать? И пусть будет конфигурации на поддержке у двух поставщиков!!!

"...Сравнивать эти файлы мы будем с помощью файлового менеджера Total Commander и его встроенных инструментов.."

А чем Сравнить файлы не устраивает?

5. Алексей Папанов (El_Loco) 31.12.15 19:56
очень запутанно для новичка. а для опытных сие бесполезно.
абзацы на весь экран вообще пугают.
6. Александр (МимохожийОднако) 01.01.16 12:06
Плюсанул за попытку. А кто читал комментарии - выйдет и на другие материалы.
7. Джо Неуловимый (get-start) 01.01.16 22:11
(3) albert, по ссылкам - насколько я понял (1 января), там идёт настройка переноса с помощью замещения. то есть - так или иначе, либо изменения обновления полностью замещают изменения конфигурации, либо изменения конфигурации полностью замещают изменения обновления. то есть - в том сравнении НЕТ возможности редактировать модуль. мой способ (с помощью Total Commander-а) предполагает эту возможность. поэтому - ничего вредного тут не вижу. наоборот - сплошная польза!
8. Джо Неуловимый (get-start) 01.01.16 22:13
(4) Torin, "А чем Сравнить файлы не устраивает? "

во-первых - алгоритм сравнения у tc намного корректнее, чем у конфигуратора 1с. поэтому сравнения более удобно проводится (для понимания, в чём различия)... ну и во-вторых - сравнивая в 1с у нас нет возможности "слёту" переносить необходимые нам изменения...
9. Джо Неуловимый (get-start) 01.01.16 22:23
(6) МимохожийОднако, спасибо за плюс. поскольку этим способом я много успешно пользовался, то уверен, что он кому-то будет полезен тоже.
10. Алексей Драчков (Bassgood) 03.01.16 12:27
(7) get-start, с версии 8.3.6 можно вносить изменения в модули прямо во время их сравнения/объединения + возможность использования других сторонних программ для сравнения
Shmell; CratosX; okulus; get-start; +4 Ответить 2
11. Джо Неуловимый (get-start) 03.01.16 18:47
(10) Bassgood, это хорошо... если у 1с с первого раза получилось всё корректно (подключение сторонних программ), то можно лишь оставить принцип сравнения, сильно упростив все механизмы... то есть - здесь предлагается способ и как инструмент - tc, за неимением встроенного... но тем не менее, насколько я слышал - в этой платформе (8.3.6) сильно всё изменилось и так просто даже на неё бывает не перейти (если имеются доработки в конфигурации)... поэтому многие даже не смогут протестировать эти нововведения в ближайшее время.
12. Джо Неуловимый (get-start) 06.01.16 16:21
(1) softcom_1c, поскольку первый комментарий во многом определил последующие и стал "топовым", то подведу некое резюме в ответе на него... ознакомившись и учитывая комментарий (10) от Bassgood (спасибо за информацию) - получается, что 1С только начинает внедрять способ изменения при сравнении... то есть - только начиная с платформы 8.3.6 имеется возможность сравнивать/анализировать с редактированием (даже используя подключённые внешние программы). насколько это корректно/удобно - это надо ещё проверять на деле. до этого релиза платформы - можно было ТОЛЬКО сравнивать/анализировать, без возможности редактирования. причём - сравнение производилось алгоритмами 1С, которые сами по себе являются не совсем корректными, что приводит к достаточно сложным (для понимания и анализа) результатам сравнения... поэтому в принципе, если платформа ниже 8.3.6 - инструментами 1С не сделать того, что предлагается в данной статье. но даже имея указанную платформу (и выше) - статья имеет своё место быть, как алгоритм переноса изменений и альтернатива для "встроенного" варианта, если на платформе будут возникать какие-то проблемы с подобными обработками...
13. Ярослав Радкевич (WKBAPKA) 06.01.16 18:18
Блииииин... сколько обновляю никогда не додумывался до такой ацкой сложности )))
vx_gas; IgorS; +2 Ответить 1
14. Ярослав Радкевич (WKBAPKA) 06.01.16 18:20
хотя... хорошая статья. если клиент спросит: почему так дорого? сразу показываем эту статью, поднимаем указательный палец вверх, поправляя очки со словами... это вам не что либо как, а как либо что )
15. Джо Неуловимый (get-start) 06.01.16 19:02
(13) - (14) WKBAPKA, конечно, привычным методом всегда удобнее/быстрее - против этого не поспоришь... НО

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

2. данный метод никак не задействует внимание обычно подобные обновления требуют высокой степени внимательности и при такой монотонной работе это внимание может рассеиваться, что приведёт к ошибкам обновления. данный метод полностью алгоритмизирует действия в связи с этим (делай раз - делай два - ...) внимание можно не так напрягать и ошибки практически исключены.

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

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

как-то так, например.
16. Андрей Акулов (DrAku1a) 11.01.16 07:18
0. Сделать бекап перед обновлением
1. Сохранить текущую конфигурацию (A)
2. Сохранить конфигурацию поставщика (Б)
3. Обновить конфигурацию*
4. Сохранить обновлённую конфигурацию поставщика (В)
5. Выполнить сравнение конфигураций: сравнить А и Б
6. Выполнить сравнение конфигураций: сравнить Б и В
7. Перенести из конфигурации А объекты, не измененные при обновлении (их нет в сравнении Б и В)
8. Для измененных объектов - проанализировать, что именно изменялось и продублировать изменения (как вариант - "попроцедурное" обновление).
* - настоятельно рекомендуется не обновлять сразу конфигурацию ИБ
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа