← На главную

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

Шаг 1. Определение порядка и цепочки релизов

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

1. Файлы описания поставки (ReadMe / ChangeLog): При распаковке каждого дистрибутива обновления в каталог шаблонов создаются файлы описания в формате HTML. В нижней части страницы описания всегда приведен перечень предыдущих версий конфигурации, для которых предназначено данное обновление. Построив цепочку в обратном порядке — от целевого релиза к исходному, мы получим минимально необходимый маршрут обновления.
2. Официальный портал обновлений: В таблице релизов в строке каждого выпуска указаны версии, с которых поддерживается переход.
3. Специализированные калькуляторы и утилиты: Для автоматического расчета маршрута и последовательной установки промежуточных версий применяются специализированные скрипты и программы автоматизации (например, «Обновлятор-1С»), которые умеют самостоятельно скачивать и накладывать обновления по построенной цепочке.

Шаг 2. Подготовка информационной базы и платформы

Перед началом любого масштабного обновления выполним обязательные подготовительные действия:

1. Создание резервной копии: Создадим полную копию базы средствами СУБД (для клиент-серверного варианта) или скопируем файл 1Cv8.1CD (для файлового варианта). Также рекомендуется сделать выгрузку в файл .dt через конфигуратор.
2. Проверка версии платформы «1С:Предприятие 8.3»: Каждая мажорная ветка конфигурации повышает требования к минимальной версии технологической платформы и изменяет режим совместимости. Установим версию платформы, полностью совместимую с целевой редакцией 11.3, перед началом процедуры.
3. Тестирование и исправление: Запустим процедуру Тестирование и исправление информационной базы в конфигураторе. Проверим логическую и ссылочную целостность данных. Наличие «битых» ссылок в старой базе гарантированно приведет к сбою алгоритмов реструктуризации.
4. Отключение регламентных заданий: На период многоэтапного обновления отключим фоновые и регламентные задания, чтобы исключить блокировки таблиц и непредвиденную нагрузку на сервер.

Шаг 3. Поэтапный переход через узловые релизы

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

1. Обновляем базу до последнего актуального релиза ветки 11.1 (например, 11.1.10.ххх).
2. Выполняем переход на первый поддерживаемый релиз ветки 11.2, а затем последовательно доводим базу до финального релиза 11.2.3.ххх.
3. С финального релиза ветки 11.2 выполняем переход на начальный релиз редакции 11.3 и далее обновляем до целевой сборки.

Посмотрим, почему нельзя просто загрузить конфигурацию целевого релиза через файл .cf минуя промежуточные версии. В версиях 11.2 и 11.3 произошло глобальное изменение структуры объектов: например, отдельные справочники Упаковки и ЕдиницыИзмерения были объединены в единый справочник УпаковкиЕдиницыИзмерения. При «грубой» загрузке конфигурации данные этих таблиц не перенесутся программными алгоритмами, будут безвозвратно утеряны связи в документах, а справочник ИдентификаторыОбъектовМетаданных заполнится с критическими ошибками, что заблокирует назначение прав и ролей.

Шаг 4. Обязательный контроль процедур отложенного обновления

Самая частая ошибка при длительном обновлении — применение следующего файла .cfu в конфигураторе без запуска пользовательского режима на промежуточном релизе. Разберем правильный порядок действий:

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

Шаг 5. Альтернативный вариант: переход через перенос данных

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

1. Разворачиваем абсолютно чистую типовую базу целевого релиза (11.3 или 11.4).
2. Настраиваем типовую выгрузку и загрузку данных с использованием универсального формата EnterpriseData или правил конвертации.
3. Переносим из базы 11.1 только нормативно-справочную информацию (НСИ) и вводим документы ввода начальных остатков на выбранную дату (например, на начало квартала или года).

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