Как обновить сильно измененную «1С:Розницу» (Рарус: Аптека) с версии 2.0/2.1 на 2.3 в условиях РИБ?

Обновление конфигураций 1С, которые «перепрыгивают» через несколько подредакций (например, с 2.0 сразу на 2.3), всегда является серьезным вызовом для разработчика. Ситуация осложняется, если база сильно кастомизирована (переписана), содержит отраслевую специфику (как в случае с «Рарус: Аптека») и работает в режиме распределенной информационной базы (РИБ) на 15 и более узлов. В такой ситуации стандартное нажатие кнопки «Обновить конфигурацию» практически гарантированно приведет к критическим ошибкам.

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

Стратегия 1: Последовательное обновление через «опорные» релизы

Этот метод предполагает постепенное обновление конфигурации через ключевые релизы, на которых происходят важные изменения структуры данных. Мы не можем просто накатить конфигурацию 2.3 на 2.1, так как в промежуточных версиях (например, в 2.2) выполняются обработчики обновления, которые реструктуризируют таблицы для работы с маркировкой, честным знаком и требованиями 54-ФЗ.

Рассмотрим пошаговый алгоритм:

1. Подготовка «чистой» конфигурации: Приведем текущий релиз к максимально типовому виду. Наши изменения в коде (модулях) лучше временно закомментировать или вынести, оставив только добавленные реквизиты, чтобы не потерять данные в них.
2. Определение цепочки переходов: Прямой переход с 2.1 на 2.3 не предусмотрен. Сначала необходимо обновиться до финального релиза редакции 2.1, затем совершить переход на переходный релиз редакции 2.2, и только после выполнения всех фоновых процедур обновления переходить на 2.3.
3. Контроль отложенного обновления: Это критически важный момент. После каждого значимого прыжка по версии необходимо зайти в базу в режиме «Предприятие» и дождаться завершения всех фоновых заданий. Проверить это можно в разделе Администрирование — Обслуживание — Результаты обновления программы. Пока статус не будет «Обновление успешно завершено», переходить к следующему релизу нельзя.
4. Адаптация доработок: После достижения целевого релиза 2.3 необходимо перенести свои изменения. Современный стандарт разработки в 1С рекомендует максимально использовать расширения конфигурации. Это позволит в будущем обновляться значительно легче.

Стратегия 2: «Технологический переход» через Конвертацию Данных

Если база «переписана до неузнаваемости», эксперты рекомендуют отказаться от классического обновления в пользу переноса данных в новую, чистую базу актуального релиза. Это позволяет избавиться от «мусора» в коде и некорректно заполненных регистров, накопившихся за годы работы.

Разберем этот процесс:

1. Создаем пустую базу на актуальном релизе «1С:Розница 2.3» (или актуальной версии «Рарус: Аптека»).
2. Используя инструмент КонвертацияДанных (версии 2.1), создаем правила обмена между старой и новой версиями.
3. Переносим только необходимые данные:
   • НСИ: Справочники товаров, контрагентов, касс, складов.
   • Остатки: На определенную дату (например, на начало месяца).
   • Цены: Актуальные прайс-листы.
4. Отраслевая специфика: Для «Рарус: Аптека» крайне важно корректно перенести учет серий и сроки годности. В новых редакциях механизмы работы с сериями могут отличаться, поэтому в КД 2.1 нужно внимательно прописать алгоритмы сопоставления.

Преимущество этого метода в том, что мы получаем чистую систему, полностью готовую к работе с маркировкой (МДЛП). Недостаток — потеря истории документов (хотя старую базу можно оставить как архив).

Работа с РИБ (Распределенной информационной базой)

Обновление 15 узлов — это зона повышенного риска. Проанализируем, почему это так, и как минимизировать риски:

Проблема гигантских пакетов обмена: При переходе между редакциями происходит массовая перезапись документов и регистров (из-за работы обработчиков обновления). Это регистрирует тысячи изменений для обмена. При попытке синхронизации сформируется файл обмена в несколько гигабайт, который периферийный узел может просто не «переварить».

Решение для РИБ:

• Если используется Стратегия 1 (обновление релизов), перед запуском обмена после обновления центра стоит очистить таблицы регистрации изменений для узлов, если вы планируете обновить их вручную (накатив cf-файл).
• Если используется Стратегия 2 (перенос в новую базу), то для всех 15 магазинов придется создать новые начальные образы. Это наиболее надежный вариант, гарантирующий, что схема данных на узлах будет идентична центру.

Технические нюансы: Режим совместимости и Платформа

Переход на 2.3 потребует актуальной версии платформы (не ниже 8.3.15). Выясним причину возможных проблем при смене платформы: старые базы часто работают в режиме совместимости с 8.2. При обновлении до 2.3 режим совместимости будет поднят до 8.3.14 или выше.

На что обратить внимание:

• Динамические списки: Могут перестать работать некоторые произвольные запросы в формах.
• Работа с торговым оборудованием: В редакции 2.3 используется обновленная БиблиотекаПодключаемогоОборудования (БПО). Старые драйверы ККТ могут не поддерживаться, потребуется перенастройка всех касс в 15 магазинах.
• Метод ОбновитьПОВерсии: В коде типовых обновлений часто встречаются вызовы, которые жестко завязаны на наличие определенных метаданных. Если вы удалили какой-то «ненужный» типовой реквизит в своей переписанной базе, обновление прервется с ошибкой.

Использование автоматизированных средств

Для упрощения процесса можно рассмотреть использование специализированного ПО, такого как Обновлятор-1С. Рассмотрим его возможности:

// Пример логики, которую может выполнять скрипт обновления
Процедура ВыполнитьПоследовательноеОбновление()
    // 1. Создание резервной копии
    Копия = СоздатьБэкап();
    // 2. Скачивание релизов из списка
    СписокРелизов = ПолучитьСписокДоступныхОбновлений();
    Для Каждого Релиз Из СписокРелизов Цикл
        Если Релиз.Обязательный Тогда
            ОбновитьКонфигурацию(Релиз);
            ЗапуститьПредприятиеИВыполнитьОбработчики();
        КонецЕсли;
    КонецЦикла;
КонецПроцедуры

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

Выводы и рекомендации

Подведем итог: если ваша база 2.1 содержит минимум доработок, идите путем последовательного обновления через ключевые релизы 2.2. Если же база изменена значительно (на 30-50% и более), выберите путь создания новой базы на 2.3 и переноса остатков через Конвертацию Данных. Для РИБ на 15 узлов наиболее безопасным способом будет пересоздание начальных образов после того, как центральный узел будет полностью отлажен и проверен в работе.