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

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

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

Содержание

Работаем с 1С:8

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

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

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

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

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

Сведение

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

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

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

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

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

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

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

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

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

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

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

Сталкиваемся с проблемой — «Обнаружены ссылки, помеченные на удаление».

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

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

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

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

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

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

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

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

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

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

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

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

Сравнение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прочие

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

Загрузка изменённой платформы

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

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

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

Понравилась статья? Поделить с друзьями: