Как создать свой конструктор запроса в 1С: полный гайд

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

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

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

Архитектура СКД и источники данных

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

Первым шагом является определение источников данных. В стандартном конструкторе 1С это могут быть регистры, документы, справочники или объединения (UNION) нескольких таблиц. В вашем кастомном решении вы должны явно прописать эти источники в коде или в предопределенной схеме. Важно понимать, что каждый источник должен иметь уникальный псевдоним и набор доступных полей.

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

Вот основные типы источников, которые вы можете использовать в своем конструкторе:

• 📁 Таблицы базы данных — прямые ссылки на физические или виртуальные таблицы метаданных.
• 🔗 Объединения — результат операции UNION, позволяющий склеить разнородные данные с одинаковой структурой полей.
• 📊 Наборы данных запроса — готовые тексты запросов, которые передаются в СКД как источник.
• 🔄 Вложенные схемы — использование одной СКД внутри другой для модульности.

⚠️ Внимание: При использовании прямых таблиц базы данных в качестве источников убедитесь, что у пользователя есть необходимые права доступа (RLS). СКД автоматически применяет ограничения прав, но только если источник описан корректно через метаданные, а не через произвольный текст запроса.

Проектирование интерфейса конструктора

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

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

Отдельное внимание стоит уделить блоку отборов. Это самая сложная часть интерфейса, так как пользователю нужно не только выбрать поле, но и указать условие (Равно, Больше, В периоде) и значение. Для реализации динамических условий часто применяют комбинацию полей ввода и выпадающих списков. Логика переключения видимости элементов управления реализуется через обработчики событий ПриИзменении.

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

Настройка параметров и полей вывода

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

Процесс добавления поля в выборку выглядит следующим образом. Сначала вы получаете ссылку на поле из источника данных, используя метод КомпоновщикНастроек.ИсточникДанных.Поля.Найти. Затем создается новый элемент в коллекции полей выбора, и ему присваивается найденное поле. Важно также настроить заголовок поля, который будет виден пользователю в итоговой таблице отчета.

Для реализации гибкости часто используют механизм Параметров. Параметры позволяют передавать в запрос значения, которые пользователь вводит в форму перед запуском. Например, параметр "Период" или "Организация". В конструкторе необходимо предусмотреть возможность привязки полей отборов к этим параметрам. Это позволяет делать запросы параметризированными и эффективными с точки зрения использования индексов базы данных.

Рассмотрим таблицу соответствия элементов интерфейса и свойств СКД, которую полезно держать перед глазами при разработке:

Элемент интерфейса	Свойство СКД	Тип данных	Описание
Список доступных полей	ИсточникДанных.Поля	Коллекция	Все поля, которые можно выбрать
Чекбокс "Включить"	Настройки.ПоляВыбора	Булево	Флаг добавления поля в SELECT
Выпадающий список условий	Настройки.Отборы	Перечисление	Тип сравнения (Равно, Больше и т.д.)
Поле ввода значения	Настройки.Отборы.Значение	Произвольный	Конкретное значение для фильтрации
Список группировок	Настройки.Структура	Дерево	Иерархия группировок (GROUP BY)

Программная реализация формирования запроса

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

Ключевой метод здесь — КомпоновщикНастроек.Закомпоновать(). Он преобразует визуальные настройки в готовый объект МакетКомпоновкиДанных. Далее этот макет передается в конструктор Новый ПроцессКомпоновкиДанных, который и выполняет всю грязную работу по генерации SQL-кода и выборке данных из СУБД.

Важно правильно передать параметры в процесс компоновки. Если вы использовали в отборах переменные формы, их необходимо собрать в коллекцию ПараметрыКомпоновкиДанных. Типы данных параметров должны строго соответствовать типам полей, с которыми они сравниваются. Несовпадение типов (например, передача строки в поле типа Число) вызовет исключение на этапе выполнения.

Как оптимизировать большой запрос?

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

Пример кода для запуска процесса компоновки может выглядеть так:

Процедура СформироватьОтчет(Команда)
// Переносим настройки из формы в компоновщик
ЗаполнитьНастройкиКомпоновщика();

// Получаем готовый макет
Макет = КомпоновщикНастроек.Закомпоновать();

// Создаем процесс выполнения
Процесс = Новый ПроцессКомпоновкиДанных(Макет, ПараметрыКомпоновки);

// Получаем результат
Результат = Процесс.Результат;

// Вывод на экран
ОтчетТабличныйДокумент.Очистить();
ОтчетТабличныйДокумент.Вывести(Результат);
КонецПроцедуры

Обработка ошибок и валидация данных

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

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

При возникновении ошибки СУБД текст исключения часто бывает слишком техническим и непонятным для бухгалтера или менеджера. Рекомендуется анализировать текст ошибки и выводить пользователю адаптированное сообщение. Например, вместо "Ошибка синтаксиса текста запроса в строке 5..." написать "Невозможно сгруппировать по полю 'Комментарий', так как оно имеет текстовый тип и не участвует в агрегации".

⚠️ Внимание: Никогда не выводите полный текст системной ошибки с трассировкой стека в обычном сообщении пользователю. Это нарушает безопасность и пугает конечных пользователей. Сохраняйте полные логи во внутреннем журнале регистрации для анализа разработчиком.

Особое внимание уделите проверке на дублирование псевдонимов. Если пользователь добавил одно и то же поле в выборку дважды с разными настройками агрегации (например, один раз "Сумма", второй раз "Среднее"), система должна либо автоматически переименовать поля, либо запросить уточнение имен.

Расширенные возможности и оптимизация

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

Еще одной мощной функцией является поддержка вычисляемых полей. Позвольте пользователям создавать свои формулы прямо в конструкторе. Например, поле "Маржинальность", которое рассчитывается как отношение прибыли к выручке. В СКД это реализуется через добавление поля с выражением, где в формуле используются другие поля выборки.

Не забывайте про производительность. Конструктор, позволяющий выбирать любые поля без ограничений, может сгенерировать запрос, который "повесит" базу данных на несколько минут. Внедрите механизм лимитов: ограничение на максимальное количество строк для предпросмотра, запрет на выбор полей с типом "ХранилищеЗначения" или больших текстовых полей без необходимости.

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

Часто задаваемые вопросы (FAQ)

Можно ли сохранить настройки конструктора для повторного использования?

Да, объект НастройкиКомпоновкиДанных поддерживает сериализацию в XML или XDTO. Вы можете сохранять настройки пользователя в регистр сведений или в файл, а затем загружать их при следующем запуске отчета. Это позволяет создавать библиотеки популярных отчетов.

Как добавить в конструктор поля из нескольких разных регистров?

Для этого необходимо использовать механизм Объединения наборов данных (UNION) в источниках данных СКД. Поля в объединяемых таблицах должны иметь совместимые типы данных. После настройки объединения они будут доступны в конструкторе как единый виртуальный источник.

Почему запрос выполняется медленно при выборе многих полей?

Выбор большого количества полей, особенно тех, которые не индексируются или требуют вычислений (как виртуальные таблицы остатков), увеличивает время выполнения. Старайтесь выбирать только необходимые поля и используйте отборы по периодам для ограничения объема выборки.

Можно ли ограничить доступ к определенным полям в конструкторе?

Да, это реализуется через RLS (Record Level Security) или программно, удаляя недоступные поля из коллекции КомпоновщикНастроек.ИсточникДанных.Поля перед показом формы пользователю, в зависимости от его роли в системе.