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