← На главную

При обновлении нетиповых конфигураций или конфигураций, находящихся на поддержке с возможностью изменения, разработчики нередко сталкиваются с неожиданным поведением платформы: внесенные ранее доработки в модулях или формах не затираются типовым кодом вендора, даже если процесс обновления запускался со всеми параметрами по умолчанию. Разберем детально, как работает внутренний механизм обновления платформы 1С, почему сохраняются пользовательские изменения и как правильно переносить готовый результат на другие однотипные информационные базы.

Механизм трехстороннего сравнения конфигураций

В отличие от простого объединения двух файлов, штатная процедура обновления в 1С (через файл поставки .cf или файл обновления .cfu) использует трехстороннее сопоставление метаданных. В процессе анализа платформа одновременно сравнивает три конфигурации:

1. Старая конфигурация поставщика — эталонная версия от вендора, на которой база находилась до текущего момента.
2. Новая конфигурация поставщика — версия из файла обновления (.cfu или .cf).
3. Текущая основная конфигурация — рабочая конфигурация базы данных с внесенными пользовательскими доработками.

Проанализируем логику, которой руководствуется конфигуратор при анализе конкретного объекта (модуля, реквизита, формы):

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

Тиражирование доработанного обновления на несколько баз: анализ вариантов

Когда требуется накатить один и тот же релиз на несколько одинаковых баз с одновременным переносом собственных доработок, возникает вопрос: можно ли подготовить одну базу-эталон, а затем быстро применить результат к остальным? Рассмотрим возможные подходы, их преимущества и скрытые риски.

Вариант 1. Сравнение и объединение с конфигурацией из файла (.cf)

Самый очевидный на первый взгляд путь — выгрузить файл .cf из уже обновленной и доработанной первой базы, а затем в целевых базах выполнить команду Конфигурация — Сравнить, объединить с конфигурацией из файла.

Выясним особенности этого способа:

1. Что обновляется: Изменяется дерево объектов основной конфигурации. Номер версии в общих свойствах конфигурации станет новым, а при первом запуске в режиме «1С:Предприятие» отработают регламентные процедуры обновления данных.
2. Что не обновляется: Конфигурация поставщика, хранящаяся в служебной таблице базы, остается старой. В окне Конфигурация — Поддержка — Настройка поддержки будет отображаться номер предыдущего релиза.
3. Последствия: При попытке следующего обновления штатным файлом .cfu конфигуратор выдаст ошибку или не обнаружит подходящего обновления, поскольку файлы .cfu содержат исключительно дельту изменений между строгими номерами релизов поставщика.

Вариант 2. Полная загрузка конфигурации из файла (.cf)

Команда Конфигурация — Загрузить конфигурацию из файла полностью перезаписывает структуру метаданных и конфигурацию поставщика данными из файла .cf. Однако применять этот способ следует с крайней осторожностью.

Разберем риски механизма загрузки:

1. Платформа 1С идентифицирует объекты метаданных (справочники, документы, реквизиты, табличные части) по внутренним уникальным идентификаторам (UUID), а не по их строковым именам.
2. Если целевые базы развивались независимо или в них когда-либо вручную создавались объекты с одинаковыми именами, их внутренние идентификаторы гарантированно будут отличаться.
3. При выполнении операции «Загрузить конфигурацию» несовпадающие по UUID объекты будут расценены платформой как удаленные, а на их месте будут созданы новые. В результате реструктуризации базы данных вся накопленная пользовательская информация в соответствующих таблицах будет безвозвратно стенена. Полную загрузку допустимо применять исключительно к базам, развернутым из одной исходной копии и не имеющим независимых правок метаданных.

Вариант 3. Правильный регламент: обновление поставщика с синхронизацией доработок

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

1. Накатить на целевую базу официальный файл обновления .cfu или типовой .cf от фирмы «1С» через меню Конфигурация — Поддержка — Обновить конфигурацию. Это гарантирует корректный перевод конфигурации поставщика на новый релиз.
2. Выполнить объединение с подготовленным файлом .cf от эталонной базы через меню Конфигурация — Сравнить, объединить с конфигурацией из файла, перенеся только блок собственных изменений.

Как актуализировать конфигурацию поставщика, если объединение уже выполнено

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

1. Возьмем чистый типовой файл .cf необходимого релиза.
2. Перейдем в меню Конфигурация — Поддержка — Обновить конфигурацию и выберем указанный файл.
3. В появившемся окне настройки правил объединения снимем все флажки с метаданных и модулей.
4. Нажмем кнопку Выполнить. В результате основная рабочая конфигурация останется неизменной, а конфигурация поставщика и данные поддержки обновятся до целевой версии, восстановив возможность накатывать последующие .cfu.

Важность запуска в режиме «1С:Предприятие»

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