Обновление конфигурации «1С:Управление производственным предприятием» (УПП), которая не видела обновлений несколько лет и была серьезно доработана («перепилена»), — это сложная инженерная задача. Отставание на 50 релизов означает, что система пропустила колоссальное количество изменений в законодательстве, механизмах учета и структуре данных. В такой ситуации стандартная процедура обновления «в лоб» неизбежно приведет к потере данных и неработоспособности системы.
В данной статье мы разберем комплексный подход к решению этой задачи, объединив опыт практикующих разработчиков и технические требования платформы 1С. Рассмотрим, как минимизировать риски, сохранить уникальные доработки и обеспечить корректную работу обработчиков данных.
Прежде чем приступать к техническим действиям, проанализируем ситуацию. Мы имеем дело с конфигурацией, которая отстала примерно на 3-4 года разработки. За это время в УПП изменились не только формы отчетности, но и базовые алгоритмы, такие как прослеживаемость товаров, маркировка и учет НДС. Рассмотрим основные стратегии, которые можно применить:
Проанализируем ситуацию: за 15 лет эксплуатации предприятия в коде накапливается до 70-80% «мусорных» доработок, которые либо дублируют современный типовой функционал, либо уже не используются. Поэтому инвентаризация — наш первый и самый важный шаг.
Чтобы процесс прошел максимально безболезненно, разберем, как «облегчить» конфигурацию перед обновлением. Наша задача — максимально разнести типовой код и кастомные изменения. Рассмотрим по шагам рекомендации экспертов:
1. Перенос логики в подписки на события. Выясним причину большинства конфликтов при обновлении — это изменения в типовых модулях объектов (процедуры ПередЗаписью, ПриЗаписи, ОбработкаПроведения). Перенесем весь дозаписанный код из модулей объектов в подписки на события. Это позволит обновлять модули объектов «по версии поставщика», не опасаясь затереть свои алгоритмы.
2. Вынос печатных форм и отчетов. Если в конфигурации допилены типовые макеты или добавлены новые печатные формы прямо в состав документов, перенесем их в механизм «Внешние печатные формы и обработки». Это сократит количество точек соприкосновения при сравнении объектов.
3. Работа с формами и реквизитами. Проанализируем добавленные на формы реквизиты. Часто бывает, что реквизит на форме есть, данные в него вносятся, но в алгоритмах они уже не участвуют. Удалим лишнее, а для нужного проверим привязку к программному коду (события ПриИзменении, ПриОткрытии).
Посмотрим на техническую сторону вопроса. Обновление на 50 релизов требует актуальной версии платформы. Рассмотрим важные моменты:
Платформа: Для последних релизов УПП рекомендуется использовать платформу не ниже 8.3.17, а лучше актуальные версии ветки 8.3.21/8.3.22. Перед началом процесса обновим платформу на сервере и клиенте.
Режим совместимости: Обратим внимание на свойство конфигурации «Режим совместимости». При скачке через 50 релизов он наверняка изменится. Резкое изменение режима совместимости может «сломать» запросы или работу с формами. Посмотрим на это внимательно: если конфигурация работает в режиме «Версия 8.2.13», а целевая требует «Версия 8.3.14», переход нужно делать плавно.
Размер базы и SQL: Обновление затронет огромные массивы данных. Проведем тестирование и исправление (ТиИ) с очисткой неиспользуемых объектов и сжатием таблиц. Убедимся, что на SQL-сервере достаточно места для роста лога транзакций.
Самая большая ошибка при обновлении на 50 релизов — это попытка обновиться сразу на последний cf через «Сравнение/Объединение» без запуска предприятия. В УПП критически важны обработчики обновления данных. Это процедуры, которые пересчитывают остатки, заполняют новые регистры на основе старых данных и меняют структуру аналитики.
Рассмотрим правильный алгоритм обновления:
Разберем, почему это важно. Если пропустить промежуточные обработчики, то данные в новых реквизитах останутся пустыми, и на 50-м релизе система просто не поймет, откуда брать информацию для новых налоговых регистров.
Для анализа доработок за 15 лет встроенный механизм сравнения может быть неэффективен. Проанализируем ситуацию: визуальное сравнение в конфигураторе часто подсвечивает различия в комментариях, переносах строк или префиксах, которые не влияют на логику.
Рекомендуем использовать выгрузку конфигурации в файлы XML. Посмотрим, как это сделать:
// В Конфигураторе:
// Конфигурация -> Выгрузить конфигурацию в файлы...
После выгрузки типовой конфигурации и вашей «перепиленной», используйте инструменты сравнения текстов (например, KDiff3 или WinMerge). Это позволит увидеть реальные изменения в коде модулей гораздо быстрее и точнее. Вы сможете отсечь изменения, которые 1С внесла в типовые механизмы, от своих собственных «инъекций» кода.
Поскольку мы обновляем систему для долгосрочной эксплуатации, рассмотрим возможность использования расширений конфигурации. Хотя УПП построена на обычных формах, современные версии платформы позволяют подключать расширения для перехвата процедур (через аннотации &Вместо, &Перед, &После).
В процессе обновления наиболее критичные доработки, которые вы решили оставить, лучше вынести в расширение. Это позволит в будущем обновлять основную конфигурацию простым «накатыванием» типового cf, не тратя часы на ручное объединение модулей. Разберем пример переноса проверки перед записью документа:
&Вместо("ПередЗаписью")
Процедура Моя_ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
// Сначала вызываем типовой функционал (если нужно)
ПродолжитьВызов(Отказ, РежимЗаписи, РежимПроведения);
// Затем выполняем свою проверку
Если Не МояПроверкаДанных() Тогда
Отказ = Истина;
КонецЕсли;
КонецПроцедуры
Подводя итог, отметим, что обновление УПП на 50 релизов — это не просто техническое действие, а проект по рефакторингу системы. Выясним причину необходимости каждой доработки: если она больше не нужна, смело удаляйте ее. Помните, что поддержка УПП официально завершается в 2026 году, поэтому при таком масштабном обновлении стоит еще раз взвесить — не дешевле ли будет начать переход на 1С:ERP.
Контрольный список перед финальным обновлением рабочей базы:
Следуя этой методике, мы превращаем хаотичный процесс «борьбы с ошибками» в структурированную последовательность действий, гарантирующую сохранность данных и стабильность работы предприятия.