При разработке или анализе типовых отчетов в конфигурации 1С:Зарплата и управление персоналом (ЗУП) 3.1 программисты часто сталкиваются с ситуацией, когда текст запроса в схеме компоновки данных (СКД) выглядит предельно простым или даже «нерабочим» с точки зрения классического SQL. Однако при выполнении отчет выводит сложные данные: ФИО в нужных падежах, кадровые данные на разные даты и сведения о стажах. Это происходит благодаря механизму представлений — специальной программной надстройке над запросами.
В этой статье мы подробно разберем, как устроена эта «магия», где искать исходный код преобразований и как правильно отлаживать такие отчеты.
Разберем ситуацию: вы открываете запрос в консоли или СКД и видите там обращение к таблицам, которых не существует в структуре метаданных, например, Представления_КадровыеДанныеСотрудников. Если попытаться выполнить такой запрос напрямую, система выдаст ошибку. Секрет заключается в том, что перед выполнением запроса специальный программный обработчик находит эти «маркеры» и заменяет их на огромные куски кода со сложными соединениями, вложенными запросами и обращениями к регистрам сведений.
Проанализируем основные причины использования такого подхода:
Если нам необходимо разобраться, как именно преобразуется запрос, мы должны обратиться к общему модулю, который является «сердцем» этого механизма. Почти вся логика сосредоточена в библиотеке «Зарплата и кадры» (БЗК).
Ключевым объектом является общий модуль ЗарплатаКадрыОбщиеНаборыДанных. Именно в нем определены функции, которые парсят текст запроса и подставляют вместо маркеров реальное содержимое. Самая важная функция, которую стоит изучить — это ЗаполнитьПредставления.
Рассмотрим пример того, как это вызывается в коде отчета:
// Пример вызова в модуле объекта отчета
Процедура ПриКомпоновкеРезультата(РезультатХода, ДанныеРасшифровки, СтандартнаяОбработка)
// ... подготовка параметров ...
ЗарплатаКадрыОбщиеНаборыДанных.ЗаполнитьПредставления(ТекстЗапроса, Истина);
// Теперь переменная ТекстЗапроса содержит развернутый SQL-код
КонецПроцедуры
Выясним, какие именно конструкции в тексте запроса инициируют срабатывание механизма. Обычно они начинаются с префикса Представления_. Рассмотрим наиболее популярные:
Представления_ФИОФизическихЛиц — используется для получения ФИО. В параметрах можно указать формат (фамилия и инициалы или полное имя) и падеж.Представления_КадровыеДанныеСотрудников — самый мощный инструмент. Позволяет вытащить практически любую информацию о сотруднике: от табельного номера до текущего руководителя.Представления_СведенияОбОрганизациях — подставляет данные о КПП, ИНН, кодах ОКПО и ответственных лицах организации.Важно понимать, что эти таблицы часто описываются как временные таблицы в начале запроса. Проанализируем типичный фрагмент:
ВЫБРАТЬ
Сотрудники.Ссылка КАК Сотрудник,
&Период КАК Период
ПОМЕСТИТЬ ВТ_Сотрудники
ИЗ
Справочник.Сотрудники КАК Сотрудники
;
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
КадровыеДанные.Сотрудник КАК Сотрудник,
КадровыеДанные.Должность КАК Должность,
КадровыеДанные.Подразделение КАК Подразделение
ИЗ
Представления_КадровыеДанныеСотрудников(ВТ_Сотрудники) КАК КадровыеДанные
В данном примере механизм увидит обращение к Представления_КадровыеДанныеСотрудников, проанализирует поля, которые выбираются (Должность, Подразделение), и заменит этот вызов на соединения с регистрами КадроваяИсторияСотрудников и другими.
Для разработчика основной сложностью является невозможность просто «скопировать и запустить» запрос из СКД в консоль запросов. Чтобы увидеть финальный текст, который уходит на сервер СУБД, воспользуемся следующей методикой:
ЗаполнитьПредставления (обычно это общий модуль или модуль отчета).Также в типовых конфигурациях существует специальная обработка «Консоль запросов с поддержкой представлений» (ее можно найти на ИТС или специализированных ресурсах). Она умеет имитировать работу этого механизма, позволяя писать запросы с использованием Представления_... прямо в консоли.
Разберем, как представления интегрируются в систему компоновки данных. В ЗУП 3.1 в схемах компоновки часто используются внешние наборы данных или программная модификация текста запроса. Если вы видите, что в схеме запрос пустой или очень короткий, посмотрите в модуль объекта отчета. Там почти всегда переопределено событие ПриКомпоновкеРезультата.
Система работает по следующему алгоритму:
Почему этот механизм так активно используется именно в ЗУП, а не в БП или УТ? Дело в периодичности и историчности данных. В зарплатных отчетах нам постоянно нужно знать, кем был сотрудник на начало месяца, кем на конец, и не менялась ли у него фамилия посередине. Механизм представлений инкапсулирует в себе всю логику работы со срезами данных на разные моменты времени, освобождая разработчика от написания однотипных и громоздких ЛЕВОЕ СОЕДИНЕНИЕ с условиями по периоду.
Важный момент: если вам нужно добавить свое поле в существующий типовой отчет, использующий представления, проверьте, доступно ли оно в списке разрешенных полей для данного представления в модуле ЗарплатаКадрыОбщиеНаборыДанных. Иногда требуется расширить список выбираемых полей в параметрах вызова функции.
Таким образом, изучив работу этого механизма, вы сможете не только эффективно разбирать чужой код, но и создавать свои производительные и гибкие отчеты, используя все преимущества типовой архитектуры 1С.