К нам поступил запрос от клиента: «хотим конфигуратор отчетов».
Чтобы обычные сотрудники, далекие от SQL, могли создавать всевозможные нужные им отчеты на основе любых данных в системе.
Абстрактно идея ясна.
Но как именно это должно выглядеть? Посидев, подумав и изучив, что есть на рынке по этому поводу, я пришел к пониманию, что эта тема далеко не избитая и очень актуальна.
Поэтому хотелось бы поделиться примером «конфигуратора отчетов», реализованного на базе системы ERP-Платформа.
На мой взгляд, идеологически он получился близким к идеалу, поэтому в начале статьи я попытаюсь рассказать концепцию того, каким должен быть конфигуратор отчетов «для людей».
Идеальный конфигуратор отчетов — это сочетание простоты и функциональности.
Например, в 1С не сможет пользоваться функциональный человек, не имеющий опыта программирования 1С.
Или в Битриксе — простой, но не умеет делать нужные вещи.
Идеальный конфигуратор отчетов будет понятен обычному пользователю и в то же время поддерживает создание отчетов любого уровня сложности.
Такой требования в конфигуратор отчетов:
1) Простота
Это для непрограммистов.
Простой менеджер, далекий от понимания SQL, сделает отчет по интересующим данным.
2) Универсальность Отчеты могут формироваться по всей системе на основе любых пользовательских данных.
3) Автоматически подключать новые При изменении конфигурации системы, если в таблицу добавляется новое поле, или новая таблица, или устанавливается целый новый модуль, то все изменения должны автоматически быть доступны в конфигураторе.
4) Вложение Между таблицами существуют связи.
Например, задачи имеют свойства: тип, статус и т. д. Они хранятся в специальных каталогах; в основной таблице только ссылки.
Поскольку система для НЕпрограммистов, мы не будем обременять пользователей тем, что такое левое соединение.
Пользователь, выбрав статус в поле, должен получить не число, а статус задачи «в работе» и т. д. Глубина погружения должна быть не менее одного уровня в связанные таблицы.
5) Поддержка сложных структур Бывает, что отчет сложный, затрагивает много таблиц и даже SQL-запрос использовать нельзя, но требуется серьезная обработка PL/SQL. Для этого в конфигураторе отчетов предусмотрено указание процедуры, которую напишет программист с помощью встроенного PL/SQL-редактора ERP-платформы.
6) Планировщик и доставка отчетов Часто отчеты создаются на периодической основе.
Например, пользователь хочет видеть отчеты на почте утром, ежедневно, еженедельно.
ежемесячно и т. д. Нужен планировщик задач, в котором настроено автоматическое формирование отчета в определенный момент. Помимо планировщика вам понадобится система доставки отчетов.
Это не обязательно должно быть письмо.
В зависимости от настроек пользователя может быть уведомление в интерфейсе, отправка в телеграм, отправка на почту и т.д. Доставка по всем каналам связи с пользователем.
7) Диаграммы Создание диаграмм на основе данных отчета 8) Вывод результата Вывод результатов отчета в различных форматах, таких как Excel или PDF. Что есть в мире Мы начали с изучения того, что есть в мире.
Исследование показало, что все печально.
Сначала была 1С.
Да, там все круто, можно практически все, но где пункт 1, «для простых людей»? Там черт ногу сломает, пока не разберется.
У менеджера, который увидит такое впервые в жизни, просто расплавится мозг.
В целом круто — но надо быть проще и интуитивно понятнее.
В популярных CRM-системах все печально.
На самом деле ничего нет. Единственное, что привлекло мое внимание, это конфигуратор отчетов в Битриксе.
В целом он подходит под определение «для людей» и поначалу мне даже понравился, но в качестве наглядного примера опишу несколько недостатков: 1) Узкость системы: отчеты привязаны только к определенным таблицам с основным функционалом: «Задачи», «Продукты», «Транзакции» и т.д. Всего 6 штук! Но что мне делать, если я хочу проанализировать, какой процент рабочего времени в графиках сотрудников занимают задачи данного типа, или я хочу получить список клиентов, у которых не заполнена электронная почта в контактах.
О составлении отчетов по данным установленных приложений не может быть и речи.
2) Условия можно строить только на глубину 4 вложенности.
Неужели сложно было сделать безлимит? 3) Сортировать можно только по одному из полей.
Что делать, если вам нужно отсортировать задачи по типу, а внутри типа по дате в порядке убывания? 4) Все отчеты перечислены в столбце в алфавитном порядке.
Они снова разделены по таблицам «Задачи», «Продукты»,… 6 штук.
Что делать, если мне нужна собственная группа или подгруппа отчетов.
Как группировать отчеты по темам? 5) Нет планировщика, который нужно запускать периодически.
(по крайней мере я не нашел).
В то же время оно есть в задачах.
В общем, система либо универсальная, но очень сложная, либо для людей – но слишком узкая, либо ее вообще нет. Поэтому мы идем своим путем.
Дерево Для начала было решено организовать построение отчетов в виде древовидной структуры.
Любой пользователь может создать свою ветку узла (можно создавать вложенные ветки, ограничений нет), либо добавить свой отчет в другие доступные ему ветки.
При наведении курсора мыши на отчет появляется его описание.
Не буду загромождать статью принтскринами из системы управления деревом.
Ты можешь видеть Здесь .
Во-вторых, вам нужны права доступа.
Нехорошо, чтобы все видели все.
Есть общие отчеты, а есть те, которые могут видеть отдельные сотрудники или группы сотрудников, включая целые ветки отчетов.
Стандартная система прав доступа в ERP-платформе оказалась здесь благом.
В нем есть структурирование прав доступа вплоть до отдельных элементов страницы, и в него достаточно легко интегрировать систему отчетности.
А потом еще и права доступа к процедурам для отчетов, но об этом ниже.
Настройка глобальной структуры Далее необходимо построить структуру связей в системе.
Система должна знать, какие поля имеют зависимости с другими таблицами (пример задачи и ее статус).
Данная настройка выполняется один раз разработчиком конфигурации.
По сути, необходимо воссоздать Foreign key (я не говорю здесь о контроле целостности, только о соединениях).
Структура ERP-платформы позволила сделать это довольно легко.
В стандартный редактор таблиц добавлены необходимые поля:
В таблице ставится флажок, чтобы он был виден в конфигураторе отчетов.
У каждого поля есть галочка, чтобы определить, будет ли оно видно в конфигураторе, потому что.
Не все поля имеет смысл отображать в отчетах, и лишний мусор в списке не нужен.
Если поле является идентификатором универсального каталога, то можно указать номер универсального каталога (подробнее об этом позже).
Выберите поле из другой таблицы, с которой связано это поле.
Я также не буду загромождать статью подробным описанием этого редактора, вы можете прочитать Здесь .
Работу по настройке этих подключений выполняет разработчик конфигурации.
Это уже сделано в конфигурации по умолчанию.
При этом любой пользователь с необходимыми правами доступа может войти в редактор таблиц и произвести необходимые манипуляции.
Если добавлено новое поле и оно будет необходимо в отчетах, необходимо поставить галочку для использования этого поля в отчетах.
Теперь конфигуратор отчетов будет знать подключения и отображать такое изображение, когда пользователь выбирает поле:
Вот мы и подошли к пункту 3 наших требований.
При установке нового модуля в систему его данные и структура должны автоматически появиться в отчете.
Здесь разработчик модуля обязан установить эти флажки во время разработки.
И система их уже подхватит при установке.
Для обычных пользователей это будет выглядеть так, будто все автоматически стало доступно после установки.
Универсальный справочник Теперь сделаем необходимое отступление.Теперь вернемся с новым пониманием системы управления и посмотрим на редактор полей в конфигураторе отчетов.Что такое «Универсальный каталог»? о котором я упоминал чуть выше, и которому при редактировании полей таблицы выделяется целый столбец.
Для краткости мы будем называть его США.
Прежде всего, CS — это способ существенно снизить трудозатраты на разработку.
Замечено, что большинство каталогов состоят из 4 полей: 1) Идентификатор параметра 2) Имя параметра 3) Числовое значение параметра 4) Текстовое значение параметра Например.
Валюта каталога:
Или каталог состояния задачи:
И можно привести еще сотню примеров.Они состоят из одного и того же набора полей одного типа.
Те.
вы можете использовать один редактор для всех таких каталогов, одну процедуру запроса данных и т. д. Каждый раз, когда вам понадобится справочник, вам не придется рисовать интерфейсы, делать ссылки, писать запросы и т. д. муторную работу.
В общем, США мегаудобны.
Он должен иметь следующую функциональность: 1) Выделите поля таблицы, сгруппируйте и отсортируйте их.
2) Составить условия.
3) Предварительный просмотр результата.
В целом редактор получился вот такой
Поля (столбцы)
Сначала пользователь выбирает «Справочник» — это таблица, за которой находится функциональный модуль системы.
Затем просто добавляет необходимые поля.
Вы можете переименовывать поля и менять порядок их отображения.
Все четко и интуитивно понятно.
Второе поле — универсальный каталог.
Если с этим полем в системе связан конкретный каталог, то пользователь может указать N – имя, 1 – первый параметр, 2 – второй параметр.
А при формировании отчета, например, в поле Статус задачи вместо числа 92 система покажет текст «В работе», если выбрано N и т. д. Все очень просто.
Группировка Группировать так же просто.
Если вам нужно суммировать значения поля, выберите СУММА в поле «Агрегировать».
В этом случае система сама будет группировать все остальные поля при формировании запроса.
Естественно, для разных типов данных в списке должны отображаться разные функции.
Например, для типа данных varchar нет смысла печатать SUM. Чтобы вещи не становились слишком большими, нам пришлось ввести некоторые сокращения, например COU_D — это «количество уникальных элементов» (сокращение от sql count Different).
Но когда вы наводите указатель мыши на заголовок столбца, появляется легенда, сообщающая вам, какое значение это означает. 
Остальные заголовки столбцов содержат аналогичную краткую информацию по функционалу.
Сортировка Сортировка полей также проста и универсальна.
В графе «Сортировка» выберите «1» в поле, по которому будет происходить сортировка; если вам нужна сортировка по другому полю, выберите напротив него «2»; если в обратном порядке, то «2 desc» и т. д. Все очень просто.
Большим преимуществом этого подхода является то, что всегда доступен полный пул полей, и мы можем указать сортировку по всем полям включительно.
Условия Все состоит из контейнеров с условиями.
Контейнер — это то, что указано в скобках.
Условие — это операция сравнения между A и B (A> B, A=B, A<=B.).
Например: ( И И ) — является контейнером И, соответственно, условие ( ИЛИ ИЛИ ) является контейнером ИЛИ.
И из такой конфигурации И/ИЛИ и условий внутри вы можете создавать сколь угодно сложные строки условий.
Например, если вам нужно выбрать данные, соответствующие и одно из условий 2 или 3. Затем необходимо объединить условия 2 и 3 в контейнер ИЛИ.
( И ( ИЛИ ))
Здесь в контейнере AND находятся и контейнер, а внутри контейнера ИЛИ есть условие 2 и условие 3. Например: ( (А> В) И ( (A> C) ИЛИ (A=B) ) )
Для пользователя в интерфейсе это будет выглядеть так:
Но недостаточно просто создать редактор условий.
Условие может быть константой или переменной.
Условие переменной определяется просто – в конфигураторе оно не заполняется.
Если значение условия пустое, то перед формированием отчета необходимо запросить его у пользователя.
Если пользователь ничего не вводит, введите null. Чтобы поле ввода выглядело информативным, вам также понадобится такое свойство, как имя.
Имя может совпадать или не совпадать с именем поля.
Например, если мы ввели константу в поле «Дата», но оставили поле «Статус» пустым.
тогда система должна запросить у пользователя «Статус» перед созданием отчета.
В общем: есть значение - константа, пусто - спрашивайте.
Здесь тоже все просто.
Опять же, поле может быть связано с DC. В этом случае вы можете указать, какое из полей CS отображать и, как в примере выше, вместо числового поля «Статус» будет отображаться красивый список выбора.
Не было необходимости ограничивать его четырьмя уровнями вложенности, как в Битриксе.
Условия можно разветвлять бесконечно.
Процедуры Конфигуратор отчетов предназначен для НЕпрограммистов и для создания отчета не требуется знание SQL. Но в случае сложного отчета, данные которого расположены во множестве различных таблиц со сложными связями, придется привлечь программиста.
Такие вещи можно сделать, написав процедуру в стандартном PL/SQL-конфигураторе, который входит в базовую систему программирования ERP-платформы, и указав эту процедуру в отчете.
В процедуре можно сделать любую PL/SQL-конфигурацию, т.е.
по сути что угодно.
Я не буду углубляться в тему конфигурационного программирования в ERP-платформе, потому что… эта тема выходит далеко за рамки данной статьи.
Если коротко, то он состоит из 2-х частей: программирование веб-интерфейса и программирование баз данных и, соответственно, связей между ними.
С точки зрения программирования баз данных вы можете создавать таблицы, триггеры и процедуры любой сложности.
В рамках конфигуратора отчетов нас интересует как раз часть системы создания процедур.
Он реализует полноценный PL/SQL (и даже несколько функций, которых нигде нет, например тип данных изображения или операторы API в триггерах, которые позволяют напрямую передавать данные во внешние системы на основе события в базе данных) Но это не так просто.
Программирование в системе доступно системным администраторам или лицам, которым администраторы предоставили эти права.
Конфигуратор отчетов доступен всем, и вы не можете разрешить любому пользователю включать в отчет какую-либо процедуру.
Поэтому доступ к процедурам в отчетах снова пришлось интегрировать в стандартную систему распределения прав в ERP-платформе.
Для использования процедуры в системе отчетов необходимо прописать права на нее в Роли пользователя, создающего отчет. После того как процедура стала доступна пользователю, он может указать ее в отчете.
Вы можете добавлять поля из полей процедуры.
Доступны функции агрегирования и сортировки.
Но условия здесь являются входными параметрами процедуры.
Они все необходимы, и порядок изменить нельзя.
Поэтому редактирование здесь ограничено.
Вы можете указать только константу.
Но изменить порядок, удалить, добавить новые не получится.
Пример использования процедуры в отчете в ERP-платформе Под спойлером приведу пример, если кому интересно, как выглядит использование процедур в отчете в нашем редакторе.
Например, вот процедура «APPLICATION_List», которая формирует список приложений согласно условиям в интерфейсе списка приложений: 
Если ни одно из условий не заполнено, т.е.
все пустые, процедура выдаст список заявок со статусом «получено».
Если указать это в отчете и выбрать аналогичные поля, что и в интерфейсе со списком приложений 
Тогда мы получим аналогичный результат в отчете 
Вот еще код этой процедуры в интерфейсе PL/SQL платформы ERP. Но это выходит далеко за рамки данной статьи и не предназначено для обычных пользователей.
Это всего лишь пример того, что такие вещи можно сделать.
В целом вся конфигурация ERP-платформы написана на собственном встроенном языке; соответственно, все это доступно в конфигураторе отчетов, и пользователи сами могут редактировать и модернизировать что угодно.
Процедура APPLICATION_List
Запланированный запуск
Автоматическое получение периодических отчетов – очень важная функция.
В моей практике таких отчетов было создано немало.
Платформа ERP имеет стандартный планировщик задач для запуска запланированных процедур, который обычно программируется так же, как cron. В него удалось интегрировать запуск отчетов.
Те.
повторюсь, используйте стандартную функцию системы и не пишите новую.
Но оказалось, что не все так просто.
Сам планировщик простой.
Отчет ставится так же, как и процедура, только запускается другой скрипт, который тянет отчет и получает из него данные.
Но в процессе работы я понял, что просто отправлять отчет в html, встроенном в письмо, совершенно неправильно и пришлось копать гораздо глубже.
Было решено не ограничивать возможность пользователя получать отчет. Помимо электронной почты, вы можете получить отчет в веб-интерфейсе своего аккаунта в системе уведомлений, либо на телефон в Telegram. В общем, используйте для этого стандартную систему уведомлений ERP-платформы.
Но возник вопрос - как передать тело отчета, скажем в телеграм например.
Да, туда можно отправлять форматированные сообщения, но отчеты разные.
это может быть и тот лист. Аналогичная проблема и в веб-интерфейсе.
Можно, конечно, ввести blob-поле для уведомления, потому что размер отчета мы не знаем, но опять же это будет костыль, который нужно программировать индивидуально, а хотелось убить всех зайцев одним камень.
Создать универсальную систему доставки отчетов, чтобы она работала одинаково во всех каналах доставки информации без доработок.
Потому что появится новый канал и для него опять нужно будет что-то индивидуально писать.
Было найдено следующее решение.
Скрипт, который запускается по расписанию и получает данные отчета, создает pdf-файл с отчетом и размещает его на диске в аккаунте клиента.
Затем через стандартную систему уведомлений рассылает рассылку со ссылкой на этот файл.
Те.
Грубо говоря, я получил уведомление, такой-то отчет и ссылку.
Пользователь нажимает на ссылку и файл ему открывается.
Формат PDF универсален, он откроется везде, как на телефоне, так и на компьютере.
Хорошо, есть средства доставки.
Теперь нам нужно создать получателей.
Настройка получателей Получателей может быть 3: 1) Работник (конкретное лицо) 2) Отдел (отдел согласно штатному расписанию) 3) Групповые (рабочие группы сотрудников) Соответственно, может быть любая комбинация этих типов.
Эта информация заполняется в конфигураторе отчетов в самом отчете.
На основе этих данных скрипт формирования отчета рассчитает набор уникальных получателей и отметит их ссылками на отчет в стандартной системе уведомлений.
Далее рассылка будет зависеть от индивидуальных настроек пользователей.
Минимум - зайдет в веб-интерфейс.
Далее, если в контактах сотрудника есть письмо с типом «для уведомлений», оно попадет туда.
Если у сотрудника подключен Telegram, он тоже зайдет туда.
Но опять же не факт, что отчет должен увидеть каждый, но он есть на диске.
Здесь проблема решается просто.
Каждая папка на диске имеет систему ограничения прав доступа.
Разрешения к папке «Отчеты» по умолчанию полностью ограничены, даже не на чтение.
Те.
Никто не сможет просмотреть его содержимое, но ссылки откроются.
Если кому-то вдруг понадобится просмотреть содержимое этой папки, администратор должен индивидуально назначить права на нее ролям пользователей.
Так что проблем с безопасностью здесь нет. Принцип работает как в YouTube «доступ по ссылке».
В списке вы ничего не увидите, но можете посмотреть видео, если знаете ссылку.
Графическая часть На самом деле диаграммы нужны довольно редко.
На практике я практически никогда не сталкивался с требованиями рисовать диаграммы.
Но такая возможность должна быть.
В некоторых ситуациях это может быть большим плюсом.
На данный момент наш конфигуратор предоставляет 3 типа диаграмм: 1) Линейный 2) Столбчатый 3) Круглый 4)… и в будущем добавлять другие типы по мере возникновения реальной необходимости.
И интерфейс к ним.
Это оказалось очень просто
Принцип таков.
Если есть хотя бы одна галочка — отображать диаграмму, все пусто — не отображать.
Соответственно, если указано Х, то это будут названия отделов по Х-позвоночнику.
В линейном и столбчатом режиме просто установите флажки, указывающие, из каких полей строить строки и столбцы.
В круговом это можно сделать только для одной из колонн.
Здесь в принципе все понятно и углубляться не будем.
Вы можете увидеть более подробную информацию Здесь .
Форматы вывода данных Это также важный аспект. Как минимум, пользователь должен иметь возможность распечатать отчет одним щелчком мыши.
Максимум, получить его в виде PDF-файла или загрузить в Excel для дальнейшей обработки.
Все эти опции, конечно же, предусмотрены и здесь в принципе все понятно и ничего нового.
Послесловие Хотелось бы подвести итог, каким должен быть идеальный конфигуратор отчетов.
1) Это не должно вызывать проблем у пользователей.
Но простота и функциональность — вещи противоречивые.
Функциональный элемент сложнее в эксплуатации.
Возможно, это даже потребует специальной подготовки.
Здесь вы можете пойти по пути матрешки.
На верхнем уровне создайте простой и удобный интерфейс, охватывающий широкий круг потребностей.
Когда сталкиваешься со сложной потребностью, должна быть дверь во внутренние слои с функциональностью, необходимой для ее решения.
Вот как они его построили.
Внешне простой интерфейс, но если вы столкнулись с чем-то сложным: вот редактор PL/SQL — делайте что угодно и подключайте его как готовый блок к простому интерфейсу отчета.
2) Конфигуратор отчетов не должен быть статичным, а автоматически расширяться вместе с расширением системы.
Необходимо сделать так, чтобы при расширении системы код самого конфигуратора отчетов не нужно было переписывать, а он автоматически подхватывал все изменения.
В системах с возможностью настройки пользователем, например в 1С или в ERP-Плаформе, такой подход является единственным выходом, поскольку какая конфигурация будет у пользователя, заранее неизвестно, и за ним не уследишь.
со всеми, настроив конфигуратор отчетов для каждой конфигурации системы.
3) Конфигуратор отчетов должен хорошо выполнять задачу формирования отчетов, а не делать сопутствующие вещи.
Здесь концепция аналогична принципу небольшие «острые» утилиты в unix-подобных системах.
Утилита должна уметь блестяще справляться со своей задачей, а не уметь все по чуть-чуть.
Передавайте сопутствующие задачи утилитам, которые их блестяще выполняют, и просто получайте от них результат. Это правило полностью применимо к системе.
Например, стандартный модуль прав доступа должен заниматься правами доступа к отчетам, и всем, что связано с правами доступа - он может делать это хорошо, причем неважно, где в системе.
Нет необходимости выстраивать свою систему прав доступа в отчетах — это костыль, который никогда не будет так хорош, как разработанный под него модуль.
То же самое и с планировщиком.
Нет смысла запускать запланированные задачи в конфигураторе отчетов; лучше доверить это системе, которая сможет сделать это хорошо.
Нет необходимости реализовывать редактор сложных запросов в конфигураторе отчетов.
Это слишком усложнит интерфейс и отпугнет обычных пользователей.
Для этих задач лучше использовать стандартный редактор процедур, который хорошо умеет настраивать сложные запросы.
Конфигуратору отчетов нет необходимости создавать индивидуальную систему дистрибуции, когда можно использовать стандартную, а при появлении нового канала доставки об этом можно не беспокоиться.
Пусть каналами доставки управляет специально предназначенный для этого модуль.
Аналогичные требования предъявляются и к конфигуратору – он должен максимально хорошо справляться со своими прямыми задачами и уметь взаимодействовать с другими модулями системы.
Такой подход в системе позволяет хорошо отлаживать эти узконаправленные функции в модулях, а также не тратить лишнее время разработчика на реализацию частично дублированных функций в разных частях системы.
Теги: #Конфигуратор отчетов #ERP-системы #Программное обеспечение для службы поддержки #CRM-системы #Управление проектами
-
Заработок В Интернете: Путь Гуру К Успеху
19 Oct, 24 -
Картинки Появились В Openssh
19 Oct, 24 -
Ddos - Мысли Вслух...
19 Oct, 24 -
Что Бы Ты Сделал, Если...?
19 Oct, 24
