← На главную

Введение в задачу

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

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

Этап 1: Подготовка и анализ платформы

Прежде чем мы вообще притронемся к конфигуратору, нам необходимо обратить внимание на фундамент — технологическую платформу 1С:Предприятие. Это критически важный момент, который часто упускают из виду.

Старая версия Розницы (2.3.10) работала на платформах версий 8.3.17 или 8.3.18. Актуальные релизы требуют платформу не ниже 8.3.22, а лучше — 8.3.24. Если мы попытаемся накатить новую конфигурацию на старый сервер 1С, база данных просто не запустится, выдав ошибку несоответствия версии платформы или режима совместимости. На этом же этапе полезно провести профилактику данных, выполнив поиск и удаление дублей без ограничения на количество записей, чтобы не тащить лишний мусор в новую версию.

Порядок действий на этом этапе:

1. Сделаем полные архивные копии (бэкапы) всех баз данных (центральной и периферийных), используя средства СУБД (SQL) или выгрузку в dt (если база файловая).
2. Скачаем и установим актуальную версию платформы 1С на сервер и все клиентские машины.
3. Проверим работоспособность текущей старой базы на новой платформе. Она должна запускаться и работать корректно.

Этап 2: Построение цепочки обновлений

Главная ошибка новичков — попытка обновить базу сразу на последний релиз с помощью файла cf. В случае с разрывом в 3 года это практически гарантированно приведет к потере данных в регистрах, так как структура хранения данных менялась многократно, и обработчики перехода должны отрабатывать последовательно.

Нам необходимо построить «маршрут» обновлений. Для этого обратимся к официальной таблице релизов на сайте поддержки пользователей. В процессе подготовки цепочки стоит выполнить анализ конфигурации на наличие ошибок и проверку вызовов общих модулей, чтобы заранее выявить потенциальные проблемы совместимости в доработках.

В таблице релизов есть колонка «Обновление с версии». Нам нужно найти нашу версию 2.3.10.39 и посмотреть, на какую максимальную версию можно перейти напрямую. Обычно цепочка выглядит так: 2.3.10 -> 2.3.12 -> 2.3.14 -> 2.3.16 и так далее. Мы можем «перепрыгивать» через промежуточные исправительные релизы, но обязаны соблюдать мажорные вехи переходов.

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

Этап 3: Технология обновления нетиповой конфигурации

Так как в нашей конфигурации есть доработки (свои справочники и документы), автоматическое обновление нам не подходит. Мы будем использовать режим «Сравнение и объединение».

Рассмотрим два подхода к файлам обновлений:

1. Использование файлов .cfu (update): Это классический способ. Мы последовательно накатываем маленькие файлы обновлений. Это безопасно, но долго.
2. Использование файлов .cf (полная конфигурация): Если мы скачаем полные дистрибутивы целевых релизов (тех самых вех, через которые мы прыгаем), процесс сравнения и объединения может пройти стабильнее. Многие специалисты при этом выбирают путь приведения конфигурации к типовой с выносом всех доработок в расширения, что значительно упрощает все последующие обновления.

Алгоритм действий в конфигураторе:

1. Открываем конфигурацию, выбираем Конфигурация -> Поддержка -> Обновить конфигурацию.
2. Выбираем файл обновления.
3. В окне сравнения и объединения ОБЯЗАТЕЛЬНО снимаем галочку с корня конфигурации.
4. Нажимаем кнопку «Действия» -> «Отметить по подсистемам файла поставщика». Это позволит выбрать все типовые объекты.
5. Вручную проверяем наши добавленные объекты. Так как автор темы указал, что добавлены новые справочники и документы, а типовые объекты не менялись, риск конфликтов минимален. Наши объекты должны остаться нетронутыми.
6. Критический момент: Режим совместимости. В окне сравнения найдите свойство корня конфигурации РежимСовместимости. Убедитесь, что оно устанавливается в значение из новой конфигурации поставщика. Если оставить старый режим, новый функционал (например, маркировка) работать не будет.

Этап 4: Запуск обработчиков обновлений

После применения обновления в конфигураторе, мы обязаны запустить 1С в режиме «Предприятие». В современных конфигурациях, включая Розницу 2.3, львиная доля переноса данных выполняется фоновыми заданиями. На этом этапе могут проявиться специфические баги, такие как проблема с загрузкой остатков ЕГАИС из УТМ, которую необходимо оперативно устранить для корректной работы склада.

Давайте посмотрим, как это контролировать:

1. Запускаем базу под администратором.
2. Дожидаемся окна с сообщением о выполнении обновления версии программы.
3. Переходим в раздел Администрирование -> Обслуживание -> Результаты обновления программы.
4. Нас интересует ссылка «Отложенные процессы обновления» (или «Данные в обработке»).
5. Пока список отложенных обработчиков не станет пустым (или пока статус не станет «Выполнено»), нельзя приступать к накатыванию следующего релиза.

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

Этап 5: Проблема РИБ и её решение

В теме справедливо заметили, что обновление через РИБ будет «долгим и печальным». Давайте разберем, почему, и как с этим бороться.

Почему нельзя обновлять РИБ стандартно в такой ситуации?
При штатном обмене все изменения конфигурации регистрируются для передачи в периферийный узел. Представьте объем изменений за 3 года: изменен почти каждый объект, каждый модуль, каждая форма. Плюс служебные данные обработчиков обновления. Файл сообщения обмена (XML) вырастет до нескольких гигабайт. Также для работы маркировки в РИБ вам потребуется обработка для автоматической актуализации токенов ИС МП, чтобы кассы в магазинах могли работать в разрешительном режиме.

Оптимальная стратегия: Пересоздание узлов

Вместо того чтобы мучить каналы связи, мы поступим радикально, но эффективно:

1. Полностью обновляем только Центральную Базу до последнего актуального релиза. Выполняем все процедуры, описанные выше.
2. Убеждаемся, что в Центре все данные на месте, документы проводятся, отчеты формируются.
3. Для периферийных узлов (магазинов) мы НЕ делаем обмен. Мы создаем новые образы.
4. В Центральной базе заходим в настройки синхронизации данных (РИБ).
5. В зависимости от ситуации, можно либо сбросить признак распределенной базы у старых узлов и создать новые, либо воспользоваться механизмом «Создать начальный образ» для существующего узла (с заменой базы в магазине).

Этот метод гарантирует, что в магазин приедет чистая, оптимизированная база актуальной версии, без накопленного "мусора" регистрации изменений за 3 года.

Автоматизация процесса

Если ручное обновление через конфигуратор кажется слишком утомительным (нажимать «Далее» 20-30 раз), можно воспользоваться специализированным ПО, таким как «Обновлятор-1С». Эта программа умеет:

• Сама скачивать нужные релизы цепочки.
• Автоматически делать бэкапы.
• Запускать обновление в пакетном режиме.
• Выполнять обработчики обновления данных.
• Справляться с нетиповыми конфигурациями (если изменения не затрагивают обновляемые типовые объекты, программа может применить обновление поверх, но с осторожностью).

Однако, учитывая, что конфигурация «своя», первый прогон обновления лучше сделать вручную или под строгим контролем, чтобы убедиться, что алгоритмы объединения корректно отрабатывают перенос ваших справочников.

Переход на Розницу 3.0

Стоит также упомянуть, что сейчас 1С активно продвигает редакцию Розница 3.0 (на базе УНФ). Версия 2.3 пока поддерживается, но развитие функционала идет в 3.0.

Важно понимать: переход с 2.3 на 3.0 — это не обновление (cfu), а переход на другой программный продукт с переносом данных. Ваши добавленные справочники и документы при таком переходе автоматически не перенесутся. Их придется переписывать заново под архитектуру 3.0 и писать правила обмена для переноса исторических данных. Поэтому, если задача стоит просто «обновить текущую систему», оставайтесь на ветке 2.3, пока 1С официально не объявит о прекращении её поддержки.

Заключение

Подводя итог, план работ выглядит следующим образом:

1. Обновление платформы 1С до 8.3.22+.
2. Создание бэкапа.
3. Последовательное обновление Центральной базы с запуском Предприятия на каждом этапе (можно пропускать релизы согласно таблице 1С).
4. Контроль режима совместимости и сохранности нетиповых объектов.
5. Полное завершение всех фоновых заданий обновления в Центре.
6. Пересоздание периферийных баз (создание новых начальных образов) вместо попытки обмена.

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