← На главную

Обновление нетиповой конфигурации, которая не обновлялась несколько лет (например, 5–6 лет), является одной из самых ответственных и рискованных задач при сопровождении систем 1С. В случаях с конфигурациями на платформе «1С:Предприятие» (такими как Управление торговлей 10.3) основная сложность заключается не столько в объеме метаданных, сколько в сохранении пользовательских доработок и целостности структуры данных. Проанализируем основные риски, возможные подходы к решению этой задачи и выработаем оптимальную последовательность действий.

Основные технические риски при перескакивании через релизы

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

1. Невыполнение обработчиков обновления информационной базы: При запуске обновленной базы в режиме «1С:Предприятие» срабатывают процедурные и отложенные обработчики данных. Они заполняют новые реквизиты, конвертируют структуры регистров и пересчитывают данные. Если пропустить промежуточные версии, эти процедуры могут не выполниться или отработать с ошибкой, что приведет к разрушению структуры данных.
2. Удаление и миграция реквизитов: В процессе развития конфигурации разработчики фирмы «1С» часто переименовывают реквизиты, добавляя префикс Удалить, а через несколько релизов окончательно исключают их из структуры метаданных. Перенос данных со старых полей на новые происходит именно в промежуточных обработчиках. При прямом обновлении «через года» информация из старых реквизитов будет навсегда утеряна.
3. Режим совместимости платформы: При переходе на свежие релизы конфигураций часто меняется требуемый режим совместимости платформы, что может повлиять на исполнение запросов и поведение блокировок.

Стратегия 1. Поэтапное обновление через «узловые» релизы

Рассмотрим наименее травматичный способ обновления рабочей нетиповой базы без риска потери данных. Вместо последовательной установки десятков выпусков выделим так называемые «узловые» (ключевые) релизы, в которых происходили кардинальные изменения структуры данных или метаданных.

Разберем алгоритм выполнения поэтапного обновления:

1. Подготовка тестового контура: Разворачиваем копию рабочей базы данных на локальном сервере или тестовом сервере 1С. Все операции проводим строго на копии.
2. Определение реальных изменений (3-way merge): Чтобы увидеть только те изменения, которые внесли программисты заказчика, используем трехстороннее сравнение. Берем типовой файл конфигурации поставщика той же версии, которая сейчас установлена в базе. Сравниваем текущую рабочую конфигурацию с типовым файлом соответствующей версии. Это позволяет отсечь типовой код и выявить изолированные пользовательские доработки.
3. Пошаговое объединение конфигураций: Разбиваем весь путь обновления (например, 20–30 релизов) на 5–10 промежуточных этапов. Для каждого этапа выполняем объединение конфигураций, бережно сохраняя доработанные общие модули, формы и объекты.
4. Запуск обработчиков обновления: После каждого прохождения промежуточного «узлового» релиза обязательно обновляем конфигурацию базы данных и запускаем программу в режиме «1С:Предприятие» под правами администратора. Дожидаемся полного завершения процедур обновления ИБ.
5. Тестирование на копии: Проверяем ключевой функционал (кассовый блок, проведение документов продажи, выгрузки) и передаем базу на проверку ключевым пользователям.

Стратегия 2. Точечный перенос необходимого нового функционала

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

Часто заказчику не требуется весь массив изменений 1С, а нужны лишь конкретные блоки (например, новая форма счет-фактуры, выгрузка на сайт Битрикс, интеграция с кассами или ЭДО). Рассмотрим порядок действий при таком подходе:

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

Стратегия 3. Перенос остатков и оборотов в чистую актуальную базу

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

1. Устанавливаем чистую типовую конфигурацию 1С актуального релиза.
2. Переносим в нее только необходимый блок пользовательских доработок (новые справочники, документы и регистры), обособляя их или оформляя в виде расширений/внешних обработок.
3. Выполняем перенос нормативно-справочной информации (НСИ) и остатков из старой базы на начало периода с помощью правил конвертации данных.

Рекомендации по организации работы

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

1. Фиксация технического задания: Не начинайте работы до утверждения четкого списка критериев приемки. Обязательно согласуйте с заказчиком, какие именно процессы должны быть протестированы после обновления.
2. Оплата по этапам или почасовая аналитика: Оцените трудозатраты на проведение трехстороннего сравнения и выявление всех переписанных объектов до объявления итоговой стоимости.
3. Тестирование пользовательских отчетов и печатных форм: Внезапное изменение печатных форм или алгоритмов отчетов часто приводит к остановке работы пользователей, поэтому проверяйте эти элементы в первую очередь.