Дано: есть большое количество отчётов, построенных на разных технологиях, этакий «зоопарк» — это и отчёты Crystal, и отчёты, загружаемые с помощью VBA кода в Excel, и RGW, и Access и т.д. и т.п. Важна не конкретная технология, а именно разнородность.
Как всё это упорядочить? Ну, вы же понимаете, что я буду говорить про SSRS, так как именно эта технология позволяет хранить всё на сервере, а не в локальных папках, и так как это на настоящий момент лучшая простая массовая технология в области отчётности.
Начнём с того, что больше 80% отчётов являются табличными, т.е. такими, где количество и структура столбцов заранее определены, а количество строк переменно.
Оставшиеся (менее 20%) отчётов — это либо матричные отчёты (с переменным количеством и строк, и столбцов), либо (чаще всего) отчёты фиксированной формы, классический пример — это российский баланс, где фиксированным являются не только столбцы, но и строки. Другим, чуть менее классическим примером, являются документы, например, счет-фактура или накладная, или УПД. Они, конечно, тоже имеют переменное количество строк, но я решил отделить их от обычных табличных отчётов из-за трудоёмкости «рисования» формы самого отчёта:
Здесь я буду вести речь про табличные отчёты. Возьмём, например, вот такой:
Или вот такой:
Если рассматривать вопрос трудоёмкости создания подобного рода (табличных) отчётов, то самое сложное при их создании — получить правильный запрос к базе данных. А если запрос к базе данных уже есть, создать отчёт MS SQL Server Reporting Services дело нескольких минут или десятков минут (зависит от количества параметров, необходимости слегка «подкирпичить» запрос для совместимости с типами переменных, иногда нужно задать имя выводимого поля, вот, например, на картинке выше можно заметить такой фрагмент «isnull(GL53002,’’)» — в RGW это будет работать, а для SSRS желательно в явном виде указать имя поля в возвращаемом наборе данных, например, вот так: «isnull(GL53002,’’) as AccountName» и т.п.). Иногда на всё это, включая первичное тестирование, может уйти полчаса, иногда 2 часа, но, как правило, не больше 4-х.
Именно поэтому любые разговоры относительно того, что невозможно переделать 100 существующих отчётов я всегда воспринимаю скептически, как говорится: «Дорогу осилит идущий». Ну, предположим, что в среднем, на каждый отчёт требуется 2 часа. Умножим на 100 отчётов. 200 часов. Ну, да, это месяц работы. Но далеко не в каждой компании имеется 100 отчётов, в одной 10, в другой 25, редко где 50. Зато вы получите возможности, которых раньше не было. Не поленитесь и прочтите всё-таки статью «Что Вы сможете выжать из Вашей Скалы с помощью новых технологий?» или «Почему мы выбрали в качестве инструмента построения системы корпоративной отчетности MS SQL Server Reporting Services?»
Разумеется, иногда приходится полностью переписывать запрос, так, например, я встречал аксессовские отчёты, построенные не на исходных таблицах, а на представлениях (views), когда в одном представлении идёт обращение к другому, а из него, в свою очередь, к третьему и так до 10 вложений. Смотрится это ужасно, абсолютно непрозрачно и непонятно, а выполняется мучительно долго. Поэтому перед человеком, переносящим такого рода старый отчёт на новую платформу, встаёт вопрос: «оставить всё как есть, или всё переделать?». Но это уже другая история 🙂
