При разработке в 1С с использованием расширений часто возникает одна и та же проблема: при создании внешней обработки в Конфигураторе конструктор запросов не видит объекты метаданных (справочники, документы, регистры), которые были добавлены в расширении. Это создает неудобства, заставляя искать альтернативные способы написания и отладки кода. Разберем, почему так происходит и какие существуют эффективные методы для решения этой задачи.
Основная причина такого поведения заключается в контексте выполнения. Внешняя обработка, открытая в Конфигураторе, работает в контексте основной конфигурации и ничего не "знает" о подключенных расширениях. А вот в режиме "1С:Предприятие" система уже работает в объединенном контексте, где видны и объекты основной конфигурации, и объекты всех активных расширений.
Рассмотрим несколько практических подходов, которые помогут комфортно работать с запросами в расширениях.
Это самый популярный и надежный способ. Идея проста: мы создаем и отлаживаем запрос в той среде, где видны все нужные нам данные, — в режиме "1С:Предприятие", а затем переносим готовый текст запроса в код.
Рассмотрим по шагам:
Запустите информационную базу в режиме "1С:Предприятие".
Откройте инструмент "Консоль запросов". Это может быть как стандартная обработка с диска ИТС, так и любая из множества усовершенствованных версий, которые часто распространяются в виде расширений (например, от сообщества Infostart).
В открывшейся консоли вы увидите полное дерево метаданных, включая все таблицы, созданные в вашем расширении. Здесь конструктор запросов будет работать корректно.
Составьте необходимый запрос. Вы можете выполнять его, анализировать результаты, смотреть временные таблицы и план выполнения, то есть проводить полноценную отладку.
Когда запрос полностью готов и работает как надо, скопируйте его текст.
Вернитесь в Конфигуратор и вставьте скопированный текст в модуль вашей обработки или расширения, присвоив его свойству Текст объекта Запрос.
Этот метод, как отмечают на форуме, имеет и побочный положительный эффект: он заставляет лучше изучить язык запросов и со временем начать писать их вручную, без конструктора, что повышает уровень квалификации разработчика.
Вместо того чтобы создавать внешнюю обработку (файл .epf), можно создать объект метаданных Обработка непосредственно внутри самого расширения. Такой подход имеет свои преимущества:
Единый контекст. Код обработки, находящейся в расширении, "видит" все остальные объекты этого же расширения по умолчанию.
Целостность решения. Весь связанный функционал находится в одном месте — внутри расширения. Это упрощает его перенос и обновление.
Интеграция с БСП. Такие обработки можно легко встроить в интерфейс конфигурации через подсистему "Дополнительные отчеты и обработки" Библиотеки стандартных подсистем (БСП), если это необходимо.
Этот способ идеально подходит, если ваша обработка является неотъемлемой частью функционала, который добавляет расширение, а не разовым сервисным инструментом.
В обсуждении упоминается "ИР" — это, как правило, сокращение от "Интерактивная разработка". Такие инструменты (например, входящие в библиотеку "Инструменты разработчика") позволяют редактировать код модулей расширения прямо в режиме "1С:Предприятие" и применять изменения "на лету", без перезапуска сеанса и обновления конфигурации. Это значительно ускоряет цикл разработки и отладки.
Помимо прямого ответа на вопрос, в обсуждении были затронуты важные аспекты поддержки расширений. Один из участников поделился полезным приемом для контроля актуальности кода после обновлений основной конфигурации.
Идея заключается в том, чтобы в каждой перехваченной процедуре или функции с аннотацией &Вместо делать проверку на версию конфигурации. Если версия изменилась, система будет сообщать об этом пользователю (или разработчику), сигнализируя о необходимости проверить, не изменилась ли логика в типовом коде.
Посмотрим на пример:
В расширении создается общий модуль, например СОГ_ДопФункции, с экспортной функцией проверки версии:
Функция ПроверитьВерсиюИсполняемогоКода(пРазрешеноРаботатьВерсии, Отказ = Ложь) Экспорт
// Контроль версии 1С
Если Метаданные.Версия <> пРазрешеноРаботатьВерсии Тогда
ТекстСообщения = "Сменилась версия 1С с '%1' на '%2', необходимо проверить функционал модуля! (сообщите программисту, он должен был проверить)";
ТекстСообщения = СтрШаблон(ТекстСообщения, пРазрешеноРаботатьВерсии, Метаданные.Версия);
ОбщегоНазначенияКлиентСервер.СообщитьПользователю(ТекстСообщения, , , , Отказ);
КонецЕсли;
Возврат Отказ;
КонецФункции
Затем в каждой процедуре, заимствованной в расширение, в самом начале делается вызов этой функции с указанием версии конфигурации, для которой писался этот код:
&НаКлиенте
&Вместо("НовыйДоговор")
Процедура СОГ_НовыйДоговор(Команда)
// Проверяем, не изменилась ли конфигурация
СОГ_ДопФункции.ПроверитьВерсиюИсполняемогоКода("3.0.95.27");
// ...далее идет ваш код...
КонецПроцедуры
Такой механизм "чекпоинтов" помогает не пропустить важные изменения и своевременно адаптировать расширение после обновления основной конфигурации.
Важно отметить, что фирма "1С" знает об этой проблеме и уже работает над ее решением. Анонсировано, что в платформе версии 8.3.28 объекты из установленных расширений станут доступны во внешних отчетах и обработках прямо в Конфигураторе, в том числе в конструкторе запросов и схемах компоновки данных (СКД).
Таким образом, в ближайшем будущем описанные обходные пути могут стать неактуальными, а разработка — еще более удобной.