Как отменить автоматическое сопоставление закрытых модулей защиты при сравнении и объединении конфигураций в 1С?

← На главную

При внедрении дополнительных отраслевых модулей или расширений в типовые решения 1С (например, при интеграции модуля «Учет спецодежды и инвентаря» в конфигурацию КУФИБ для Казахстана от компании «1С-Рейтинг») технические специалисты часто сталкиваются со специфической проблемой. В процессе сравнения и объединения конфигураций платформа автоматически сопоставляет два закрытых (защищенных) модуля. Один из этих модулей принадлежит основной конфигурации, а второй — устанавливаемому дополнению.

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

Почему происходит автоматическое сопоставление модулей?

Давайте проанализируем внутренние механизмы работы платформы 1С. Когда мы запускаем процедуру «Сравнить, объединить с конфигурацией из файла», сопоставление объектов происходит не только по их символическим именам в дереве метаданных. Главным ориентиром для платформы служат внутренние уникальные идентификаторы объектов — GUID (Globally Unique Identifier).

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

Ниже мы подробно рассмотрим три практических метода решения этой проблемы.

Способ 1. Использование «Режима копирования объектов» (Решение через промежуточную конфигурацию)

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

Рассмотрим этот процесс по шагам:

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

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

Способ 2. Кардинальное разделение объектов через выгрузку в файлы XML (Изменение GUID)

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

Проанализируем этот алгоритм подробнее:

Откроем конфигурацию дополнительного модуля в отдельном Конфигураторе.
В главном меню выберем пункт «Конфигурация» — «Разработка конфигурации» — «Выгрузить конфигурацию в файлы...». Укажем пустую локальную папку на диске.
После завершения выгрузки откроем эту папку. Структура конфигурации теперь представлена в виде набора папок и файлов XML.
Нам необходимо найти XML-файл, описывающий конфликтующий защищенный модуль. Обычно он находится в подпапке, соответствующей типу объекта (например, ОбщиеМодули), и его имя совпадает с именем модуля в конфигурации.
Откроем этот файл с помощью любого текстового редактора (например, Notepad++).
В самом начале XML-структуры файла найдем строку, содержащую уникальный идентификатор (GUID) объекта. Он выглядит как строка формата xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.
Изменим несколько символов в этом идентификаторе, чтобы сделать его уникальным (или воспользуемся любым генератором GUID онлайн). Крайне важно изменить GUID и в файле самого модуля, и в файле-манифесте конфигурации, где этот модуль регистрируется.
В Конфигураторе выберем пункт «Конфигурация» — «Разработка конфигурации» — «Загрузить конфигурацию из файлов...» и укажем нашу измененную папку.
Сохраним конфигурацию и выгрузим ее в файл .cf.

Теперь при сравнении и объединении с основной конфигурацией платформа увидит измененный модуль как совершенно новый независимый объект, так как его GUID больше не совпадает с GUID модуля защиты основной конфигурации.

Способ 3. Запрос специализированного файла интеграции у разработчика

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

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

Разработчик может предоставить готовый файл объединения (например, .cfu или специальный .cf), в котором внутренние коллизии модулей защиты уже устранены на уровне исходного кода поставки.
Использование официального дистрибутива интеграции гарантирует корректную работу системы лицензирования, так как закрытые модули могут обращаться к внешним компонентам защиты (например, DLL-библиотекам), которые ожидают строго определенные имена и свойства объектов метаданных.

Как восстановить поддержку поставщика после «Режима копирования»?

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

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

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