Часто разработчики сталкиваются с ситуацией: в режиме конфигуратора открывается внешняя обработка, в ней запускается конструктор запроса, но в списке таблиц отсутствуют регистры сведений или другие объекты, которые были созданы в подключенном расширении. Это может сбить с толку, так как кажется, что система "не видит" нужные данные.
Давайте разберемся, почему так происходит, является ли это ошибкой, и какие есть способы для комфортного написания запросов к данным из расширений.
Основная причина такого поведения кроется в изоляции контекстов. В режиме конфигуратора контекст основной конфигурации и контекст каждого расширения существуют отдельно друг от друга. Конструктор запроса, который мы запускаем из модуля внешней обработки (или из модуля основной конфигурации), "знает" только о тех объектах метаданных, которые описаны в самой основной конфигурации. Он не имеет доступа к метаданным, добавленным в расширениях.
Важный момент: это штатное поведение платформы, а не ошибка. Хотя конструктор запроса и встроенная проверка синтаксиса в конфигураторе будут ругаться на несуществующие таблицы и поля, сам запрос, написанный текстом, будет корректно выполняться в режиме "1С:Предприятие". В пользовательском режиме платформа объединяет основную конфигурацию и все активные расширения в единую, результирующую конфигурацию, и все объекты становятся доступны.
Фирма "1С" знает об этом неудобстве и планирует улучшения. Ожидается, что в платформе версии 8.3.28 объекты из расширений станут видимы в конструкторе запросов, запущенном из внешних обработок в конфигураторе.
Пока ожидаются доработки платформы, существует несколько проверенных и надежных способов составить и отладить запрос к данным из расширения. Рассмотрим их по порядку.
Это самый удобный, быстрый и рекомендуемый метод. Консоль запросов, запущенная в пользовательском режиме, видит полную картину метаданных, включая все объекты из всех подключенных расширений.
Разберем по шагам:
Этот способ позволяет избежать ошибок и опечаток, а также дает возможность сразу проверить корректность работы запроса на реальных данных.
Логика этого метода проста: если запустить конструктор из контекста самого расширения, то он увидит все объекты этого расширения. Для этого можно создать временную процедуру в любом общем модуле внутри расширения, кликнуть правой кнопкой мыши и выбрать "Конструктор запроса с обработкой результата".
Однако у этого способа есть существенный недостаток. Такой конструктор увидит объекты своего расширения, но не увидит объекты основной конфигурации, если они не были предварительно "позаимствованы" в это расширение. Этот метод подходит только в том случае, если ваш запрос обращается исключительно к таблицам, созданным в самом расширении.
Как показывает практика, если у вас несколько расширений, которые добавляют метаданные, становится неудобно переключаться между ними, чтобы "поймать" нужный контекст. Поэтому этот метод менее универсален, чем работа с консолью.
Это самый прямой путь для опытных разработчиков. Вы можете просто написать текст запроса вручную в модуле обработки. При этом нужно быть готовым к тому, что встроенный синтаксический анализатор конфигуратора будет подчеркивать названия таблиц и полей из расширения как ошибки, выдавая сообщения вроде "Поле объекта не обнаружено".
Просто игнорируйте эти предупреждения. Как мы уже выяснили, в режиме исполнения все будет работать корректно.
Существует еще одна причина, по которой ваш запрос может не работать даже в режиме "Предприятие". Чтобы новые объекты из расширения (например, наш РегистрСведений) были в принципе доступны для запросов из основной конфигурации, у расширения должно быть установлено правильное Назначение.
Проанализируем два основных варианта:
Адаптация: Этот тип назначения следует выбирать, когда вы добавляете новые объекты или изменяете существующие для нужд конкретного внедрения, дорабатывая типовую логику. Объекты из такого расширения становятся частью общей конфигурации и доступны отовсюду. Для решения нашей задачи нужно выбрать именно это назначение.Дополнение: Этот тип используется для создания изолированных сервисных функций, например, отчетов или обработок, которые не должны вмешиваться в основную логику. Объекты, созданные в расширении с этим назначением, не будут видны для запросов из основной конфигурации.Вывод: перед тем как искать ошибку в запросе, убедитесь, что в свойствах вашего расширения установлено назначение "Адаптация".
Иногда можно услышать категоричное мнение: "Не надо создавать регистры сведений в расширении". Это чрезмерное упрощение. Создание собственных объектов метаданных — одна из ключевых и самых мощных возможностей механизма расширений, позволяющая гибко дорабатывать типовые решения, не снимая их с поддержки.
Проблемы, о которых обычно говорят в этом контексте, связаны не с самим фактом создания регистра, а с архитектурной сложностью поддержки множества расширений, которые могут изменять одни и те же данные или зависеть друг от друга. Поддерживать такую систему действительно трудно.
Если для реализации одной крупной задачи вы создали несколько расширений, которые тесно связаны между собой, стоит рассмотреть возможность их объединения в одно. Это упростит сопровождение, обновление и понимание общей логики доработок.