Часто в процессе разработки возникает необходимость создать отчет, который функционально похож на уже существующий. Самым простым решением кажется обычное копирование объекта в Конфигураторе или файла на диске. Однако после таких манипуляций разработчики сталкиваются с досадной проблемой: при попытке открыть оба отчета система «зависает» на первом или просто переключает фокус на уже открытое окно, отказываясь запускать вторую копию. Давайте разберемся, почему это происходит и как правильно клонировать отчеты в среде 1С:Предприятие.
Платформа 1С:Предприятие идентифицирует объекты метаданных не только по их имени, но и по внутреннему уникальному идентификатору — GUID (Globally Unique Identifier). Когда мы просто копируем файл внешнего отчета через проводник или используем банальное «Копировать-Вставить» в дереве конфигурации, GUID исходного объекта дублируется в копии.
Для системы два объекта с одинаковым GUID являются одним и тем же функциональным узлом. В результате, когда вы пытаетесь открыть вторую форму, платформа «считает», что отчет уже запущен, и просто переводит пользователя на существующее окно вместо инициализации нового экземпляра.
Если вы работаете с внешними отчетами (файлы с расширением .erf), самым надежным и быстрым способом будет использование встроенного инструментария Конфигуратора. Вместо того чтобы копировать файл в операционной системе, выполните следующие действия:
Этот простой шаг заставляет платформу принудительно сгенерировать новый GUID для нового файла. В результате система будет воспринимать их как два независимых объекта, что позволит без проблем открывать их одновременно в одном сеансе работы 1С.
Ситуация становится сложнее, когда отчет находится внутри конфигурации. Простого переименования объекта в дереве метаданных часто оказывается недостаточно, так как GUID форм, команд и макетов внутри объекта остаются прежними. Если вы просто скопируете объект в дереве, вы получите «клон» с теми же внутренними ссылками.
Рассмотрим пошагово, как избежать проблем при копировании встроенных объектов:
Имя.ЭтаФорма или жестко заданные имена метаданных.Опытные разработчики рекомендуют совмещать эти методы: после копирования объекта в конфигурации рекомендуется пересоздать основные формы (особенно ФормуОтчета), чтобы все внутренние идентификаторы элементов управления гарантированно обновились.
При копировании программного модуля будьте внимательны к коду, где используются прямые ссылки на метаданные. Например, если в коде прописано обращение к объекту:
// Пример потенциально опасного кода при копировании
Метаданные.Отчеты.МойИсходныйОтчет.Макеты.ОсновнойМакет;
После копирования отчета этот код в новой копии все равно будет ссылаться на старый объект. Необходимо либо использовать универсальные обращения, такие как ЭтотОбъект, либо своевременно обновлять ссылки в тексте модуля в соответствии с новым именем объекта.
Подводя итог, можно сказать, что решение проблемы всегда кроется в обеспечении уникальности GUID. Для внешних файлов достаточно функции сохранения копии, а для внутренних — создания новых форм, что позволит вам избежать конфликтов и обеспечить стабильную работу вашей конфигурации.