Вопрос обновления конфигураций 1С через файл конфигурации .cf часто окутан мифами. Некоторые специалисты считают это «быстрым путем», позволяющим обойти ограничения или сэкономить время. В этой статье мы подробно разберем, почему способ доставки обновления не влияет на юридические обязательства, какие технические опасности таит в себе «прыжок» через несколько версий и как правильно организовать процесс обновления, если вы решили использовать CF.
Начнем с самого распространенного заблуждения: якобы использование CF-файла вместо штатного файла обновления CFU освобождает от необходимости иметь действующую подписку 1С:ИТС. Это абсолютно не соответствует действительности. Рассмотрим этот вопрос с точки зрения лицензионного соглашения.
Для любой версии программ 1С (за исключением Базовых конфигураций), право на получение и использование любых обновлений — будь то программные файлы, патчи или новые релизы — предоставляется только при наличии действующего договора информационно-технологического сопровождения (ИТС). Не имеет значения, каким техническим способом обновление попало в вашу базу:
.cfu..cf.Если на момент обновления у организации нет активной подписки ИТС, любое изменение конфигурации на более новую версию признается нарушением авторских прав. Более того, современные конфигурации на базе БиблиотекиСтандартныхПодсистем (БСП) имеют встроенные механизмы проверки легальности получения обновлений. При запуске программа может заблокировать работу или выводить постоянные предупреждения о нелегальном использовании, если не обнаружит подтвержденного права на обновление в облачном сервисе 1С.
Давайте проанализируем, в чем заключается разница между этими типами файлов. Файл .cfu (Configuration Update) — это «разностный» файл. Он содержит в себе только те изменения, которые произошли между конкретными старыми версиями и текущей. Файл .cf (Configuration File) — это полный слепок всей структуры конфигурации.
На первый взгляд кажется, что «накатить» полный CF проще, так как не нужно последовательно применять несколько CFU. Однако за этой простотой скрывается критическая ловушка для ваших данных.
Рассмотрим ситуацию: у вас установлена 1С:Розница 2.2.10.19, а вы хотите сразу перейти на 2.3.4. Если вы просто возьмете CF от последней версии и загрузите его в базу, вы обновите только структуру метаданных (таблицы, колонки, типы данных). Но данные в этих таблицах сами собой не преобразуются.
В системе 1С существует понятие обработчиков обновления. Это специальные процедуры на языке 1С, которые выполняются в режиме «1С:Предприятие» после внесения изменений в структуру базы. Разберем по шагам, что происходит внутри:
CF старый объект просто исчезнет, а новый останется пустым.Если вы проигнорируете цепочку релизов, эти обработчики просто не запустятся или отработают некорректно. В результате вы получите «битую» базу. Самое опасное здесь то, что ошибки могут проявиться не сразу, а через месяц, когда бухгалтер начнет закрывать период или сдавать отчетность. Исправить такие последствия в «боевой» базе практически невозможно без отката к старой копии и потери внесенных за месяц данных.
Если вам все же необходимо использовать CF (например, когда штатное обновление CFU выдает ошибки или база была сильно доработана), придерживайтесь строгого алгоритма. Выясним, как сделать это безопасно.
Нельзя брать случайные релизы. Зайдите на сайт поддержки пользователей 1С и для каждого релиза откройте файл update.htm. Там указано, с каких именно предыдущих версий возможно обновление. Эти версии называются «ключевыми» или «переходными».
Рассмотрим правильный цикл обновления:
Конфигурация — Поддержка — Обновить конфигурацию.Выбор файла обновления и указываем CF-файл следующего ключевого релиза (не последнего!).Администрирование — Обслуживание — Результаты обновления программы.После прохождения всей цепочки до актуального релиза крайне рекомендуется выполнить процедуру «Тестирование и исправление». Это поможет выявить возможные нарушения логической целостности ссылок, которые могли возникнуть при масштабном изменении структуры.
Чтобы понять, насколько важен запуск в режиме «Предприятие», посмотрим на структуру модуля обновления. В коде конфигурации это выглядит примерно так:
Процедура ПриДобавленииОбработчиковОбновления(Обработчики) Экспорт
Обработчик = Обработчики.Добавить();
Обработчик.Версия = "2.2.11.5";
Обработчик.Процедура = "ОбменДаннымиРозница.ПересчитатьОстаткиПоСкладам";
Обработчик.РежимВыполнения = "Отложенно";
КонецПроцедуры
Система БиблиотекаСтандартныхПодсистем проверяет текущую версию в базе и версию в конфигураторе. Если вы перескочили с 2.2.10 сразу на 2.3.4, система может просто не увидеть этот обработчик для версии 2.2.11, так как логика обновления часто завязана на последовательный перебор версий в массиве обработчиков.
Подведем итог нашему анализу:
CFU или автоматический поиск обновлений — это минимизирует риск случайного «перескакивания» важной версии.Помните, что время, сэкономленное на «быстром» обновлении, несопоставимо с временем и затратами на восстановление данных в случае программного сбоя. Всегда проверяйте результаты обновления на копии базы перед применением их в рабочей среде.