Обновление типовых конфигураций 1С, находящихся на поддержке без изменений, обычно не вызывает трудностей. Однако при наличии собственных реквизитов, регистров сведений, измененных алгоритмов проведения и форм документов переход на новую редакцию (например, с Управление торговлей 11.2 на Управление торговлей 11.3) требует четкого соблюдения методики. Разберем по шагам, как выстроить последовательность действий, чтобы не потерять накопленные данные и доработки программного кода.
Анализ типов изменений: метаданные против программного кода
Прежде чем приступать к процедуре обновления, проанализируем имеющиеся доработки в информационной базе. Все изменения в 1С делятся на две принципиальные категории:
Изменения структуры метаданных: добавленные реквизиты в типовые справочники и документы, новые регистры сведений, регистры накопления, собственные документы и подсистемы. Эти объекты содержат пользовательские данные. Если исключить их из конфигурации на промежуточном релизе, платформа выполнит реструктуризацию и безвозвратно удалит накопленные значения из таблиц СУБД. Поэтому добавленные объекты метаданных и реквизиты необходимо сохранять на каждом этапе цепочки обновления.
Программный код и формы: логика модулей объектов, менеджеров, общих модулей, доработки экранных и печатных форм. Если измененная логика не затрагивает проведение документов в промежуточных релизах, перенос интерфейсных правок можно отложить до финального целевого релиза. Однако если в процессе перехода выполняются алгоритмы перезаполнения регистров или перепроведение документов, влияющий на движения код также должен присутствовать в ключевых релизах.
Подготовка к обновлению информационной базы
Перед выполнением любых манипуляций с конфигуратором выполним обязательные подготовительные действия:
Создадим полную резервную копию информационной базы (выгрузка .dt или средствами СУБД).
Выгрузим файл текущей конфигурации информационной базы (.cf), содержащий все пользовательские доработки.
Выгрузим файл текущей типовой конфигурации поставщика соответствующего релиза (через меню Конфигурация — Поддержка — Настройка поддержки — Сохранить в файл). Это позволит в любой момент получить точный отчет о сравнении и список доработок.
Выполним тестирование и исправление информационной базы, чтобы исключить логические и ссылочные ошибки до начала реструктуризации.
Очистим локальный кэш конфигуратора в каталогах AppData/Local/1C и AppData/Roaming/1C.
Пошаговый алгоритм последовательного обновления через ключевые релизы
Рассмотрим стандартный и наиболее безопасный сценарий обновления через цепочку дистрибутивов поставщика с использованием механизма трехстороннего сравнения.
Использование полных файлов конфигурации (.cf): для сокращения количества промежуточных шагов рекомендуется использовать полные дистрибутивы релизов (файлы .cf), а не накопительные обновления .cfu. Это позволяет переходить сразу по узловым (ключевым) релизам, официально разрешенным фирмой «1С».
Запуск процедуры обновления поставщика: перейдем в меню Конфигурация — Поддержка — Обновить конфигурацию, укажем файл .cf следующего ключевого релиза.
Настройка окна объединения: в открывшемся окне сравнения и объединения обязательно включим фильтр по дважды измененным объектам (то есть объектам, которые были изменены и поставщиком в новом релизе, и разработчиком в текущей базе).
Сохранение структуры данных: снимем флаги удаления со всех пользовательских реквизитов, табличных частей и новых объектов метаданных. Для собственных объектов выбираем режим объединения с сохранением конфигурации пользователя.
Применение изменений к базе данных: сохраняем конфигурацию и нажимаем Обновить конфигурацию базы данных (F7), соглашаясь с реструктуризацией таблиц.
Обязательный запуск в режиме «1С:Предприятие»: конфигурации на базе Библиотеки стандартных подсистем (БСП) требуют обязательного запуска в пользовательском режиме после каждого ключевого релиза. Запустим базу и дождемся полного завершения монопольных и отложенных обработчиков обновления. Контролировать процесс можно через форму «Результаты обновления программы».
Повторение цикла: повторяем шаги для следующего промежуточного релиза вплоть до целевого.
Работа с обработчиками обновления БСП
Рассмотрим подробнее поведение отложенных обработчиков. В современных версиях прикладных решений (включая Управление торговлей) многие регистры переформировываются по новым аналитическим разрезам (например, РеестрДокументов, новые регистры взаиморасчетов или себестоимости). Если не дать отложенным обработчикам завершить работу и сразу накатить следующий релиз, база данных окажется в неконсистентном состоянии, что приведет к системным ошибкам при дальнейших обновлениях.
Для пакетного запуска обновления данных из командной строки можно использовать параметр:
Финальный перенос доработок и адаптация функционала
Когда база успешно обновлена на целевой релиз и все обработчики завершены, переходим к переносу пользовательского кода и экранных форм:
Сравниваем текущую обновленную конфигурацию с исходным доработанным файлом .cf, выгруженным на начальном шаге.
Анализируем измененные типовые модули. Если типовой алгоритм в новом релизе кардинально изменился, адаптируем нетиповой код под новый контекст функций и процедур БСП.
Переносим доработки экранных форм, командных панелей и печатных форм.
Проверяем синтаксическим контролем все модули и тестируем проведение ключевых документов программы.
Альтернативный подход: вынос доработок в расширения
Чтобы упростить последующие обновления прикладного решения, проанализируем возможность рефакторинга конфигурации. Все новые формы, печатные формы, отчеты и подписки на события рекомендуется переносить в механизмы расширений конфигурации. В таком случае основная конфигурация остается на стандартной типовой поддержке без снятия с замка, что позволяет в дальнейшем обновлять базу штатным способом без ручного объединения кода.