Как ускорить переход с конфигурации 1С:Розница 1.0 на редакцию 2.2?

Переход между редакциями 1.0 и 2.2 в конфигурациях «1С:Розница» (включая отраслевые решения, такие как «Розница. Аптека») сопровождается колоссальным изменением метаданных и структуры таблиц. Обновление информационной базы стандартным путем через последовательное накатывание релизов нередко занимает десятки часов или вовсе завершается аварийно из-за нехватки памяти. Разберем основные причины медленной конвертации, способы ускорения процесса и альтернативные варианты перехода.

Причины низкой скорости обновления

Выясним причину многочасовой обработки данных при переходе с редакции 1.0 на 2.x. В конфигурации происходят коренные изменения ключевых подсистем:

1. Переработка подсистемы чеков ККМ: исторические данные по продажам требуют масштабного дозаполнения новых реквизитов. Обработка выполняется в несколько проходов, перезаписывая каждую строку и каждый документ.
2. Изменение ценообразования: на смену прежним механизмам приходят правила ценообразования, виды цен и документы применения цен, что требует глобального пересчета регистров.
3. Учет серий и сроков годности: в отраслевых аптечных решениях справочники сильно перегружены сериями, производителями и признаками ЖНВЛП. Новая концепция политик учета серий вынуждает систему анализировать ретроспективные остатки и движения.
4. Накладные расходы СУБД: непрерывная запись миллионов изменений переполняет журнал транзакций СУБД, а включенный журнал регистрации и фоновые задания создают предельную нагрузку на дисковую подсистему.

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

Проанализируем правильный маршрут обновления. Распространенная ошибка — последовательная установка всех промежуточных релизов (1.0 → 2.0 → 2.1 → 2.2). Для перехода между поколениями выпускаются специализированные переходные конфигурации.

Редакция 2.0 в этой цепочке представляет собой технический служебный дистрибутив, предназначенный исключительно для реструктуризации данных. Работать в ней нельзя. Переход выполняется по цепочке: исходная база 1.0 обновляется на переходную конфигурацию, в ней запускаются процедуры конвертации данных, после чего выполняется прямое обновление на актуальный релиз 2.2. Для отраслевого решения («Розница. Аптека») наличие и номер актуального переходного дистрибутива следует уточнять у разработчика отраслевого решения.

Оптимизация программного кода конвертации

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

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

1. Отключение проверок при записи: использование свойства ОбменДанными.Загрузка позволяет пропустить громоздкие обработчики событий при перезаписи документов, что дает до 30–40% прироста скорости.
2. Объединение проходов: объединим несколько циклов модификации реквизитов в один проход выборки данных.

Посмотрим на пример установки режима загрузки при модификации документов чеков:

ДокументОбъект = СсылкаНаЧек.ПолучитьОбъект();
ДокументОбъект.ОбменДанными.Загрузка = Истина;
// Заполнение требуемых реквизитов новой редакции
ДокументОбъект.Записать(РежимЗаписиДокумента.Запись);

Подготовка информационной базы и оптимизация окружения

Разберем по шагам регламентные операции, которые необходимо выполнить до запуска процесса конвертации:

1. Свертка и очистка чеков: чеки ККМ за закрытые кассовые смены, по которым уже сформированы документы ОтчетОРозничныхПродажах, не несут оперативной ценности для дальнейшей работы. Их удаление или архивация перед переходом сокращает время обновления в разы.
2. Перевод базы на клиент-серверный вариант (64-бит): файловые базы гарантированно сталкиваются с блокировками таблиц и ограничением адресного пространства в 4 ГБ. Конвертацию следует запускать на 64-разрядном сервере «1С:Предприятие» и высокопроизводительном дисковом массиве (NVMe SSD).
3. Настройка СУБД: переведем базу данных в MS SQL в простую модель восстановления (Simple Recovery Model). Это предотвратит лавинообразное разрастание лога транзакций (LDF-файла).
4. Отключение сервисных механизмов платформы:
   1. Установим блокировку регламентных и фоновых заданий в консоли кластера серверов 1С.
   2. Отключим индексацию полнотекстового поиска (ППС).
   3. Установим уровень записи журнала регистрации на «Регистрировать только ошибки» либо временно отключим его полностью.

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

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

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

1. В новую конфигурацию «Розница 2.2» переносятся нормативно-справочная информация (номенклатура, характеристики, серии со сроками годности, контрагенты, организации, эквиваленты штрихкодов) с помощью универсальной выгрузки/загрузки XML или правил конфигурации «Конвертация данных 2».
2. На контрольную дату фиксируются и переносятся остатки:
   1. Товарные остатки в разрезе серий аптечного ассортимента (документ ВводНачальныхОстатков).
   2. Остатки денежных средств по операционным кассам и кассам ККМ.
   3. Действующие розничные цены (документы установки и применения цен).
3. Для аптечных номенклатурных позиций проверяем обязательное назначение корректной политики учета серий (например, «Учет остатков по сериям») до проведения документов ввода остатков.
4. Исходная информационная база «Розница 1.0» переводится в архивный режим (только чтение) для просмотра истории чеков и построения старой отчетности.

Важное замечание для распределенных информационных баз (РИБ): механизмы РИБ не способны передать глобальные изменения структуры между редакциями 1.0 и 2.2 по каналам синхронизации. Перед обновлением узлы обязательно отвязываются от центральной базы. После обновления центральной базы (или создания чистой базы 2.2 с переносом остатков) для каждого магазина формируются и выгружаются полностью новые начальные образы узлов РИБ.