Как исправить ошибку «Объект метаданных не найден по полному имени» при открытии типового отчета как внешнего?

При разработке и адаптации типовых бухгалтерских отчетов (например, «Карточка счета», «Оборотно-сальдовая ведомость» и др.) в конфигурациях «1С:ERP Управление предприятием», «1С:Комплексная автоматизация» или «1С:Бухгалтерия предприятия» разработчики часто сохраняют типовой отчет во внешний файл с расширением .erf. Однако при попытке открыть такой файл в режиме «1С:Предприятие» возникает критическая ошибка:

Объект метаданных не найден по полному имени: "ВнешнийОтчет.КарточкаСчета".
ВызватьИсключение ЗаголовокОшибки + Символы.ПС + Символы.ПС + ОписаниеОшибки()

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

Причины возникновения ошибки

Проанализируем архитектуру типовых решений на базе Библиотеки Стандартных Подсистем (БСП) и подсистемы бухгалтерских отчетов:

1. Отсутствие модуля менеджера у внешних отчетов. В платформе 1С:Предприятие внешние отчеты содержат только модуль объекта и модули форм. В типовых же отчетах значительная часть бизнес-логики (формирование структуры колонок, макетов, расшифровок) вынесена в модуль менеджера. Типовой программный код активно использует конструкции прямого обращения к менеджеру через менеджер коллекции: Отчеты[ИмяОтчета]. Для внешнего отчета такая конструкция возвращает ошибку или Неопределено.
2. Проверка идентификаторов метаданных БСП. При инициализации формы вызываются методы общих модулей (например, БухгалтерскиеОтчетыВызовСервера или функции работы с метаданными). Они пытаются получить объект по полному имени через Метаданные.НайтиПоПолномуИмени() или через справочник «Идентификаторы объектов метаданных». Так как внешнего отчета нет в дереве конфигурации, система формирует имя вида ВнешнийОтчет.ИмяОтчета и аварийно завершает работу с исключением.
3. Недостаточность функции «СведенияОВнешнейОбработке». Стандартное добавление экспортной функции БСП для регистрации отчета в справочнике «Дополнительные отчеты и обработки» регистрирует отчет в интерфейсе, но не отменяет внутренних жестких связей логики формы с модулем менеджера и общими модулями типового отчета.

Рассмотрим основные способы решения задачи в зависимости от стоящих перед разработчиком целей.

Способ 1. Перенос логики модуля менеджера в модуль объекта внешнего отчета

Если нам необходимо сохранить типовую форму отчета и ее интерфейс, разберем по шагам, как переписать внутренние вызовы:

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

   
   // Типовой вызов менеджера:
   // МенеджерОтчета = Отчеты[БухгалтерскиеОтчетыКлиентСервер.ПолучитьИдентификаторОбъекта(Форма)];
   // МенеджерОтчета.СформироватьОтчет(...);
   

   получаем объект отчета из реквизита формы:
   Скопировать код

   
   ОбъектОтчета = РеквизитФормыВЗначение("Отчет");
   ОбъектОтчета.СформироватьОтчет(...);
   

3. Локализуем вызовы общих модулей подсистемы. Находим в модулях формы и объекта вызовы сервисных процедур, таких как: БухгалтерскиеОтчетыВызовСервера.ОбработкаПроверкиЗаполнения(ЭтотОбъект, Отказ); Копируем исходный код этих процедур напрямую в модуль объекта нашего внешнего отчета и вызываем локальные методы вместо процедур общего модуля.

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

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

1. Экспортируем схему компоновки данных (СКД) из типового отчета в XML-файл или копируем ее через буфер обмена.
2. Создаем новый чистый внешний отчет и загружаем в него полученную СКД.
3. Не копируем типовые формы и модули подсистемы бухгалтерских отчетов. Используем автогенерируемую форму платформы или стандартную форму отчета БСП.
4. В настройках СКД определяем требуемые параметры и поля. Отчет будет формироваться стандартным процессом компоновки без обращения к специализированным механизмам типовой конфигурации.

Способ 3. Создание расширения конфигурации (рекомендуемый вариант)

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

1. Создаем новое расширение конфигурации.
2. Добавляем в расширение типовой отчет (или создаем новый отчет непосредственно в дереве метаданных расширения).
3. При добавлении отчета в расширение сохраняется полноценная структура метаданных: создается модуль менеджера, модуль объекта и формы.
4. При необходимости можно переопределить методы типового отчета с помощью аннотаций &Вместо, &Перед или &После, избегая любых проблем с поиском метаданных в общих модулях БСП.

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