Обновление конфигурации «1С:Зарплата и управление персоналом КОРП» (ЗУП КОРП) с устаревшей ветки 3.1.10 на актуальную 3.1.14 — это не просто штатная процедура, а серьезный технический проект, особенно если система содержит значительные доработки. Ситуация осложняется тем, что обе эти ветки являются версиями длительного сопровождения (LTS), и между ними лежит пропасть в виде множества промежуточных релизов и изменений в архитектуре Библиотеки стандартных подсистем (БСП).
В данной статье мы разберем оптимальные стратегии перехода, проанализируем технические риски и выясним, как минимизировать трудозатраты при сохранении стабильности системы.
Рассмотрим исходные данные: имеется конфигурация 3.1.10.50 с существенными изменениями. Нам необходимо перейти на 3.1.14.154. Основная сложность заключается в том, что при классическом последовательном обновлении (через 10–12 промежуточных релизов) программисту придется на каждом шаге заново разрешать конфликты в коде и формах. Это не только долго, но и чревато внесением случайных ошибок.
Проанализируем три основных пути решения задачи, которые выработала практика сообщества 1С.
Если база находится на стадии внедрения (как в случае переноса из 2.5) и реальных учетных данных в ней немного, это самый эффективный способ. Вместо того чтобы «тащить» старую конфигурацию через десятки обновлений, мы поступим наоборот.
.cf, который содержит в себе типовую 3.1.14 плюс ваши изменения.Важный нюанс: Нельзя просто заменить конфигурацию через «Загрузить конфигурацию из файла». Если вы так сделаете, система не поймет, что произошел переход между версиями, и не запустит обработчики обновления данных. Правильный алгоритм — это именно сравнение и объединение с «постановкой на поддержку» всех объектов, чтобы программа зафиксировала изменение номера версии и при запуске в режиме «Предприятие» инициировала легальный процесс миграции данных.
Если ваша база 3.1.10 была получена путем переноса из ЗУП 2.5 и адаптация еще не завершена в боевом режиме, рассмотрим вариант повторного переноса. Алгоритмы миграции в 14-й редакции существенно доработаны по сравнению с 10-й. В них исправлено множество ошибок, связанных с расчетом среднего заработка, остатками отпусков и учетом НДФЛ.
Выясним преимущества этого подхода:
Если же база уже «живая» и в ней ведется учет, придется идти по пути последовательных обновлений. Однако не обязательно устанавливать каждый релиз. Разберем цепочку:
Внимание: При таком «прыжке» объем изменений в базе будет колоссальным. В 3.1.14 полностью пересмотрен механизм учета доходов для НДФЛ и логика заполнения регламентированной отчетности. Приготовьтесь к тому, что фоновые задания по обновлению данных будут работать несколько часов, а то и дней.
Рассмотрим критические моменты, на которые должен обратить внимание программист при любом выбранном способе:
1. Обновление платформы. Для работы ЗУП 3.1.14 требуется платформа не ниже 8.3.15.1830 или 8.3.16.1148. Проверьте также режим совместимости в свойствах конфигурации — он должен соответствовать требованиям нового релиза. Если оставить старую платформу, вы столкнетесь с ошибками при вызове методов БСП, которые используют новые возможности ядра.
2. Адаптация кода. Между редакциями 10 и 14 произошла смена версий БСП. Многие экспортные процедуры в общих модулях были удалены или перемещены. Проанализируем типичный пример: если в ваших доработках использовались процедуры типа ОбщегоНазначения.СообщитьПользователю, проверьте, не изменился ли их состав параметров. Большинство старых методов помечены как Устаревшие, и их стоит заменить на актуальные аналоги сразу.
3. Фоновые обработчики. После первого запуска обновленной базы обязательно зайдите в раздел Администрирование — Обслуживание — Обновление программы — Результаты обновления. Вы увидите список дополнительных процедур обработки данных. Пока этот список не будет пуст (все флажки зеленые), отчетность (особенно 6-НДФЛ и РСВ) строить бесполезно — данные будут некорректны.
4. Механизм расширений. Если ваши изменения вынесены в расширения, помните: в 3.1.14 могли измениться типы данных реквизитов или удалены некоторые поля. После обновления основного cf расширения могут перестать подключаться. Рекомендуем предварительно проверить их на совместимость с новой версией в копии базы.
Посмотрим на последовательность действий, которая минимизирует риски:
// 1. Создаем резервную копию (обязательно!)
// 2. Выполняем тестирование и исправление БД перед обновлением
// 3. Подготавливаем файл сравнения типовых релизов (3.1.10 -> 3.1.14)
// 4. Анализируем конфликты в ваших доработках
// 5. Обновляем платформу на сервере и клиентах
// 6. Запускаем обновление конфигурации
// 7. Контролируем выполнение обработчиков в пользовательском режиме
Проанализировав ситуацию, мы приходим к следующему заключению: если база находится на этапе разработки и данные в ней носят тестовый характер, оптимальным будет Вариант 1 или даже повторный перенос из 2.5 сразу в 3.1.14. Это сэкономит десятки часов на рутинном сравнении релизов и даст более «чистый» результат.
Если же база эксплуатируется, выбирайте переход с финального релиза 3.1.10 сразу на 3.1.14, но закладывайте значительное время на тестирование механизмов НДФЛ и расчетного листка, так как именно в этих блоках произошли самые масштабные архитектурные изменения.