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