SSRS для финансового департамента: 30 отчётов вместо трёх утренних Excel-файлов

Финансовый директор клиента описал ситуацию коротко: «Каждое утро две девочки собирают данные из трёх систем в один Excel. Два часа. Каждый день». Три системы - это 1С:Бухгалтерия, отдельная база на SQL Server с управленческим учётом и выгрузки из банк-клиента в CSV. Итоговый файл - сводная таблица на несколько листов с формулами, которую потом рассылают по почте руководителям. Процесс работает уже лет пять, все к нему привыкли, и никто не думал его менять - пока одна из «девочек» не ушла в декрет, а вторая не попросила прибавку.

Вот тут и позвонили нам.

Что решили развернуть

SQL Server 2008 R2 у клиента уже стоял - на нём жила та самая база управленческого учёта. Лицензия Enterprise, Reporting Services установлен вместе с движком, но не настроен. Это типичная история: SSRS ставится по умолчанию вместе с сервером, но потом о нём никто не вспоминает.

Решение напрашивалось само: настроить SSRS, написать отчёты, настроить подписки - и утренний ручной ритуал просто исчезает. Report Manager встроен, агент подписок тоже - никаких дополнительных лицензий.

Единственная работа, которую нужно было сделать заранее - нормально связать три источника. Данные из 1С гнались в staging-таблицы на том же SQL Server через штатную выгрузку 1С (XML, раз в час). CSV из банк-клиента - через SSIS-пакет, который крутился по расписанию SQL Agent. Управленческая база была уже на SQL Server и никакого ETL не требовала.

Отчёты: что пришлось делать руками

Отчётов набралось тридцать с небольшим. Большинство - вариации на тему: ДДС за период, сравнение план-факт по статьям, остатки по счетам, дебиторка-кредиторка в разрезе контрагентов. Несколько штук - сложнее: кросс-табличные с параметрами по периоду и подразделению.

Писать отчёты в Report Builder - не самое увлекательное занятие, если честно. Инструмент сделан для пользователей, а не для разработчиков: много кликов, логика запросов спрятана в визарде, параметры настраиваются через диалоги. С другой стороны - это же и плюс: финансовый аналитик клиента, посмотрев на процесс, спросил «а я так смогу?» Смог. Сам написал три несложных отчёта без нашей помощи. Это важно: если отчётная система требует разработчика на каждый новый запрос, она не приживается.

Те отчёты, где нужна была хоть какая-то нетривиальная логика - писались напрямую в T-SQL и оборачивались в датасет. SSRS прекрасно живёт с хранимыми процедурами в качестве источника данных, что сильно упрощает отладку: запрос можно погонять в SSMS отдельно, убедиться, что данные правильные, и только потом делать из него отчёт.

Подписки и расписание

Это то, ради чего всё затевалось. В SSRS подписки делятся на стандартные и data-driven. Стандартная - рассылка конкретного отчёта конкретным адресатам по расписанию. Data-driven - когда список получателей и параметры берутся из базы.

Для большинства отчётов хватило стандартных подписок. Настройка простая: выбираешь отчёт, формат (Excel, PDF, что угодно), расписание, список email-адресов. Всё. SQL Server Agent подхватывает задачу и крутит её по расписанию.

Утреннюю сводку настроили так: в 7:30 агент генерирует сводный Excel-файл и рассылает его руководителям. Они открывают почту - файл уже там. Никаких ручных операций.

Формат Excel в SSRS работает нормально для большинства случаев, но с нюансами. Если в отчёте есть группировки и subtotal-строки - в Excel они разворачиваются не совсем так, как выглядят в Report Manager. Пришлось на нескольких отчётах переделать структуру: убрать интерактивные группировки, которые в браузере выглядят красиво, но в Excel превращаются в плоскую таблицу со сдвигом колонок. Компромисс простой - два варианта одного отчёта: один для просмотра в браузере с интерактивностью, второй «плоский» для выгрузки.

Что получилось

Две недели от первого разговора до момента, когда подписки заработали в боевом режиме. Большая часть времени ушла не на SSRS, а на разбор логики отчётов: что именно считается «дебиторкой» у этого клиента, как они разбивают статьи ДДС, какие периоды сравниваются. Это обычная история - формализация требований всегда занимает больше времени, чем техническая реализация.

Ручная сборка утреннего Excel исчезла. Две девочки, которые этим занимались, переключились на другую работу - анализ, а не механическую сборку данных.

Один отчёт из тридцати пришлось переписать дважды: финансовый директор посмотрел на первую версию и сказал, что «это не то, что он имел в виду». Оказалось, что план-факт у них считается нарастающим итогом с начала квартала, а не за отдельный месяц. Это нормально - такие вещи часто выясняются только когда человек видит реальные данные в реальном отчёте.

Что стоит учесть, если идёте тем же путём

Первое - Service Account для SSRS нужен отдельный. Не LocalSystem, не сетевая служба. Отдельный доменный аккаунт с минимальными правами: читать из нужных БД, слать почту через SMTP-релей. Потом, когда понадобится добавить источник данных на другом сервере, не придётся разбираться, почему SSRS не может до него дотянуться.

Второе - Report Manager живёт на IIS, и если IIS уже занят. У клиента на том же сервере стоял корпоративный сайт на IIS. Пришлось разносить на разные порты и настраивать URL Reservation вручную через Reporting Services Configuration Manager. Неочевидно с первого раза.

Третье - подписки крутятся через SQL Agent. Если SQL Agent остановлен или не работает - подписки не уйдут, и вы об этом не узнаете сразу. Мониторинг SQL Agent нужен в любом случае, но лучше убедиться в этом до того, как FinDir в понедельник утром не получит привычный файл.

Если смотрите в сторону BI и отчётности на базе SQL Server - SSRS в составе 2008 R2 закрывает большинство корпоративных сценариев без дополнительных лицензий. Главный вопрос не в инструменте, а в том, насколько хорошо формализованы требования к отчётам до начала работы.