Как поставить конфигурацию 1С на поддержку при несовпадении UUID метаданных и избежать потери данных?

← На главную

При сопровождении нетиповых баз данных 1С специалисты часто сталкиваются с необходимостью вернуть доработанную конфигурацию на поддержку. Типичный сценарий: база «Бухгалтерия предприятия 3.0» находится в режиме «Редактирование с сохранением поддержки» (на всех объектах отображаются желтые кубики), в нее внесены незначительные изменения (пара справочников, документов или новых реквизитов). Задача заключается в том, чтобы вернуть «замочки» на все типовые объекты, оставив возможность редактирования только для реальных доработок.

Однако при попытке выполнить стандартную процедуру объединения или загрузки конфигурации поставщика разработчик может столкнуться с крайне опасной ситуацией: платформа при сохранении изменений (клавиша F7) инициирует масштабную реструктуризацию таблиц базы данных с удалением существующих реквизитов, справочников или документов. Это происходит из-за несовпадения внутренних уникальных идентификаторов (UUID/GUID) метаданных в основной конфигурации и конфигурации поставщика.

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

Почему возникает расхождение UUID метаданных?

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

Имя объекта (например, справочник Контрагенты) — текстовое имя, видимое разработчику и пользователям.
Внутренний уникальный идентификатор (UUID) — скрытая 128-битная строка (GUID), по которой платформа однозначно сопоставляет объект метаданных с физическими таблицами в СУБД (например, таблица _Reference123).

Если в прошлом обновления конфигурации накатывались некорректно — например, через простое сравнение и объединение с файлом .cf (без использования стандартного механизма поддержки) или путем копирования объектов через буфер обмена (Ctrl+C / Ctrl+V), — внутренние UUID объектов в основной конфигурации и конфигурации поставщика начинают различаться. Внешне объекты выглядят абсолютно одинаково, но для платформы это принципиально разные сущности.

Когда вы пытаетесь загрузить «чистую» конфигурацию поставщика поверх вашей основной, платформа заменяет ваши «неправильные» UUID на «правильные» UUID поставщика. При обновлении конфигурации базы данных (F7) система видит, что старый объект исчез, а вместо него появился новый. СУБД выполняет команду удаления старой таблицы (вместе со всеми вашими данными!) и создает новую пустую таблицу.

Шаг 1. Точная диагностика проблемы

Прежде чем предпринимать какие-либо действия, нам необходимо точно выяснить, какие объекты имеют расхождения по внутренним идентификаторам. Обычное сравнение конфигураций по умолчанию сопоставляет объекты по именам, скрывая от нас критические различия в UUID.

Проанализируем ситуацию с помощью встроенных механизмов платформы. Выполним следующие шаги по шагам:

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

Поскольку мы отключили сопоставление по именам, платформа выполнит сравнение исключительно по внутренним UUID метаданных. В результате мы увидим реальную картину: все объекты, чьи идентификаторы различаются, отобразятся как удаленные в одной конфигурации и созданные в другой. Если в списке сравнения появились типовые константы, документы или справочники (например, регистр сведений ЦеныНоменклатурыДокументов), это верный сигнал того, что прямое обновление или загрузка .cf файла приведет к полной очистке данных в этих таблицах.

Способ 2. Восстановление таблицы сопоставления правил поддержки (Рекомендуемый метод)

Если мы выяснили, что физические UUID объектов базы данных отличаются от UUID поставщика, нам необязательно физически менять идентификаторы в базе данных (что сопряжено с огромными рисками). Платформа 1С хранит связи между объектами в специальной внутренней таблице сопоставления поддержки. Мы можем заставить систему заново перестроить эти связи по именам объектов.

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

Обязательно создаем резервную копию базы данных (бэкап) перед началом любых работ!
Выгружаем текущую основную конфигурацию в файл (меню Конфигурация — Сохранить конфигурацию в файл..., назовем его custom_work.cf).
Переходим в меню Конфигурация — Поддержка — Настройка поддержки и полностью снимаем конфигурацию с поддержки. При этом физическая структура таблиц и все данные пользователей остаются абсолютно нетронутыми.
Выполняем операцию Конфигурация — Сравнить, объединить с конфигурацией из файла. В качестве файла выбираем чистый, типовой файл поставщика (.cf) строго той же самой версии, которая установлена в вашей базе (например, 3.0.46.19).
Платформа обнаружит, что конфигурация не находится на поддержке, сопоставит объекты по именам и выдаст диалоговое окно с вопросом: «Поставить на поддержку?». Отвечаем «Да».
В открывшемся окне сравнения и объединения снимаем абсолютно все флажки. Нам не нужно переносить никакие свойства или объекты из файла поставщика в основную конфигурацию. Наша цель — только зарегистрировать правила поддержки.
Нажимаем кнопку «Выполнить». Платформа создаст новые правила поддержки, сопоставив имена ваших измененных объектов с оригинальными объектами поставщика и сохранив ваши физические UUID.
Выполняем обновление конфигурации базы данных (клавиша F7). Реструктуризация данных проводиться не будет, так как метаданные физически не менялись, а «замочки» вернутся на свои места.

Способ 3. Физическое исправление UUID через выгрузку в XML (Для опытных разработчиков)

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

Начиная с платформы 8.3, разработчикам доступен мощный инструмент выгрузки конфигурации в файлы XML. Проанализируем, как использовать его для решения нашей проблемы:

Выгружаем конфигурацию поставщика в файлы XML через меню Конфигурация — Выгрузить конфигурацию в файлы... в отдельную папку (например, C:\XML_Vendor).
Аналогичным образом выгружаем нашу основную конфигурацию в другую папку (например, C:\XML_Custom).
Структура выгрузки представляет собой набор папок и файлов XML, где каждый объект метаданных описан индивидуально. Например, описание справочника содержится в файле со структурой:


<MetaDataObject>
    <Catalog uuid="d3b07384-d113-4e4a-a0f1-1e24743c7b80">
        <Properties>
            <Name>Контрагенты</Name>
            ...

Используя специализированные скрипты или внешние обработки (широко представленные на специализированных ИТ-ресурсах), производим сопоставление файлов по тегу <Name> и заменяем значения атрибута uuid в файлах нашей доработанной конфигурации на UUID из конфигурации поставщика.
После успешной автоматической замены загружаем измененные файлы обратно в конфигуратор через меню Конфигурация — Загрузить конфигурацию из файлов....

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

Способ 4. Современное решение — Перенос доработок в Расширения

Если вы работаете с современными конфигурациями на управляемых формах (такими как «Бухгалтерия предприятия 3.0»), лучшим архитектурным решением будет полный отказ от изменения основной конфигурации и перевод всех доработок в Расширения конфигурации.

Выясним преимущества этого подхода:

Основная конфигурация возвращается на полную поддержку («на замок»). Это позволяет обновлять базу в автоматическом режиме за считанные минуты.
Все добавленные реквизиты, справочники, документы и программный код переносятся в отдельный контейнер расширения, который не заменяет конфигурацию поставщика, а накладывается поверх нее динамически.
Проблема несовпадения UUID навсегда уходит в прошлое.

Для реализации этого сценария создайте новое расширение, перенесите туда все добавленные реквизиты и объекты, напишите обработку для переноса данных из старых (измененных) реквизитов основной конфигурации в новые реквизиты расширения, после чего смело загружайте чистую конфигурацию поставщика.

Групповое изменение правил поддержки в современных версиях 1С

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

Чтобы быстро установить правила поддержки для множества объектов одновременно:

В окне «Настройка поддержки» выделите родительскую ветку метаданных (например, нажав правой кнопкой мыши по ветке Справочники).
Выберите пункт «Установить правило».
В появившемся окне выберите режим Объект поставщика не редактируется и установите флажок Применить к подчиненным объектам.
Также вы можете использовать стандартное множественное выделение объектов в дереве с помощью клавиш Shift или Ctrl, чтобы точечно установить замочки на выбранную группу элементов за один клик.

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