Обновление старых, сильно доработанных конфигураций «1С:Управление торговлей 10.3» часто преподносит сюрпризы. Одна из самых известных проблем — невозможность штатного перехода с релиза 10.3.25.1 на версию 10.3.26.2. Несмотря на то что обновление конфигурации в режиме Конфигуратора проходит успешно, при попытке зайти в пользовательский режим (предприятие) система выдает критическую ошибку: «Переход с версии 10.3.25 на версию 10.3.26.2 конфигурации "Управление торговлей" не поддерживается!». Разберем, почему это происходит и как правильно решить проблему, не нарушив логику дальнейших обновлений.
Прежде всего, проанализируем ситуацию. Релиз 10.3.26.2 выпускался в период активных изменений в законодательстве (НДС и кассовые операции). В программном коде процедуры обновления разработчики 1С используют жестко заданный массив строк с номерами предыдущих версий, с которых разрешен переход. В релизе 10.3.26.2 по технической ошибке номер «10.3.25» просто забыли включить в этот список.
Ситуация осложняется, если база нетиповая. В этом случае программисты часто обновляют конфигурацию через «Сравнение-объединение», что иногда приводит к рассинхронизации версии основной конфигурации, конфигурации поставщика и значения константы НомерВерсииКонфигурации.
Перед тем как вносить изменения в код, проверим текущее состояние информационной базы. Выполним следующие действия:
Константы.НомерВерсииКонфигурации.Получить(). Если там указано «10.3.25.1», а система требует одну из списка старых версий, значит, сработал программный запрет.Самый надежный способ — это «помочь» системе увидеть нашу версию как допустимую. Нам необходимо найти процедуру, которая отвечает за проверку возможности обновления. Обычно это общий модуль ОбновлениеИнформационнойБазы (или аналогичный, в зависимости от точной сборки).
Найдем процедуру ПроверитьВозможностьОбновления (или фрагмент кода внутри ВыполнитьОбновление). Проанализируем список разрешенных версий. Чтобы исправить ситуацию, добавим номер нашей версии в массив допустимых. Если же вы хотите действовать радикально (как предлагалось в сообщениях форума), можно временно закомментировать проверку, но будьте осторожны: это может привести к пропуску важных обработчиков обновления данных.
Посмотрим на пример того, как может выглядеть правка в коде:
// В общем модуле находим место, где формируется список разрешенных версий
РазрешенныеВерсии = Новый Массив;
РазрешенныеВерсии.Добавить("10.3.24");
// Добавляем недостающую версию вручную:
РазрешенныеВерсии.Добавить("10.3.25");
РазрешенныеВерсии.Добавить("10.3.25.1");
После внесения этих правок и сохранения конфигурации, при запуске в режиме Предприятия система успешно опознает версию и запустит необходимые процедуры обработки данных.
Если вы планируете обновлять базу «рывком» через множество релизов (например, до 10.3.66), и вам нужно просто проскочить этот барьер, рассмотрим вариант с временным отключением проверки в процедуре ВыполнитьОбновление. Найдем соответствующую процедуру и проанализируем её структуру.
Нам нужно найти блок, где ТекущаяВерсияИБ сравнивается с версией метаданных. Пример корректировки:
Процедура ВыполнитьОбновление() Экспорт
ТекущаяВерсияИБ = Константы.НомерВерсииКонфигурации.Получить;
// Если мы точно уверены, что конфигурация поставщика корректна,
// можем временно форсировать версию для прохождения проверки
// ТекущаяВерсияИБ = "10.3.24"; // Обманный маневр для системы
// ... далее идет стандартный код ...
КонецПроцедуры
Важный нюанс: Просто закомментировать весь блок обновления — плохая идея. В УТ 10.3 при каждом значимом релизе запускаются фоновые или явные обработки (например, пересчет регистров НДС или заполнение новых справочников для торгового оборудования). Если их пропустить, в версии 10.3.66 вы получите «битые» данные или неработающий функционал касс.
Поскольку конечная цель — установка современного кассового оборудования (ККТ), выясним причины, по которым нельзя обновляться «как попало». Между версиями 10.3.25 и 10.3.66 лежат критические изменения:
МенеджерОборудования.Для безопасного обновления рекомендуем делать промежуточные остановки на следующих «контрольных точках»:
Если в вашей базе много доработок, проанализируем стратегию «чистого» обновления. Вместо того чтобы мучаться с объединением каждого релиза, попробуйте следующий алгоритм:
1. Обновите Конфигурацию поставщика до целевого релиза (например, 10.3.66) через «Поддержка — Обновить конфигурацию», выбирая последовательно cf-файлы.
2. При сравнении основной конфигурации с новой конфигурацией поставщика снимите галочки со всех объектов, которые вы дорабатывали и которые не влияют на работу торгового оборудования (например, ваши уникальные отчеты, печатные формы, специфические реквизиты в справочниках).
3. Обязательно примите изменения в общих модулях РаботаСТорговымОборудованием и МенеджерОборудованияВызовСервера, так как именно там сосредоточена логика работы с новыми ККТ.
4. Если при запуске в Предприятии снова возникнет ошибка версии, воспользуйтесь методом из Шага 2, добавив нужный номер версии в массив разрешенных внутри кода. Это гарантирует, что все механизмы трансформации данных отработают корректно.