Прилетело ко мне в разработку 1,5 десятка отчетов для ЗУП. Все - аналоги типовых отчетов по сотрудникам на дату, но только за период: инвалидность/награды/квалификация и т.п. В оригинальной постановке – «выводить в отчет всех сотрудников, которые хотя бы 1 день отработали в этом периоде». На этом (плюс приложенной форме) собственно, постановка и закончилась. (Почему даже самые сильные аналитики периодически грешат тем, что вместо снятия требований к отчету просто пересылают присланную пользователями форму напрямую разработчикам? Рефлекс срабатывает поделиться «?(р/г)адостью» с другими?)
Во все отчеты требовалось вывести информацию о должности, подразделении и виде занятости сотрудников. А для внутренних совместителей еще и вид занятости по основному месту работы. Вся эта информация – периодическая и, как следствие, трактовать, как учитывать изменение кадровых данных в отчете, можно по-разному. Можно, например, выводить всю кадровую историю по сотрудникам с разбивкой по периодам, а можно выводить данные последнего места работы. Можно учитывать изменение вида занятости и не учитывать изменение должности/подразделения, и наоборот. Вариаций множество. Пока аналитик согласует с пользователями требования пройдет минимум несколько дней, а разработчики простаивают. Причем еще и никакой гарантии, что с первой попытки будут сняты корректные требования.
Что будет, если передать эту пачку отчетов с неопределенными требованиями напрямую нескольким разработчикам, причем малознакомым с предметной областью? Каждый в меру своего понимания напишет свой расчет «всех сотрудников, которые хотя бы 1 день отработали в этом периоде». А потом еще и несколько раз будет переписывать свои отчеты. КПД будет близок к нулю, а трудозатраты запредельные.
Что делать в таком случае? Естественно, изолировать расчет сотрудников с их кадровыми данными, от всех отчетов и отдать всем разработчикам на вход один готовый набор. Создадим для этого один шаблонный отчет.
Почему именно отчет?
- Во-первых, потому что очень удобно тестировать и отлаживать. Все, что требуется для отображения информации – это накидать быстро настройку варианта. А дальше в пользовательском режиме можно менять группировки, отборы и состав выводимых полей (и проверять, естественно, как меняется исполняемый текст запроса в зависимости от настроек). Для отладки можно пользоваться внешним отчетом, чтобы не терять время на обновлениях. (Если что - в этом аргументе приводится ключевая причина, почему мы не будем размещать наш расчет где-либо еще, например, в общем модуле).
- Во-вторых, можно вместе с аналитиком проанализировать полученный результат на маленькой выборке. И убедится, что вы друг друга наконец-то правильно поняли. Просто дружно поглядев на данные на картинке, без лишних попыток на пальцах друг-другу что-то объяснить.
- В-третьих, потому что в конструкторе запроса в отчете есть закладка «Компоновка», которая позволяет без лишнего нажатия клавиш на клавиатуре указать в каком месте запроса должны подставиться условия по установленным пользователем отборам.
- Ну и в-четвертых, моя интуиция мне кричит, что если запросили 1,5 десятка отчетов с расчетом сотрудников за период, то и за самим расчетом рано или поздно тоже придут.
Пока аналитиком и пользователями дожимается вопрос, как должна выглядеть выборка сотрудников за период с их кадровыми данными, все остальные разработчики в своих отчетах описывают запрос-пустышку, со всеми необходимыми им полями (у всех набор полей разный) и с помощью конструктора собирают свои запросы.
Дальше однотипно во всех отчетах выполняется подмена запроса-пустышки на текст шаблонного запроса:
Почему мы делаем именно так, а не через передачу, например, подготовленной таблицы в менеджере временных таблиц в процессор компоновки?
Потому что в таком случае придется вручную параметризовать запрос, исходя из настроек, который сделал пользователь в рабочем отчете. А это нетривиальная, но крайне важная задача, которую потребуется решить. Так, например, помещать в менеджер ВТ кадровые данные за период по всем сотрудникам, если в отчете установлен по двум подразделениям будет абсолютно некорректно.
При такой реализации же мы получаем без каких-то дополнительных действий правильно параметризованный исполняемый запрос. Более того, все поля, которые не востребованы в рабочем отчете, будут автоматически из текста исполняемого запроса исключены. И добиваемся мы этого результата с минимумом программного кода (примерно 40 строчек кода, помимо самих запросов).
Естественно, при общении с пользователями выяснилось, что в половине отчетов логика «всех сотрудников, которые хотя бы 1 день отработали в этом периоде» одна, а в половине другая. В части отчетов нужно выводить информацию об изменениях должности и подразделения, а в остальных интересует только изменение вида занятости (по текущему и основному местам работы). С точки зрения изменений в шаблонном отчете меняется выборка данных в одном - двух запросах в пакете. Решается вопрос очень просто - параметризацией запроса, параметр будет определять вариант сбора данных. Данные, рассчитанные по разным правилам объединяются в одной выборке. Сделать мы так можем абсолютно спокойно, потому что запросы, у которых в условии будет «ГДЕ ЛОЖЬ», выполняться просто не будут.
Подобной параметризацией, кстати, удобно пользоваться собирая в одном отчете большое количество показателей и «отключая» для разных вариантов ненужные выборки. 3-5 подобных параметров вполне спокойно можно контролировать. Если же Вы переживаете, что пользователи самостоятельно не смогут настроить такой отчет – тогда возьмите и вообще закройте для этого отчета возможность изменения. Кто не знает, у формы отчета (БСП) есть две специальные настройки для таких случаев: РазрешеноВыбиратьИНастраиватьВариантыБезСохранения И РазрешеноИзменятьВарианты.
Весь расчет таким образом остается изолированным в одном отчете, разработчикам же конечных отчетов необходимо только указать значение параметра. Остальное для них остается без изменений.
О чем еще необходимо подумать перед сдачей отчетов? А о том, что, несмотря на то, что мы везде предусмотрели нежесткую параметризацию запроса по пользовательским отборам, наш запрос по-прежнему остается неоптимальным. Например, на несколько тысяч сотрудников, только сотня имеет данные об инвалидности. Если отчет формируется без отборов, а вывести нужно только сотрудников с инвалидностью, собирать кадровые данные по всем сотрудникам предприятия и помещать их во временные таблицы кажется не очень хорошим решением. В данном случае хочется выполнить жесткую параметризацию запроса на сбор кадровых данных теми сотрудниками, у которых есть записи об инвалидности. Непосредственно в данном случае можно сделать универсальную для всех отчетов параметризацию по физлицам, т.к. вся информация либо напрямую, либо опосредованно к ним привязана (через сотрудника).
Параметризовать, естественно, будем в шаблонном отчете на уровне первого запроса в пакете. Добавим параметр, недоступный пользователям, значение которого, по-умолчанию, установим в «Истина».
Дальше же при подготовке текста запроса либо прописываем вместо параметра условие отбора по физлицам, либо заменяем на «Истина». Решение об использовании принимается на уровне каждого отчета, в зависимости от рассчитываемой в нем информации.
Выигрыш в скорости такая параметризация может давать вполне существенный:
Теперь уже вполне красиво, но давайте еще одно маленькое улучшение внесем. На уровне первого запроса пакета в шаблонном отчете предусмотрена параметризация только по физлицу. Сделано это вполне осознанно, чтобы в одной выборке получить и данные по внутреннему совместительству и по основному месту работы (можно, конечно, запрос и по-другому переписать, но тогда данный пример привести не получится). А отчеты вполне вероятно будут формироваться с отбором по сотрудникам. Поскольку сотрудник однозначно определяет физлицо, хочется при установленном фильтре на сотрудников, применить и отбор по физлицу на уровне первого запроса:
Сделать это можно при компоновке результата, пробежавшись по отборам в настройках отчета, и при наличии отбора по сотруднику, принудительно добавить/переопределить в настройках отбор по физлицу. С 99% уверенностью можно сказать, что отбор по сотруднику будет в настройках отчета единичный и не будет входить в никакие группы отборов. Добавляя такую принудительную параметризацию можно получить отличный выигрыш в скорости. (А иногда подобную параметризацию не просто можно, но и обязательно нужно делать. Например, если принудительная параметризация позволит задействовать индекс, вместо полного сканирования таблицы.)
Таким образом, при установленном отборе по сотрудникам в первой временной таблице шаблонного отчета мы получаем только выборку по необходимым нам физлицам. Теперь совсем красиво.
Интуиция меня не подвела, и после того, как мы сдали наши отчеты, прилетел запрос на самостоятельный отчет с сотрудниками за период. И естественно, в него нужно кучку очень нужной информации дополнительно вывести. Здесь на выручку нам приходят необязательные соединения между таблицами.
Благодаря этому необязательному соединению между таблицами рабочие отчеты, которые ничего не знают про затребованные в шаблонном отчете дополнительные поля, и в которых они не нужны, при формировании не будут читать данные из лишних таблиц.
В качестве вывода:
- Вместо 1,5 десятка отчетов написано 1,5 десятка +1. Последний вполне информативен и впоследствии пригодился как самостоятельный (и запрос легко читаемый).
- Отчеты были запущены в разработку несмотря на то, что требования к отчетам аналитиками не были сняты. Разработчики не теряли время на выяснение с аналитиком, что в отчеты выводить. Минимизированы временные потери на переписывание запросов после очередной итерации уточнения требований с пользователями.
- Во всех отчетах исполняются вполне хорошие, параметризованные запросы. Из макета компоновки можно быстро получить для отладки текст исполняемого запроса.
- Минимум кода. Для реализации потребовалось всего четыре небольших метода, которые легко сопровождать. Вся вариативность заложена в самих запросах. Во всех запросах можно использовать конструктор.
- Скучная задача по разработке непонятно зачем и кому нужных отчетов превращена в достаточно увлекательный кейс с групповой разработкой. Я так точно удовольствие получила.
- Отчеты не получится использовать как внешние. Но так ни для кого, кроме одного конкретного клиента, они никакой ценности и не несут.
P.S. Посвящается всем, кто ничего не понял в статье Любите СКД так, как люблю ее я . За что я безумно люблю СКД , так это за возможность нежесткой параметризации запросов и необязательные соединения между таблицами. Это дает возможность «скармливать» компоновщику макета настройки (причем не заморачиваясь с их программным созданием – просто накидав нужный вариант отчета) и забирать автоматически сгенерированный хороший запрос (лапочка-компоновщик еще и все лишние поля из текста запроса сам уберет). Один раз написав хороший запрос, можно на его основе получать десятки других. Задумайтесь, какой потенциал!
Вступайте в нашу телеграмм-группу Инфостарт
