Обновление конфигурации «Управление торговлей» (УТ) 10.3 с очень старого релиза (например, 10.3.12) на актуальный (10.3.77 и выше) — это не просто техническая процедура, а серьезный проект по миграции данных и кода. Когда разрыв между версиями составляет более 50 релизов, стандартная кнопка «Обновить» может привести к непредсказуемым последствиям: от потери кастомного функционала до полной поломки логики учета. Рассмотрим детально, как выполнить этот «прыжок», минимизировав риски.
Прежде чем приступать к каким-либо действиям в конфигураторе, проанализируем, насколько база отошла от типового решения. Часто бывает так, что «сильно переделанная» конфигурация содержит изменения, которые за прошедшие 10 лет уже были реализованы самой фирмой «1С» в официальных обновлениях. Выясним это по шагам:
cf файл версии 10.3.12.3 и сравним его с нашей рабочей базой. Это позволит выделить конкретный список объектов (справочников, документов, модулей), которые были изменены или добавлены.Существует два основных подхода к решению этой задачи. Разберем преимущества и недостатки каждого.
Метод 1: Поэтапное последовательное обновление (CFU)
Этот путь предполагает прохождение через все (или основные узловые) релизы. Главный плюс — автоматический запуск обработчиков обновления данных. В 1С:УТ 10.3 за это отвечает процедура ОбщегоНазначения.ВыполнитьОбновлениеИнформационнойБазы().
При таком подходе мы последовательно накатываем обновления, каждый раз разрешая конфликты кода. Рассмотрим примерную схему узловых релизов:
Важно: Проблема этого метода в том, что при каждом обновлении придется вручную объединять модули, что при 40–50 итерациях превращается в бесконечный процесс.
Метод 2: Миграция на новый типовой релиз (Чистый лист)
Проанализируем ситуацию: если доработок много, но они локализованы в определенных модулях, часто быстрее взять последний типовой релиз (например, 10.3.77) и перенести в него ваши доработки заново, адаптируя их под новую архитектуру. После этого данные переносятся из старой базы в новую с помощью обработки «Выгрузка и загрузка данных XML» или через свертку базы.
Одной из главных опасностей «прыжка» через релизы является механизм удаления устаревших объектов. В 1С принята практика: сначала реквизит помечается префиксом Удалить..., а через несколько релизов он полностью исключается из конфигурации.
Разберем ситуацию: в релизе 10.3.20 данные переносятся из реквизита СтараяСтавка в новый регистр сведений. Если вы сразу обновитесь до 10.3.60, минуя промежуточные версии, обработчик обновления для релиза 10.3.20 может не сработать или не найти нужных метаданных, и данные просто исчезнут.
Для предотвращения этого выполним следующие действия:
При объединении конфигураций всегда обращайте внимание на модули объектов. Посмотрим на примере документа РеализацияТоваровУслуг. В старых версиях расчет НДС мог быть жестко прописан в модуле, в новых же — вынесен в общие модули или механизмы подсистемы налогообложения.
Если вам необходимо сохранить кастомную логику, попробуйте выделить её в отдельные процедуры. В конфигурациях на обычных формах (каковой является УТ 10.3) мы не можем использовать расширения в полной мере, как в УТ 11, но мы можем минимизировать правки типовых процедур. Рассмотрим пример правильной вставки кода:
// В типовой процедуре ОбработкаПроведения
Процедура ОбработкаПроведения(Отказ, РежимПроведения)
// Стандартный код 1С
...
// НАЧАЛО ДОРАБОТКИ (Собственные механизмы)
МойФирменныйМодуль.ВыполнитьДополнительныеДействия(ЭтотОбъект, Отказ);
// КОНЕЦ ДОРАБОТКИ
КонецПроцедуры
Такой подход позволит при следующем обновлении легко увидеть ваши изменения и перенести их одним блоком.
Обновляя УТ 10.3 до современных релизов, вы столкнетесь с тем, что в конфигурации появятся сотни новых объектов: справочники ШтрихкодыУпаковокТоваров, документы ЗаказНаЭмиссиюКодовМаркировкиСУЗ и целые подсистемы интеграции с ИС МП и ВетИС. Эти механизмы глубоко интегрированы в типовые документы.
Проанализируем ситуацию: если ваши старые доработки изменяли структуру проведения документов по регистрам (например, по регистру ЗаказыПокупателей), вам придется крайне осторожно адаптировать код под новые требования. В последних версиях логика проведения стала более сложной из-за необходимости контроля статусов маркируемой продукции.
Выясним итоговую последовательность действий, которая обеспечит стабильную работу системы:
cf файл на копию 10.3.12. Смотрим на список конфликтов. Если их тысячи — возвращаемся к стратегии поэтапного обновления.
// Пример вызова в процедуре ПриНачалеРаботыСистемы
ОбновлениеИнформационнойБазы.ВыполнитьОбновление();
Резюме: Прыжок с 10.3.12 на 10.3.77 возможен. Основная стратегия — это сочетание «умного» объединения (сохранение только жизненно важных доработок) и обязательного прохождения контрольных точек релизов для корректной трансформации данных. Если конфигурация переписана на 80%, рассмотрите вариант переноса остатков в чистую актуальную версию УТ 10.3.