← На главную

Обновление сильно доработанных конфигураций на платформе 1С:Предприятие 8.3 — одна из наиболее ответственных задач сопровождения, особенно когда речь идет о переходе между ключевыми подверсиями, например с редакции 11.2 на 11.3. В таких случаях прямое обновление «в лоб» через итоговый файл .cf часто приводит к потере логической целостности данных, повреждению регистров себестоимости и некорректной работе встроенных механизмов БСП.

Разберем детально, как спланировать и безопасно провести процесс обновления нетиповой конфигурации 1С:Управление торговлей, сохранив все кастомные доработки и корректность учетных данных.

Определение цепочки обновления и ключевых релизов

Каждый файл обновления конфигурации поставщика (.cfu) предназначен для установки строго на определенный список предшествующих версий. Пропустить все промежуточные релизы и обновиться сразу на финальный через штатный механизм поддержки невозможно, если целевой релиз не поддерживает исходную версию базы напрямую.

Проанализируем цепочку перехода:

1. Выясняем точный номер текущего релиза базы (например, 11.2.2.94).
2. Открываем описание каждого последующего релиза (файл ReadMe.txt или информация в дистрибутиве обновления) и фиксируем, с каких именно версий допускается обновление.
3. Составляем минимально возможную цепочку («прыжки» по ключевым релизам). Например, переход с младшего релиза редакции 11.2 на максимальный релиз этой же ветки, затем переход на первый релиз ветки 11.3 и далее до актуального релиза.

Метод подготовки эталонного файла конфигурации (оптимизация трехстороннего сравнения)

Если в рабочей базе изменено множество типовых объектов, выполнять ручное сравнение и объединение конфигураций на каждом из 10–15 промежуточных релизов крайне трудоемко. Для оптимизации этого процесса применим метод подготовки сквозного файла конфигурации поставщика:

1. Создаем чистую пустую информационную базу типовой конфигурации того же релиза, что и текущая рабочая база.
2. В этой эталонной базе последовательно устанавливаем все файлы обновления (.cfu) по цепочке ключевых релизов вплоть до финальной версии 11.3. При этом на каждом шаге просто обновляем конфигурацию базы данных.
3. Из полученной типовой базы выгружаем файл полной конфигурации (.cf) финального релиза.
4. В рабочей доработанной базе выполняем процедуру Сравнить, объединить с конфигурацией из файла или штатное обновление через поддержку, указав подготовленный файл .cf.

Такой подход позволяет выполнить сложное трехстороннее объединение доработанного кода и типовых модулей всего один раз, вместо многократного разрешения конфликтов на каждом шаге.

Обязательный запуск обработчиков обновления БСП

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

Рассмотрим правила запуска обработчиков в режиме 1С:Предприятие:

1. Если обновление выполняется последовательно по релизам, после каждого применения изменений в конфигураторе необходимо запускать сеанс предприятия с правами администратора.
2. Начиная с редакции 11.2, значительная часть процедур переведена в фоновые (отложенные) задания. Открываем форму Результаты обновления программы (раздел НСИ и администрирование — Обслуживание — Обновление программы).
3. Обязательно дожидаемся статуса 100% выполнения всех дополнительных процедур обработки данных. Переходить к следующей версии при незавершенных отложенных заданиях категорически запрещено: это неизбежно разрушит структуру регистров.

Контроль партионного учета и регистров себестоимости

При переходе между подсистемами партионного учета (в версиях 11.2 и 11.3 активно менялась архитектура партионного учета версий 2.1 и 2.2) структура движений регистров существенно трансформируется. Неправильный порядок действий может привести к «зависанию» отрицательных остатков и искажению финансового результата.

Выполним предварительные контрольные мероприятия перед началом обновления:

1. В исходной базе закрываем все прошлые периоды с помощью регламентной обработки ЗакрытиеМесяца.
2. Устанавливаем дату запрета изменения данных на границу последнего закрытого месяца.
3. Формируем контрольные отчеты по себестоимости, валовой прибыли и взаиморасчетам с контрагентами, сохраняя их эталонные показатели.
4. Проверяем кастомные доработки: если в конфигурации переопределялись регистры СебестоимостьТоваров, ПартииТоваровОрганизаций или ВыручкаИСебестоимостьПродаж, необходимо синхронизировать кастомные движения с новыми типовыми алгоритмами расчета. Типовые регламентные процедуры расчета себестоимости не учитывают нестандартную логику и могут перезаписать данные.
5. После завершения всех этапов обновления и отложенных заданий перезапускаем расчет себестоимости в тестовой копии и сверяем цифры с сохраненными контрольными отчетами.

Требования к платформе и изоляция кастомного кода

Проанализируем технические ограничения перед стартом работ:

1. Версия платформы и режим совместимости: Переход на редакцию 11.3 требует повышения минимальной версии платформы 1С:Предприятие и изменения свойства конфигурации РежимСовместимости. Сначала устанавливаем и тестируем требуемую платформу на сервере и рабочих станциях, и только затем обновляем метаданные конфигурации.
2. Перенос доработок в расширения: Чтобы упростить последующие обновления, перед началом масштабных изменений рекомендуется выделить доработки, не меняющие базовую структуру метаданных (новые печатные формы, отчеты, дополнительные модули), и перенести их в расширения конфигурации (.cfe). Это позволит вернуть типовые объекты на полную поддержку со статусом Не редактируется.