Личный опыт: как быстро и без лишних затрат обновить измененную конфигурацию
Обновлять конфигурацию сразу на несколько релизов весьма опасно. Дело в том, что после каждого обновления конфигурации запускается обновление информационных баз в режиме "1С:Предприятие". Поэтому если актуализировать только последний релиз, информационные базы могут не соответствовать последней конфигурации. В статье Дмитрий Рудаков, специалист компании ЗАО "Сибирская Аграрная Группа", делится личным опытом по единовременному обновлению конфигурации на 12 релизов.
Проверка режима изменения конфигурации
Представим себе такую ситуацию. Разработчики "Управления производственным предприятием" (далее - УПП) в релизе 1 (номера релизов здесь и далее присвоены условно) измерению (показателю) регистра расчета назначили тип "СправочникСсылка.ФизическоеЛицо" с наименованием "ФизЛицо". В релизе 2 они добавили еще одно измерение - "Сотрудник" с типом "СправочникСсылка.Сотрудники". При запуске "1С:Предприятие" включается обработка, которая заполняет измерение "Сотрудник", соответствующим измерению для "ФизЛица" образом. И потом в релизе 3 разработчики "1С" удалили измерение "ФизЛицо" и оставили только "Сотрудник". Если обновить конфигурацию с релиза 1 сразу до релиза 3, то можно очистить весь регистр расчета.
А если конфигурация стоит на поддержке с возможностью изменения, и в этой же базе данных формируется регламентированная отчетность, то необходимо обновлять конфигурацию на каждый релиз, что может быть очень дорого в человеко-часах. Например, обновление сильно измененной "УПП" на 1 релиз может занять 30 часов рабочего времени опытного специалиста.
Поэтому прежде чем приступать к обновлению, нужно определить: работаете вы в типовой конфигурации с возможностью изменения или в конфигурации без возможности изменения? Для этого зайдите в конфигуратор, где в меню выполните действия "Конфигурация - Поддержка - Настройка поддержки".
Рис.1. Вызов окна настройки поддержки конфигурации
Если установлено "На поддержке", то эта конфигурация типовая, а если "Включена возможность изменения" - конфигурация, скорее всего, изменена (по крайней мере, такая возможность заложена). Третье состояние - "Конфигурация снята с поддержки". Различные состояния конфигурации показаны на рисунках 2, 3, 4.
Рис. 2. Типовая конфигурация без возможности изменений
Рис. 3. Типовая конфигурация с включенной возможностью изменения
Рис. 4. Конфигурация, снятая с поддержки
Алгоритм обновления измененных конфигураций
Недавно передо мной встала задача обновления измененной конфигурации "Управление торговлей", релиз 10.3.13.2. Конфигурация была изменена в результате объединения с отраслевым решением "БИТ: Управление автосервисом 8" и непрерывно дорабатывалась в течение двух лет. Теперь конфигурацию нужно было обновить до релиза 10.3.25.1, то есть на 12 релизов. Я разбил всю процедуру обновления на несколько этапов.
Этап 1. Оценка стоимости и сроков процедуры обновления
Прежде чем приступать к самостоятельной работе, я решил получить независимую оценку специалистов в этой области. Единственная компания, располагающая возможностью обновления измененных конфигураций автоматизированными методами, это ООО "1С-ИжТиСи". Я обратился к специалистам этой компании с просьбой оценить стоимость обновления моей конфигурации. Для оценки времени и стоимости работ я предоставил текущую конфигурацию, нуждающуюся в обновлении. Через день я получил письмо с отчетом.
Отчет по итогам оценки стоимости и сроков проведения обновления конфигурации:
Конфигурация: Управление торговлей, редакция 10.3
Текущая версия конфигурации: 10.3.13.2
Обновление до версии: 10.3.25.1
Количество обновляемых модулей: 1 847
Количество контрольных релизов: 8
Результаты оценки меня удивили, поскольку на сайте компании была указана стоимость по акции - 1000 руб. за обновление на один релиз. Комментарий "1С-ИжТиСи":
"Стоимость обновления на каждый пропущенный релиз у нас не выше 2000 рублей. Сейчас проходит акция, поэтому стоимость не превышает 1000 руб. Но окончательная цена услуг определяется по результатам оценки трудозатрат на обновление и может быть ниже 1000 руб./релиз".
Также я уточнил, каким образом были выбраны релизы, необходимые для обновления. В ответ на свой вопрос я получил скриншот, на котором это было наглядно продемонстрировано (рис. 5). В столбце "Номер версии" указана версия конфигурации, до которой необходимо обновиться. В столбце "Обновление версии" указано, с какого релиза возможно обновление. В результате оценки количество необходимых обновлений сократилось до 9.
Рис. 5. Выбор релизов, которые обязательно нужно использовать для корректного обновления конфигурации
После изучения отчета "1С-ИжТиСи" я подсчитал личные временные затраты на тот же самый объем работы. Каждая процедура обновления занимает у меня приблизительно 6 часов. Следовательно, общие временные затраты составляют 56 (9х6) рабочих часов, то есть приблизительно семь рабочих дней. Кроме того, существует вероятность, что после обновления выявятся какие-то недочеты: к примеру, пользователь пожалуется, что нужные для него изменения в конфигурации утеряны, и тогда временные затраты серьезно увеличатся. Между тем, специалисты компании "1С-ИжТиСи" предлагают проделать весь объем работы за три-четыре рабочих дня. Поэтому я решил воспользоваться их услугами.
Теперь кратко поясню, что именно было изменено в конфигурации.
Сильно измененные объекты. Это объекты, в которых изменено много типовых свойств. Корректировки имеют комплексный характер. Реквизиты объекта добавлены в табличную часть, выведены на форму объекта и на форму списка. Дописаны обработчики добавленных реквизитов в формах. Изменен типовой механизм проведения документа или записи набора движения для регистра.
Сильно измененные документы:
"Заказ поставщику";
"Перемещение товаров";
"Требование-накладная";
"Поступление товаров и услуг".
Сильно измененные регистры:
"Партии товаров на складах";
"Товары на складах".
Значительно измененные объекты.
Объекты, в которых добавлены реквизиты, изменены либо формы объектов, либо модули объекта (как правило, проведение документа нетиповое).
Документ "Приходный кассовый ордер";
Регистр сведений "Комплектующие номенклатуры";
Регистр сведений "Списанные товары";
Общие модули.
Незначительно измененные объекты. В объектах изменены только формы и добавлены реквизиты.
Справочники:
"Виды номенклатуры";
"Договоры контрагентов";
"Контрагенты";
"Номенклатура";
"Типы цен номенклатуры";
"Ряд регистров сведений".
В разделе "Общие" изменены подписки на события, макеты, роли, общие модули. Почти все было изменено отраслевым решением.
Этап 2. Удаление конфиденциальной информации
Прежде чем предоставлять сотрудникам "1С-ИжТиСи" информационную базу для тестирования, в ней нужно удалить конфиденциальную информацию. Для таких случаев фирма "1С" рекомендует использовать обработку "Изменение конфиденциальной информации", которая не очень широко известна.
Обработка "Изменение конфиденциальной информации" предназначена для выборочного изменения или очистки информации в информационной базе. Обработку можно использовать для подготовки информационной базы перед передачей на тестирование, где необходимо скрыть (очистить, изменить) некоторую информацию.
Обработка ИзменениеКонфиденциальнойИнформации.epf есть на диске ИТС в каталоге 1CIts\EXE\EXTREPS\UNIREPS81\UpdatePrivateInformation. Также данную обработку можно скачать по ссылке: http://its.1c.ru/db/metod81#content:1644:1.
Естественно, конфиденциальная информация в каждой компании разная, но обращаю ваше внимание на данные, которые, вероятнее всего, нужно изменить:
- Справочники: Физические лица, Контактные лица, Контактные лица контрагентов, Контрагенты, Типы цен.
- Регистры сведений: Паспортные данные физического лица, ФИОФизЛиц.
Ваш список, вероятно, будет шире, но это наиболее распространенные данные. Их изменение вряд ли повлияет на возможность тестирования вашей информационной базы. Также можно групповой обработкой удалить все те объекты, работа с которыми обслуживающей компанией не предполагается.
Этап 3. Получение результатов обновления
Через три дня мне предоставили cf-файлы и исчерпывающие инструкции по их установке. Для контрольных релизов предоставляются cf-файлы, которые нельзя использовать для работы пользователей, так как в них обновлены только метаданные. Они предназначены только для корректного обновления на последнюю версию.
По результату проведенной работы могу сказать, что все изменения в конфигурации были сохранены, при визуальном просмотре все объекты, которые были изменены, сохранили свои особенности и отличия от типовой конфигурации. В ходе эксплуатации никто из пользователей не сообщил, что какие-то изменения были утрачены.
В результате обновления я выделил две небольшие задачи для самостоятельного решения.
Первая. В силу того, что обновление проводится с использованием механизма "Сравнение, объединение", конфигурация БД действительно обновляется, и обновляется правильно, без технических рисков благодаря учету контрольных релизов. Однако не обновляется конфигурация поставщика. Разумеется, технически грамотный специалист без проблем дополнит данную работу, однако я попросил "1С-ИжТиСи" выслать более полную инструкцию по обновлению. В соответствии с ней, обновление сможет произвести даже неопытный специалист.
Вторая. В результате обновления все объекты остаются на поддержке с возможностью изменения, что тоже может быть косвенным недостатком. Если нужно воспользоваться этими услугами единовременно, тогда нужно все объекты снова ставить на поддержку. Сделать это у меня пока получается только перебором всех объектов метаданных. К сожалению, пока этот процесс выполняется вручную, но в будущем и он будет автоматизирован.
Кроме двух названных задач, был обнаружен один небольшой недочет, который, в принципе, не влияет на качество обновления и редко проявляется. В результате обновления строки кода исходной конфигурации и обновленной визуально совпадают, но в конце строк по каким-то причинам добавлены пробелы. Это является недостатком, так как несколько увеличивает объем измененного кода. И в случае дальнейшего ручного обновления было бы лучше не иметь таких участков кода. На рис. 6 приведен пример до обновления, а на рис. 7 - пример после обновления.
Инструкция
Выберите две базы – рабочую и ее копию. В последней выведите изменения, отличающие ее от стандартной конфигурации программы, которая имеется в начале работы с программой после ее установки.
Создайте файл.cf, поскольку сайт производителя предоставляет пользователям только файл.cfu. Он пригодится вам для выполнения следующего шага, связанного непосредственно с обновлением измененной конфигурации.
В рабочей базе зайдите в меню «Поддержка», затем нажмите на пункт «Обновление конфигурации», выберите предварительно созданный.cf файл. В появившемся окне сравнения копии базы уберите галочки с тех пунктов, которые вы недавно обновляли.
Сравните и объедините данные при помощи меню «Поддержка». В опции «Настройка поддержки» будет подпункт «Сравнить и объединить». Обратите особое внимание, что в этом случае вы должны только сравнить и объединить данные, не ставя чекбоксы. Эта операция необходима лишь только для целей наведения порядка и выявления последовательности последовательность объектов в текущей конфигурации с порядком и последовательностью объектов, находящихся в файле обновления.
Далее снова зайдите в те же пункты меню в «Поддержке», заново выполните операцию «Сравнить и объединить», абсолютно так же, как и в прошлый раз. Выполните работу над объектами, проанализируйте результаты, сравните выявленные рабочей базы от копии, а в копии базы уточните именно те пункты, которые изменяли. Перенесите изменения из новой конфигурации поставщика. Выполните сохранение изменений посредством нажатия клавиши F7.
Повторите вышеперечисленные действия несколько раз, прежде, чем примитесь за работу с настоящими рабочими базами данных. Помните, что чем больше раз вы выполните эту последовательность до начала работы непосредственно с важными для вас данными, тем лучше.
Обратите внимание
Добавленные вами объекты конфигурации изменять нельзя, вы можете потерять данные.
Тренируйтесь в обновлении на копиях, не приступайте к работе без определенных навыков.
Конфигурации для приложения "1С: Предприятие" существуют типовые и нетиповые. Типовая конфигурация выпускается разработчиком и используется конечным пользователем в изначальном виде, а нетиповая может быть написана с «нуля», либо доработана на основе типовой.
Инструкция
Определите, какая именно конфигурация программы "1С: Предприятие" установлена на вашем компьютере, так как способы обновления конфигурации будут разными. Если вы используете типовую конфигурацию, тогда вам необходимо просто выполнить действие «Загрузить измененную конфигурацию». Если вы являетесь обладателем программы, тогда выполните следующие действия.
Подготовьте для обновления конфигурации следующие объекты. Во-первых, у вас должна быть установлена сама конфигурация. Во-вторых, найдите типовую конфигурацию того релиза, который вами используется. В-третьих, вам потребуется найти типовую конфигурацию последнего релиза той версии, которую вам необходимо получить в результате обновления. В-четвертых, сделайте копию файла конфигурации вашей установленной версии программы "1С: Предприятие".
Рассмотрим обновление на примере нетиповой конфигурации УПП 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 будет завершено обновляем конфигурацию базы данных и тестируем некоторые моменты, что именно хорошо бы протестировать станет понятно в процессе обновления, тут все индивидуально.
Обновление в рабочей базе желательно выполнять с помощью поддержки «Конфигурация» - «Поддержка» - «Обновить конфигурацию». При этом дважды измененные объекты будут загружены из нового релиза, т.е. наши изменения затрутся (конфигурацию не сохраняем!), но потом при объединении с подготовленной конфигурацией мы их восстанавливаем. После этого можно сохранить конфигурацию, обновить конфигурацию базы данных.
Инструкций по обновлению изменённых типовых конфигураций платформы 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 затрагиваются только те объекты конфигурации, которые реально изменились в новом релизе. В результате, если такой объект изменялся нами, то после обновления он полностью заменится на типовой, и нам будет необходимо повторить в нём те изменения, которые были у него до обновления так, чтобы этот объект содержал и наши изменения, и изменения нового релиза, одновременно. Но зато если изменённый нами объект конфигурации не затрагивался обновлением - в нём останутся наши изменения после обновления. Чтобы проще это понять - изображу это в виде схемы:
На данной схеме изображена некоторая типовая конфигурация в процессе изменения и обновления. Строки - это её объекты (документы, справочники, обработки и так далее). Сначала (под номером 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..."). В открывшемся окошке слева/справа отображается соответственно содержимое файлов, кнопки "Следующее отличие"/"Предыдущее отличие" позволяют искать различия. Этот инструмент позволит быстро найти интересующие нас объекты.
Замечание : может случиться и обратная ситуация - в конфигурации ПОСЛЕ обновления появились различия, которых не было ДО обновления. Это означает, что релиз обновления удалил из конфигурации соответствующие объекты. В принципе, эти объекты можно просто пропускать в наших исправлениях, посколько в этих объектах не было изменений.
2.2. Внесение изменений в обновлённые объекты. После того, как мы нашли объект с затёртыми изменениями, надо определить, где именно были эти изменения: в модуле (программном тексте), диалоговом окне (на форме) или иных настройках. Здесь я буду разделять два случая: изменение в модуле и все другие изменения. И рассмотрим эти два случая отдельно.
2.2.1. Затёртые обновлением изменения были в модуле. На самом деле, это основной случай (такое встречается намного чаще) и этот случай как раз в нашем примере: изменение удалились в модуле "УчётНДС". Как выше мы уже напоминали, что в Конфигураторе рабочей базы у нас открыто окно сравнения конфигураций. Ищем там необходимый нам объект. На самом деле, его положение в дереве конфигурации описано в нашем текстовом файле, а именно: "ОбщийМодуль.УчетНДС.Модуль". Именно так и ищем в окне сравнения. Разворачиваем дерево подчинённостей пока не найдём нужный модуль - с левого края напротив него должен быть зелёный карандаш, показывающий, что объект изменён по сравнению с конфигурацией поставщика. По найденной строке кликаем правой кнопкой мышки и выбираем "Показать различия в модулях...":
После этого откроется окно сравнения модулей:
Здесь, в верхней части указаны процедуры
и функции
, в которых имеются изменения (в нашем случае - это одна процедура "ВывестиСчетФактуруВТабличныйДокумент"), а в нижней части - тексты выбранной процедуры или функции с выделенными изменениями. Нам нужно эти изменения перенести в нашу тестовую базу. Но при этом не удалить изменения от обновления. Автоматизировать это можно следующим образом. Устанавливаем курсор в левую нижнюю часть (где текст выбранной процедуры с нашими изменениями) и жмём последовательно 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". В окне сравнения есть кнопка "Редактирование": нажмём её в сравнении первой пары. Теперь поясним, что мы видим. В первой паре сравнения видны объекты и от нашего изменения, и от обновления. В соответствии, какой у нас случай, нам надо перенести изменения только наши, либо только обновления. Во втором окне сравнения - как раз видны только те изменения, которые мы должны перенести. Если обратить внимание - в обоих случаях, второй файл и первого, и второго сравнения - один и тот же. Поэтому мы ориентируемся на строки в этом файле, и по строкам во втором сравнении, вносим изменения в окне первого сравнения: нажатая кнопка "Редактирования" как раз позволит нам это сделать.
Для "наглядности" изобразим графически действия при переносе в первом случае (изменяем обновлённый файл, внося наши изменения):
Действия во-втором случае - абсолютно аналогичны и принцим действия ровно такой-же.
Самый сложный и неприятный случай - когда наши изменения и изменения обновления - в ОДНОМ месте. То есть реально на одном сегменте кода были два изменения. В таком случае требуется вмешательство программиста. Так же вмешательство программиста, но в меньшей степени, требуется, если, например, обновлением изменены имена переменных, которые используются в наших изменениях. Стоит заметить так же, что в файле "old_type.txt", либо "old_izm.txt" могут быть пустые строки - это "следа" наших измений. Переносить надо так, чтобы в конечном файле их не было. На функциональность это не влияет, но в дальнейших сравнениях (при последующих обновлениях) - это немного затруднит анализ действий. Итак, после того, как мы сформировали четвёртый файл, перенеся все изменения - надо его содержимое скопировать в конфигурацию. В Конфигураторе тестовой базе, должен быть открыт нужный модуль на новом месте: удаляем существующую процедуру и вставляем содержимое нашего конечного файла, с учётом всех пробелов между предыдущими/последующими функциями. Таким образом мы перенесли изменения ОДНОЙ процедуры найденного объекта. У нас (рис. 6) эта процедура действительно одна. Если таких процедур несколько - описанные действия надо проделать для каждой. Если процедура новая (только в левой половинке) - то просто добавить её в соответствующий модуль в тестовой базе (для корректности дальнейшего сравнения - нужно сохранить порядок процедур, как в соответствующем модуле рабочей базы, где ещё старый релиз).
2.2.2. Затёртые обновлением изменения были НЕ в модуле. Для переноса таких изменений подобное сравнение никак не упростит работу, поэтому переносятся изменения просто визуальным сравнением объектов в рабочей и тестовой базах.
Таким образом - переносим изменения для каждого объекта, где наши изменения затёрлись обновлением. Чтобы проверить, насколько мы верно перенесли все изменения - сохраняем конфигурацию в тестовой базе, выгружаем сравнение конфигураций в файл "ОтчетОСравнении_new2.txt" и сравниваем с файлом "ОтчетОСравнении_old.txt". Если всё идиально, то будет сообщение "Файлы идентичны". Если обновлением были удалены какие-то объекты - то при правильном переносе изменений будут видны только эти объекты в различии. Правильным будет если в сравнении будут видны только пробелы/пустые строки/табуляции, но в таком случае лучше это вычищать и добиваться сообщения "Файлы идентичны". Таким образом, после сохранения изменений в тестовой базе, выгружаем сравнение в файл и сравниваем с изменениями в старом релизе - повторяем это до тех пор, пока сравнение не покажет, что мы перенесли все требуемые изменения.
3. Переносим обновлённую конфигурацию из тестовой в рабочую базу . На предыдущих этапах мы обновили тестовую базу до последнего релиза, проверили и перенесли необходимые изменения и сохранили полученную конфигурацию. Теперь мы её выгружаем в cf-файл и загружаем в рабочую базу. Перед загрузкой - необходимо сделать копию рабочей базы и снять с поддержки конфигурацию. ВСЁ. Пользователи "бездельничали" только в начале, когда мы выгружали базу, и в конце, когда мы снова выгружали базу и загружали конфигурацию.
На этом обновление полностью завершено.
Оригинал статьи находится на сайте
Программные продукты 1С являются специфическими в том смысле, что на их работу очень сильно влияет законодательство страны, в которой эти программы используются. Именно поэтому очень важно уметь обновлять эти продукты, так как кроме законодательных вопросов, обновленные конфигурации будут содержать исправление критических ошибок, ускорение всей работы программы и прочие полезные детали. Есть два варианта развития событий: первый вариант представляет собой обновление стандартной(типовой) конфигурации, что происходит достаточно быстро и не требует особых усилий, второй же вариант, когда обновить нужно модифицированную сборку, является более долгим и сложным.
Определение типа конфигурации
Обычно, пользователь точно знает, какая у него версия, так как стандартная сборка характеризуется отсутствием вмешательства во внутренние объекты программы. Другое дело, что модификацией, как правило, занимаются программисты, соответственно, пользователю поступает уже измененный продукт, о чем он может и не догадываться. Есть простой способ, позволяющий понять, вносились ли изменения туда или нет. Для этого потребуется зайти в режим Конфигуратора, соответствующая кнопка которого есть в стартовом окне программы. Там вверху есть вкладка Конфигурация, в которой есть пункт Поддержка. После нажатия на нее следует выбрать Настройку поддержки. В открытом окне должна быть активной кнопка «Включить возможности изменения», также признаком стандартной сборки является наличие иконки замка возле названия сборки. Эти признаки свидетельствуют о том, что модули программы не менялись, значит, можно выполнять централизованное обновление с официального сайта через интернет. При отсутствии этих признаков можно утверждать, что программист работал над правкой этого продукта, при этом, возможна ситуация, когда модификация была частичной, то есть, ряд объектов были оставлены в первоначальном виде. Все модифицированные объекты остаются без опознавательных пиктограмм, а стандартные элементы помечаются желтым кубом. Частичная модификация не снимает программу с поддержки полностью, так как возможность обновлять нетронутые объекты будет.
Стандартная (типовая) конфигурация – подготовка к обновлению
Кроме указанных проблем, вроде изменения законодательства или ухудшения быстродействия программы, обновить ее нужно тогда, когда программа 1С выдает соответствующее сообщение. Там будет сказано, что данная сборка была выпущена какое-то время назад, сейчас есть улучшенная конфигурация, и что ее можно обновить прямо сейчас через сайт или с помощью диска ИТС. Для начала очень важно сделать резервную копию базы, чтобы можно было все восстановить, если что-то пойдет не так. Выполняется это тремя способами. Можно просто скопировать корневую папку с базой на диск или флешку. После запуска 1С выбирается база, а в окне будет указан путь к ней. В случае проблем эта папка перемещается на место неработающей базы. Действовать можно и через конфигуратор, для чего нужно выбрать в программе этот режим. В разделе Администрирование есть кнопка Выгрузить информационную базу. После выбора папки, там появиться файл.dt, который впоследствии можно открыть соответствующей кнопкой в том же разделе.
Третий способ происходит чуть позже, на этапе обновления через интернет. Можно все сделать через диск ИТС, которые поступают на предприятие ежемесячно, также этот диск можно взять у сотрудника, имеющего договор с ИТС, только нужно проследить за совпадением конфигураций. В противном случае все выполняется через интернет. Есть важный нюанс: пакеты обновления устанавливаются строго последовательно, и какие-то релизы были пропущены, то система потребует установить вначале их. содержится в меню Справка, где понадобится нажать раздел О программе.
Если с интернетом все в порядке, то требуется зайти на сайт usersv8.1c.ru, в котором вводится логин и пароль. Далее выбираются нужные конфигурации, находящиеся по ссылке Скачать обновления. Следующий шаг – это выбор конкретных релизов, с учетом самых первых и тех, которые выходили недавно. Все файлы по очереди сохраняются на компьютере. Перед обновлением требуется открыть всех архивные файлы, и установить каждый релиз. Релизы можно загрузить, как было описано, и из диска ИТС. Теперь нужно заходить в режим Конфигуратора, после чего слева должны отображаться объекты, если же их нет, то потребуется нажать вкладку Открыть конфигурацию.
Для обновления пользователь переходит в Конфигурация-Поддержка-Обновить конфигурацию. В новом окне нажимается Поиск.
Из предложенных вариантов выбирается Поиск в текущих каталогах обновлений, после этого указывается доступный релиз или же тот, название которого будет выделено жирным. На все остальные предложения нужно нажимать Да, включая последнее окно Реорганизация информации. Финальным шагом является запуск программы в рабочем режиме, чтобы обновления вступили в силу.
Обновление нетиповой (модифицированной) конфигурации 1С
Смысл обновления измененной сборки в том, чтобы и выполненные изменения со стороны программистов не были утеряны, и изменения со стороны разработчиков вступили в силу. Все перечисленные шаги, описанные в прошлой инструкции, выполняются и в этот раз, только на финальном шаге появится сравнительная таблица, где в одном столбике будет конфигурация с модифицированными объектами, а во втором столбике будет список обновлений. В этих колонках присутствует деревья метаданных. Зеленым маркером программа отметит, в какие конкретно объекты программист вносит коррективы, а в какие вносили изменения разработчики продукта. На данном этапе нужно найти те объекты, которые отмечены в двух этих столбцах.
Для упрощения поиска можно воспользоваться кнопкой Фильтр, которая располагается снизу, после чего пометить флажком опцию Показывать дважды измененные свойства. Если все будет сделано правильно, то в рабочем окне будут высвечиваться только нужные нам объекты. Процедура обновления нетиповых модулей не затронет конфигурацию.
Нужно проанализировать эту таблицу. В данном случае понятно, что изменения произошли в обоих случаях, так как есть значки карандаша, так как возле названия модуля тоже есть значок, это означает, что произойдет их слияние. Последний столбец справа свидетельствует о том, что при завершении процесса весь пользовательский код будет изменен в пользу обновления от разработчиков.
Существуют другие режимы с частичным объединением (приоритетом), но этими режимами пользуются опытные пользователи, так как новичок превратит все наработки в запутанные модули. Соответственно, что то менять в последнем столбце, смысла нет. С другой стороны, убрав галку в первом столбике, принудительное объединение можно и отменить. Исходя из этого, можно или вручную внести код в обновленный модуль, или же не трогать код, и вручную вносить сами обновления. Чтобы понять, что конкретно потребуется внести, следует на выбранном модуле нажать правой кнопкой мыши и выбрать пункт Показать различия. Этот шаг покажет различия в конкретных процедурах. Внизу окна есть также разделение на два столбца, но там уже отображается сам код.
Дальнейшие действия зависят от уровня изменения модулей, если конфигурация была переписана кардинальным образом, то самостоятельно все обновить, без помощи программиста, будет крайне трудно.
Возможные при обновлении 1С
Больше всего ошибок допускается тогда, когда база является сильно модифицированной, так как несколько страниц кода, всевозможных справочников и прочих объектов, могут неопытного пользователя запутать. Очень важно перед какими-либо изменениями создавать и сохранять архив для резервного восстановления, после чего еще раз убедиться, что все было сделано правильно. Классической ошибкой является обновление нетиповой сборки, как будто она является стандартной. Но даже если следовать описанным инструкциям, далеко не факт, что программа сразу же заработает так, как это нужно. Вероятно, что без дополнительной настройки не обойтись. Конфигуратор не выводит выполненные изменения в элементах управления диалоговых форм, соответственно, этот момент придется проверять вручную, иначе обновления все это затрет. После обновления, конфигуратор может выводить запрет на обновление старой информационной базы, так как номера документов перестают быть уникальными , это же относится и к регистрам сведений.
Для решения проблемы потребуется:
— менять количество символов в кодах;
— менять коды в информационной базе;
— менять свойство контроля уникальности во всех справочниках.
В процессе обновления нельзя забывать про обновления интерфейсов и прав пользователей, что часто упускается из вида. Уже описывалась важность именно последовательного обновления релизов, также крайне важно применять встроенной обработкой обновления конфигураций, что позволит конвертировать нужные данные и заполнить базы информацией при необходимости. В интересах пользователя следить за совпадением внутренних идентификаторов объектов или реквизитов, иначе обновление может затереть все наработки. Даже после тщательной подготовки новой конфигурации нельзя сразу же переходить к совмещению с используемой рабочей базой, так как ее тоже нужно обновлять, после всего все тщательно тестировать.
Нужно понимать, что есть варианты, когда конфигурация будет возвращена на поддержку, то есть ее процесс обновления будет происходит в стандартном режиме для программы, через загрузку релиза по интернету. Снимается программа с поддержки после внедрения в продукт модифицированных модулей. Удаление этих модулей вернет программу в исходное состояние, но полностью избавиться от них нельзя, так как нормальная работа 1С будет невозможна, ведь зачем-то этим модули программировались. Соответственно, эти модули могут выноситься за рамки программы — работа будет выполняться по внешних модулях, но на работе программы это не скажется. Таким образом, справочники и прочие объекты останутся на месте, Самостоятельно это сделать без нужных знаний проблематично, поэтому возвращением программы в рамки стандартной сборки, если это требуется, должен программист.
Также существует несколько советов, облегчающих в дальнейшем процесс обновления программных продуктов 1С. Прежде всего нужно стараться как можно меньше модифицировать программу, и если только в этом нет крайней необходимости, то не внедрять туда ничего стороннего, а пытаться решить проблемы теми типовыми инструментами, которые есть в наличии. Все без исключения изменения в конфигурации нужно комментировать и заносить в отдельный документ, чтобы в процессе восстановления ничего важного не было упущено. Чтобы объем программного кода в типовых объектах был уменьшен, следует вынести его в собственный общий модуль, при этом нужно понимать, что вызовы процедур и функций трогать нельзя — они должны оставаться в типовых объектах, чтобы программа могла корректно работать. В целях оптимизации имеет смысл выполнить замену всех вызовов типовых процедур и функций, которые находятся и в «самописном» коде объектов и в коде внешних модулей, на вызов процедур из собственного модуля. Данные процедуры являются простым ярлыком, по которому будут вызываться процедуры из типовых модулей. Таким образом, при сравнении изменений пользователю будет не нужно будет долго искать нужные строчки в модифицированном коде. Время обновления при соблюдении указанных рекомендаций сокращается до нескольких часов работ, а если все оставить как есть, то процесс может затянуться и на несколько дней.
