1. Комментарии и "разметка"
Начнем, естественно, с документации к отчетам. Куда же без нее? Недавно, мы с моей командой задались вопросом, а где должна размещаться документация к отчету, если мы хотим чтобы сторонний разработчик обязательно нашел и прочитал ее перед тем, как лезть своими "кривыми ручками" в наше относительно "совершенное детище"?
Будете ли Вы смотреть справку к отчету, комментарий к объекту метаданных, искать комментарии в модуле объекта/менеджера? Со 100% гарантией могу сказать, что нет! В чем можно быть уверенным наверняка - первое, что сделает любой разработчик 1С, получивший задачу на доработку любого отчета, - он откроет основную схему компоновки данных. Значит, наше "наследство для передачи потомкам" должно бросаться в глаза сразу после выполнения данного действия. И что тогда может быть лучше первой строчки запроса-источника?
Это решение позволяет спокойно редактировать запрос с помощью консоли запросов и не приводит к выборке лишних полей при формировании отчета - СКД об этом позаботится за нас.
Расширим немного функциональность данного приема. Как оставить необходимые комментарии по логике построения запроса в отчете? В модулях типовых конфигураций мы периодически находим описание пакетов в комментарии перед текстом запроса. Но комментарии в отчетах не дают использовать консоль запросов! Никаких гарантий, что их не затрут. Решим эту задачу так:
Особенно рекомендую этот прием, если у Вас есть стажеры, за которыми необходимо выполнять код-ревью, - сразу видно, осознает ли "юное дарование", что оно в запросе собирает, или стажер просто "методом тыка" пытается отчет сконструировать.
Хороший отчет должен быть емок и лаконичен. Он должен полностью помещаться на экран монитора и решать собой ровно ту задачу, которую он призван решать, а при печати вмещаться на один лист формата А4 и не содержать никаких лишних данных. Это - в идеале. Утопия. А вот убедить в этом пользователей - задача практически нереальная. Почему-то им в отчете нужна обязательно куча всевозможных показателей и аналитик, причем объяснить зачем - они толком не могут. Надо - и все, со времен динозавров так сложилось...
Иногда показателей и аналитик так много, что это начинает запутывать: какие данные уже выбраны в запросе, а какие нет? Что из выбранных полей - ресурсы, а что аналитические разрезы? Хочется в таком случае как-то структурировать текст запроса. Области, как в модулях, и комментарии в запросах-источниках недоступны. На помощь приходит, как ни странно, русский язык. Что мешает все ресурсы назвать по шаблону Ресурс%НаименованиеПоказателя%, а аналитики Аналитика%НаименованиеАналитики% (ну или как-то наподобии)? Очень выручает при настройке расчета итогов и при настройке структуры вариантов.
Дополнительно на помощь с ориентацией в тексте запроса приходит выбор параметров (или текстовых полей) для разметки текста запроса - выделяются цветом, не мешают использованию консоли и в исполняемом запросе не присутствуют.
2. Глобальный серверный модуль.
Всем известно из документации, что: "Выражение механизма компоновки данных может содержать вызовы функций глобальных общих модулей конфигурации и неглобальных общих модулей с установленным свойством Клиент (обычное приложение) (при использовании обычного приложения) или Сервер (при использовании управляемого приложения). Никакого дополнительного синтаксиса для вызова таких функций не требуется."
Однако на практике очень редко, кто этим функционалом пользуется. С неглобальными общими модулями периодически возникают какие-то проблемы. А вот методы глобальных серверных модулей работают стабильно и позволяют решить большую часть проблем со сложными настройками или установкой параметров отчета.
Не стесняйтесь - заведите себе глобальный серверный модуль чисто под использование в отчетах на СКД. Со мной, например, из проекта в проект кочует один метод, который решает примерно 80% проблем по настройке отчетов с "подвывертом":
3. Отчет как "генератор запросов/данных".
Это совет скорее для начинающих специалистов. Осознание, что далеко не всегда нужно дотошно во всем разбираться приходит с опытом (а точнее c дефицитом рабочего времени, который растет вместе с опытом). Желание разобраться, как устроена система, как организовано хранение данных, написать с нуля сбор данных - весьма благородно и полезно. Но жизнь вносит свои коррективы - чаще всего времени разбираться просто нет.
И тут на помощь приходит один простой факт - практически всё уже давно придумали за нас. И вся ключевая информация уже отражена в том или ином отчете. Очень часто вместо того, чтобы сидеть и разбираться, откуда и как собрать данные в запрос, достаточно заставить аналитика настроить максимально подходящий под требования по задаче отчет (или два-три отчета), забрать из макета компоновки исполняемый запрос (или забрать результат в виде дерева/таблицы) и надстроить на него сбор недостающих данных. Это вполне хорошее решение, которое подходит для реализации интеграционных задач, обработки имеющихся в системе данных (например, новый реквизит заполнить) и для создания новых отчетов.
Я, к примеру, постоянно им пользуюсь в задачах, связанных с зарплатно-кадровым функционалом, - зачем самостоятельно собирать в запросе список работающих сотрудников в тех или иных аналитических разрезах, если есть отчет по списочному составу, за корректность данных в котором несут ответственность разработчики типового решения и в котором есть практически вся необходимая информация?
К тому же вероятность, что отчет перестанет работать, куда ниже вероятности, что перестанет работать код, взятый из общих модулей или написанный самостоятельно. Все-таки отчеты - это ключевая функциональность, с которой постоянно работают пользователи. Если вдруг все настройки в отчетах слетят - крику будет!..
Да, возможно с развитием системы взятый из отчета запрос перестанет работать или на замену старому отчету придет новый. Но так ничто и не вечно. Да и подменить один пакет данных на другой не так уж и сложно.
4. Отчет как алгоритм - "черный ящик".
В чем огромное преимущество отчета на СКД по сравнению с алгоритмом, размещенным в общем модуле?
- Во-первых, в визуализации с возможностью гибкой пользовательской настройки. Тестирование запроса в общем модуле, Вы, например, целиком на аналитика или пользователей скинуть не сможете. Как минимум, потребуется аналитику сценарии тестирования расписать. А вот тестирование отчета - легко.
- Во-вторых, в возможности наложения "нежестких" условий с произвольными операциями сравнения. Сколько усилий уйдет на поддержку в запросе только для одного поля использования/неиспользования условий "=, <>, заполнено, не заполнено, содержит" и т.д.? В отчете же достаточно просто оставить указание компоновщику макета, в каком месте в текст запроса условие подставить.
- В-третьих, в автоматической оптимизации текста запроса под состав требуемых данных. СКД отлично справляется с исключением из запроса невостребованных полей/таблиц.
Эти преимущества приводят к идее - а почему бы не использовать отчеты, как основные "кирпичики" в построении нашей системы? Давайте напишем один хороший отчет с очень хорошим запросом (в котором предусмотрим и нежесткие условия, и необязательные соединения между таблицами), соберем в этот отчет всё, что только может понадобиться пользователю, исходя из предметной логики, и "закроем его на ключик" (т.е. не будем неподготовленные умы пускать его дорабатывать)? Все-таки учетная информация группируется на определенные логические блоки.
Я постоянно задумываюсь над вопросом, на самом ли деле нужна такая декомпозиция на мельчайшие "учетные единицы информации", как это реализовано в ЗУП 3.0, в котором сбор информации, относящийся к сбору информации о сотрудниках разнесен по множеству методов в общих модулях? Для примера, как часто нужны вам были стажи сотрудников в отрыве от списочного состава этих самых сотрудников? Или их паспортные данные? Насколько удобной оказалась такая декомпозиция с точки зрения сопровождения системы?
Я себе позволить такое большое количество взаимосвязей между компонентами не могу - просто не уследить. Куда проще иметь одну "закрытую" компоненту - отчет, и использовать ее для получения данных в нужных местах. Плюс еще раз повторюсь, отчеты - это алгоритмы с удобной графической визуализацией, которая позволяет очень легко протестировать изменения.
Использовать на практике такой отчет - "кирпичик" можно, например, для генерации временных таблиц.(Самое простое использование - забрать данные, как описано в пред. пункте, - уже не будем рассматривать). Причем можно управлять составом необходимых данных с помощью вариантов отчета (или программно собранных настроек). Например, можно результат формирования отчета забрать в менеджер временных таблиц.
Второй вариант использования - в отчетах, когда для построения одного отчета требуется вся информация, рассчитанная в другом. Берем и целиком подставляем текст запроса из одного макета в другой. Единственная сложность в применении - необходимо тщательно следить за наименованием выбираемых полей: общие поля для обоих отчетов должны иметь одинаковые наименования, а присущие только одному из отчетов - должны иметь уникальное наименование. Иначе некорректно будут работать отборы.
Из плюсов же - во-первых, мы не дублируем код, все изменения вносятся ровно в одном месте. Во-вторых, у нас на выходе оптимальный запрос - мы же в первом макете все инструкции для компоновщика оставили. В третьих - огромное преимущество при отладке. Сразу берем готовый запрос из макета компоновки для консоли запросов, и не нужно по кускам собирать.
Архитектура же решения на отчетах-алгоритмах может выглядеть примерно так:
5. "Отчет в отчете"
Сталкивались когда-нибудь с необходимостью собрать в одну форму большое количество различных показателей, на расчет каждого из которых нужен собственный отчет? И естественно в форме нужна возможность установки отборов и произвольной настройки.
Есть у нас одна такая сводная форма - называется "Диспетчерский доклад". В нее собраны показатели: выпуск, коэффициенты технической готовности, потери линейного времени и прочие показатели, соответствующие специфике учета транспортного предприятия. Чтобы рассчитать каждый из показателей, потребовался "десятиэтажный" запрос, под каждый был реализован свой очень хороший отчет с расшифровками и подробным объяснением того, как цифры были получены.
Все эти показатели для расчета использовали один регистр. Т.е. с точки зрения оптимальности запроса для нашего отчета требовалось заново собрать все эти показатели, с ревизией состава пакетов. Навскидку, количество пакетов в итоговом запросе приблизилось бы к 4-5 десяткам. Сопровождать такого "монстра" было бы нереально. Выносить алгоритмы в общие модули и переписывать десяток готовых отчетов тоже не хотелось. В итоге было принято решение пожертвовать "оптимальностью" в пользу "сопровождаемости" и сформировать имеющиеся отчеты многопоточно.
Архитектурно это выглядит так: в новом отчете в качестве источника данных выступает набор - объединение источников-объектов. Каждому источнику-объекту соответствует отдельный отчет. Наименования выбираемых полей жестко соответствуют наименованиям полей исходного отчета.
Каждый источник является описанием настроек для схемы компоновки данных оригинального отчета. Настройки структуры для отчета собираются программно - выбираем только те данные, которые необходимы для сводной формы (соответственно получаем сразу "хорошие" запросы, в которых отсутствует все ненужное). Для реализации достаточно на уровне набора-объединения указать, какие из полей являются аналитическими разрезами, присвоив им роль "измерение".
Далее осталось поддержать установку в отчетах пары отборов (поскольку форма сводная - параметров в ней совсем мало). И получить внешние наборы для сводной формы, сформировав отчеты многопоточно (у нас три потока) с выводом в коллекцию значений.
Не смотря на то, что сбор данных не оптимальный, скорость формирования такового отчета получилась вполне приемлемая - 5-6 секунд.
Решение оказалось очень удобным для сопровождения. Во-первых, все-таки какие-то неучтенные вводные для расчета показателей всплывали и правки локализовались в одном отчете. Во-вторых, в какой-то момент состав показателей в сводной форме был расширен. Для вывода данных в отчет понадобилось всего лишь описать доп. источник в основном макете сводной формы. В-третьих, этот инструмент получил дальнейшее развитие в виде красивого монитора для руководителей, в котором все те же показатели были отображены уже в виде диаграмм.
На выходе у пользователей:
- десяток хороших, подробных оперативных отчетов с расшифровкой до регистратора.
- сводная форма для руководства с хорошей скоростью формирования и с возможностью гибкой настройки, для реализации которой понадобилось описать буквально несколько методов.
- красивые картинки, для которых не пришлось реализовывать сбор данных.
А у нас пример - как реализовать практически на одних отчетах целый блок доработок.
Надеюсь, Вам было интересно, и что-то окажется полезным для использования.
