Абстрактно идея понятна. Но вот как же конкретно это должно выглядеть?
Посидев, подумав, изучив что есть на рынке в этом плане, пришло понимание того что эта тема еще далеко не избита и весьма актуальна. Поэтому хочу поделиться примером «конфигуратора отчетов», который получилось реализовать на базе системы «ERP-Платформа».
На мой взгляд он получился идеологически приближенным к идеальному, поэтому в начале статьи постараюсь рассказать концепцию того, каким должен быть конфигуратор отчетов «для людей».
Идеальный конфигуратор отчетов — сочетание простоты и функциональности. Например в 1С функциональный, но неискушенный в программировании 1С человек не сможет им пользоваться. Или в битриксе — простой, но не может делать необходимые вещи.
Идеальный конфигуратор отчетов будет понятен простому пользователю и при этом поддерживает создание отчетов любого уровня сложности.
Сформировались такие требования к конфигуратору отчетов:
1) Простота
Он для НЕпрограммистов. Простой менеджер, далекий от понимания SQL, сделает отчет по интересующим данным.
2) Универсальность
Отчеты можно формировать по всей системе, по любым пользовательским данным.
3) Автоматическое подключение нового
При изменении конфигурации системы, если добавляется новое поле в таблицу, или новая таблица, или устанавливается целый новый модуль, то все изменения автоматически должны быть доступны в конфигураторе.
4) Вложенность
Между таблицами есть связи. Например у задач есть свойства: тип, статус и т.д. Это храниться в специальных справочниках, в основной таблице только ссылки. Т.к. система для НЕпрограммистов, не будем грузить пользователей что такое left join. Пользователь выбрав в поле статус должен получить не число, а статус задачи «в работе» и т.п. Глубина погружения должна быть как минимум на один уровень в связанные таблицы.
5) Поддержка сложных структур
Бывает что отчет сложен, затрагивает много таблиц и даже нельзя обойтись SQL запросом, а нужна серьезная обработка PL/SQL. Для этого в конфигураторе отчетов предусмотрено указание процедуры, которую напишет программист на встроенном редакторе PL/SQL ERP-Платформы.
6) Планировщик и доставка отчета
Часто отчеты формируются на периодической основе. Например пользователь хочет утром увидеть в почте отчеты, ежедневные, еженедельные. ежемесячные и т.п. Нужен планировщик заданий, в котором отчет ставится к автоматическому формированию в заданный момент.
Помимо планировщика нужна система доставки отчета. Это не обязательно письмо. В зависимости от настроек пользователя может быть уведомление в интерфейсе, отправка в telegram, отправка по email и т.п. Доставка по всем каналах коммуникации с пользователем.
7) Диаграммы
Формирование диаграмм по данным отчета
8) Вывод результата
Выводить результат отчета в различных форматы, например Excel или PDF.
Что есть в мире
Начали с изучения того что в мире есть. Изучение показало что все печально. Сначала была 1С. Да, там все круто, можно сделать почти все что угодно, но где же тут п.1, «для простых людей»? Там черт ногу сломит пока разберется. У менеджера, который в первый раз в жизни это увидит, мозг просто расплавиться. В общем круто — но надо проще и интуитивней.
В популярных crm системах все печально. Толком ничего нет. Единственное что привлекло внимание, конфигуратор отчетов в Битриксе. В целом подходит под определение «для людей» и по началу даже понравился, но в качестве наглядного примера опишу несколько недостатков:
1) Узкость системы: отчеты привязаны только к определенным таблицам с главной функциональностью: «Задачи», «Товары»,«Сделки» и т.п. Всего 6 штук! А вот что делать если хочу проанализировать сколько % рабочего времени в графиках сотрудников занимают задачи такого-то типа, или хочу получить список клиентов у которых не заполнен email в контактах. Чтобы делать отчеты по данным из установленных приложений нет и речи.
2) Условия можно строить только на глубину до 4 вложенности. Неужели было сложно сделать неограниченное?
3) Сортировать можно только по одному из полей. А если надо отсортировать по типу задачи, а внутри типа по дате по убыванию?
4) Отчеты все списком в столбик по алфавиту. Делятся опять же по таблицам «Задачи», «Товары»,… 6 штук. А если мне нужна своя группа, или подгруппа отчетов. Как группировать отчеты по тематике?
5) Нет планировщика для запуска с периодичностью. (я по крайней мере не нашел). При этом в задачах он есть.
В общем система или универсальная но очень сложна, либо для людей — но слишком узка, либо вообще ничего нет.
Поэтому идем своим путем.
Дерево
Для начала решено было организовать построение отчетов в виде древовидной структуры.
Любой пользователь может создать свою ветку-узел (можно создавать вложенные ветки, тут нет ограничений), или добавлять свой отчет в другие доступные ему ветки. При наведении мышки на отчет всплывает описание отчета. Загромождать статью принтскринами из системы управления деревом не буду. Можно посмотреть здесь.
Во вторых нужны права доступа. Ведь не хорошо чтобы все видели всё. Есть общие отчеты, а есть те, которые могут видеть отдельные сотрудники или группы сотрудников, в том числе это могут быть целые ветви отчетов.
Тут благом оказалась штатная система прав доступа в ERP-Платформе. Она имеет структуризацию прав доступа вплоть до отдельных элементов страницы и в нее довольно просто получилось встроить систему отчетов. А после еще и прав доступа к процедурам для отчетов, но об этом ниже.
Настройка глобальной структуры
Далее надо выстроить структуру связей в системе. Система должна знать у каких полей есть зависимости с другими таблицами (пример задачи и ее статуса). Эта настройка выполняется один раз разработчиком конфигурации.
По сути необходимо воссоздать Foreign key (про контроль целостности тут не говорю, только связи). Структура ERP-Платформы позволила довольно легко это сделать. В штатный редактор таблиц добавлены необходимые поля:
В таблице ставится галочка, что она будет видна в конфигураторе отчетов. У каждого поля ставится галочка, будет ли оно видно конфигураторе, т.к. не все поля имеет смысл выводить в отчетах, а лишний мусор в списке не к чему.
Если поле является идентификатором из универсального справочника, то можно указать номер универсального справочника (о нем чуть далее). Выбрать поле другой таблицы, с которым связано это поле.
Подробным описанием этого редактора тоже не буду загромождать статью, почитать можно здесь.
Работу по настройке этих связей делает разработчик конфигурации. В конфигурации по умолчанию это уже сделано. При этом и любой пользователь с необходимыми правами доступа, может зайти в редактор таблиц и сделать необходимые манипуляции.
Если добавляется новое поле и оно будет нужно в отчетах, надо щелкнуть на галочку использования этого поля в отчетах.
Теперь конфигуратор отчетов будет знать связи и выводить при выборе поля пользователю картинку типа такой:
Тут мы подходим к п.3 наших требований. При установке в системе нового модуля, его данные и структура должны автоматически попасть в отчет.
Здесь от разработчика модуля требуется во время разработки расставить эти галочки. А система уже подхватит их при установке.
Для простых пользователей, будет выглядеть так, как все автоматически стало доступно после установки.
Универсальный справочник
Теперь сделаем необходимое отступление. Что такое «Универсальный справочник»? который я упоминал чуть выше, и которому выделен целый столбец при редактировании полей таблицы. Для краткости будем называть его УС.
В первую очередь УС — способ существенно снизить трудозатраты на разработку. Замечено, что большинство справочников состоят из 4 полей:
1) ID параметра
2) Название параметра
3) Числовое значение параметра
4) Текстовое значение параметра
Например. Справочник Валюта:
Или справочник Статус задачи:
И еще можно привести сотню примеров.
Они состоят из одинакового набора полей одного типа. Т.е. можно для всех таких справочников использовать один редактор, одну процедуру для запроса данных и т.д.
Не надо каждый раз, когда понадобился справочник, рисовать интерфейсы, делать ссылки, писать запросы и выполнять т.п. муторную работу.
В общем УС — мегаудобно.
Теперь вернемся назад с новым пониманием по УС и рассмотрим редактор полей в конфигураторе отчетов.
Он должен иметь такую функциональность:
1) Выбирать поля таблицы, их группировать и сортировать.
2) Составлять условия.
3) Предварительный просмотр результата.
В целом редактор получился такой
Поля (столбцы)
Сначала пользователь выбирает «Cправочник» — это таблица, за которой стоит функциональный модуль системы. Потом просто добавляет необходимые поля. Поля можно переименовывать, менять их порядок вывода. Все наглядно и интуитивно понятно.
Вторым полем идет Универсальный справочник. Если в системе с этим полем связан конкретный справочник, то пользователь может указать Н — название, 1 — первый параметр, 2 — второй параметр. И система при формировании отчета, например в поле Статус задачи, вместо цифры 92, покажет текст «В работе» если выбрано Н и т.д. Все очень просто.
Группировка
Так же просто делается группировка. Если нужно просуммировать значение какого-то поля, выбирается SUM в поле Агрегатные. При этом система на все остальные поля сама поставит group by при формировании запроса.
Естественно для разных типов данных в списке должны выводятся разные функции. Например в типе данных varchar нет смысла выводить SUM.
Чтобы все не разрасталось в ширь, пришлось ввести некие сокращения, например COU_D — это «количество уникальных элементов» (сокращение от sql-ного count distinct). Но наведя мышку на заголовок столбца всплывает легенда, какое значение что означает.
По остальным заголовкам столбцов есть аналогичная краткая информация по функционалу.
Сортировка
Сортировка полей тоже простая и универсальная. В столбце Сортировка выбирается «1» в поле по которому произойдет сортировка, если необходимо отсортировать по еще одному полю напротив него выбирается «2», если в обратном порядке «2 desc» и т.д. Все очень просто.
Большое преимущество данного подхода: всегда в доступности полный пул полей и мы можем указать сортировку хоть по всем полям включительно.
Условия
Все состоит и контейнеров с условиями. Контейнер — то что в скобках. Условие — операция сравнения А и Б (А>Б, А=Б, А<=Б...).
Например: (<условие 1> И <условие 2> И <условие 3>) — является контейнером И, соответственно условие (<условие 1> ИЛИ <условие 2> ИЛИ <условие 3>) является контейнером ИЛИ. И вот из такой конфигурации И/ИЛИ и условий внутри можно составлять сколь угодно сложные вереницы условий.
Например если необходимо выбрать данные отвечающие <условие 1> и одному из условий 2 или 3. То необходимо условия 2 и 3 объединить в конейтнер ИЛИ. (<условие 1> И (<условие 2> ИЛИ <условие 3>))
Здесь в контейнере И находятся <условие 1> и контейнер <ИЛИ>, а внутри контейнера ИЛИ условие 2 и условие 3. Например: ( (A>Б) И ( (A>C) ИЛИ (A=В) ) )
Для пользователя в интерфейсе это будет выглядеть так:
Но мало просто создать редактор расстановки условий. Условие может быть константой или переменной. Переменное условие определяется просто — оно не заполнено в конфигураторе. Если значение условия пусто — то надо спросить его у пользователя перед формированием отчета. Если пользователь ничего не введет — ставить null.
Чтобы поле ввода выглядело информативно нужно еще такое свойство как название. Название может совпадать с именем поля, а может и нет.
Например, если мы ввели константу в поле «Дата», но оставили пустым поле «Статус»
то система должна спросить «Статус» у пользователя перед формированием отчета.
В общем: значение есть — константа, пусто — спрашивать. Все тут тоже просто.
Опять же поле может быть связано с УС. В этом случае можно указать какое из полей УС выводить и как в примере выше, вместо числового поля «Статус» будет выведен красивый список выбора.
Необходимости как в Битриксе ограничивать 4-мя уровнями вложенности не было. Условия можно ветвить бесконечно.
Процедуры
Конфигуратор отчетов создан для НЕпрограммистов и знание SQL для составления отчета не обязательно. Но в случае сложного отчета, данные которого находятся во многих разных таблицах со сложными связями, программиста придется привлечь.
Такие вещи можно сделать написав процедуру в стандартном PL/SQL конфигураторе, входящем в базовую систему программирования ERP-Платформы, и указав данную процедуру в отчете. В процедуре можно сделать любую PL/SQL конфигурацию, т.е. фактически все что угодно.
В тему программирования конфигурации в ERP-Платформе углубляться не буду, т.к. эта тема выходит далеко за рамки данной статьи. Вкратце — состоит из 2 частей: программирование веб интерфейса и программирование базы данных, ну и соответственно связи между ними. В части программирования базы данных можно создавать таблицы, триггеры, процедуры любой сложности. В рамках конфигуратора отчетов нас здесь как раз интересует часть системы по созданию процедур. Там реализован полноценный PL/SQL (и даже несколько фишек которых нет нигде, например тип данных image, или операторы API в триггерах, позволяющие прямо по событию в БД передавать данные во внешние системы)
Но не все так просто. Программирование в системе доступно администраторам системы, или лицам, которым эти права дали администраторы.
Конфигуратор отчета доступен всем, и нельзя дать любому пользователю включить в отчет любую процедуру.
Поэтому доступ в отчетах к процедурам опять же пришлось интегрировать в штатную систему назначения прав в ERP-Платформе.
Для использования процедуры в отчетной системе, необходимо прописать права на нее, в Роли пользователя, создающего отчет.
После того как процедура стала доступна пользователю он её может указать в отчете. Добавлять поля можно из полей процедуры. Агрегатные функции и функции сортировки доступны.
А вот условия здесь — входные параметры процедуры. Они нужны все и порядок нельзя менять. Поэтому тут редактирование ограничено. Можно только задать константу. Но менять порядок, удалить, добавить новые — не получится.
Вот например процедура «ЗАЯВКА_Список», формирующая список заявок по условиям в интерфейсе списка заявок:
Если не заполнено ни одно из условий, т.е. все null процедура выдаст список заявок со статусом «поступила».
Если ее указать в отчете, и выбрать аналогичные поля, как в интерфейсе со списком заяовк
То мы получим аналогичный результат в отчете
Вот в догонку еще код этой процедуры в PL/SQL интерфейсе ERP-Платформы. Но это уже очень глубоко выходит за рамки данной статьи и не предназначено для простых пользователей. Тут просто в качестве примера, что такие вещи можно делать.
Вообще вся конфигурация ERP-Платформы написана на её же встроенном языке, соответственно все это доступно в конфигураторе отчетов, а так же сами пользователи могут что угодно редактировать и модернизировать.
Запуск по расписанию
Автоматическое получение периодических отчетов очень важная функция. На моей практике было создано очень много таких отчетов.
В ERP-Платформе есть штатный планировщик заданий, для запуска процедур по расписанию, программируемый в целом аналогично крону. В него получилось встроить и постановку запуска отчетов. Т.е. опять же заюзать штатную функцию системы и не писать новое. Но оказалось не все так просто.
С планировщиком самим по себе просто. Ставится отчет аналогично процедуре, только дергается другой скрипт, который дергает отчет и получает из него данные. Но в процессе работы пришло осознание того, что просто слать отчет в html встроенным в письмо совершенно не правильно и пришлось капнуть гораздо глубже.
Было решено не ограничивать пользователя в возможностях получения отчета. Помимо email, можно получить отчет в веб интерфейсе аккаунта в системе уведомлений, или на телефон в telegram. В общем заюзать для этого штатную систему уведомлений ERP-Платформы. Но встал вопрос — а как передать тело отчета, скажем в telegram например. Да, там можно слать форматированные сообщения, но отчеты бывают разные… это может быть еще та простыня. В веб интерфейсе проблема аналогичная. Можно конечно ввести blob поле к уведомлению, ибо мы не знаем размер отчета, но опять же это был бы костыль, который надо программировать индивидуально, а хотелось одним кодом убить всех зайцев. Сделать универсальную систему доставки отчета, чтобы работала одинаково во всех каналах доставки информации без доработок. Ибо вот появится новый канал и для него опять что-то надо будет писать индивидуально.
Решение было найдено следующее. Скрипт, который запускается по расписанию и получает данные отчета, делает pdf файл с отчетом и кладет его на диск в аккаунте клиента. Потом через штатную систему уведомлений производит рассылку со ссылкой на этот файл. Т.е. грубо говоря пришло уведомление, отчет такой-то, и ссылка. Пользователь кликает на ссылку и ему открывается файл.
Pdf формат универсальный, откроется везде и на телефоне и на компьютере.
Ок, средство доставки есть. Теперь надо сформировать адресатов.
Настройка получателей
Получателей может быть 3 вида:
1) Сотрудник (конкретное лицо)
2) Подразделение (отдел согласно штатному расписанию)
3) Группа (рабочие группы сотрудников)
Соответственно могут быть любые сочетания этих видов. Заполняется эта информация в конфигураторе отчетов в самом отчете.
Скрипт формирования отчета на основании этих данных вычислит набор уникальных получателей и проштампует им ссылки на отчет в штатную систему уведомлений.
Далее рассылка уже будет зависеть от индивидуальных настроек пользователей. Минимум — придет в веб интерфейс. Далее если стоит в контактах сотрудника email с типом «для уведомлений» — уйдет туда. Если у сотрудника подключен телеграм, то уйдет и туда.
Но опять же, не факт что отчет должны видеть все, а он лежит на диске. Тут проблема решается просто. Каждая папка на диске имеет систему ограничения прав доступа. Права к папке Отчеты по умолчанию урезаны совсем, даже не чтение. Т.е. ее содержимого никто не сможет посмотреть, но ссылки при этом будут открываться. Если кому-то вдруг понадобится просмотр содержимого этой папки, администратор должен Роли пользователя индивидуально прописать права на нее. Так что проблем с безопасностью тут нет. Работает принцип как в youtube «доступ по ссылке». В списке ничего не увидишь, но посмотреть видео можно зная ссылку.
Графическая часть
На самом деле диаграммы довольно редко востребованы. У меня на практике практически не встречалось требований рисовать диаграммы. Но такая возможность должна быть. В каких-то ситуациях это может быть большим плюсом.
В нашем конфигураторе на текущий момент предусмотрели 3 виде диаграмм:
1) Линейная
2) Столбчатая
3) Круговая
4)… и в будущем добавлять другие виды по мере фактической потребности.
И интерфейс к ним. Он получился очень простой
Принцип такой. Стоит хоть одна галочка — выводить диаграмму, везде пусто — не выводить. Соответственно если указано Х — то это будут названия делений по ости Х. В линейной и столбчатой просто галочками указываются по данным каких полей строить линии и столбцы. В круговой это можно делать только по одному из столбцов.
Тут в принципе все понятно и углубляться не будем. Подробнее можно посмотреть здесь.
Форматы вывода данных
Это тоже важный аспект. Как минимум пользователь должен иметь возможность распечатать отчет одним щелчком. Как максимум получить его в виде файла PDF или выгрузить в Excel для дальнейшей обработки. Все эти варианты конечно предусмотрены и тут в принципе тоже все понятно и ничего нового.
Послесловие
Хотелось бы подвести итоговую мысль под тем, каким должен быть идеальный конфигуратор отчетов.
1) Он не должен гемороить пользователей. Но простота и функциональность вещи противоречивые. У функциональной вещи сложнее эксплуатация. Может даже потребоваться специальное обучение.
Тут можно пойти путем матрешки. На верхнем слое сделать простой, дружелюбный интерфейс, закрывающий большой пул потребностей. При встрече сложной потребности, должна быть дверь во внутренние слои с функционалом, необходимым для её решения.
Так и строили. Внешне — простой интерфейс, но если встретилось сложное: вот редактор PL/SQL — делайте что угодно и подключайте это в виде готового блока в простой интерфейс отчета.
2) Конфигуратор отчетов не должен быть статичным, а расширяться автоматически вместе с расширением системы. Надо делать так, чтобы при расширении системы код самого конфигуратора отчетов не надо было преписывать, а он автоматически подхватывал все изменения.
В системах с возможностью конфигурирования пользователем, например в 1С или в ERP-Плаформе, такой подход является единственным выходм, т.к. какая конфигурация будет у пользователя заранее не известно, и за всеми не угонишься подгонять конфигуратор отчетов под каждую конфигурацию системы.
3) Конфигуратор отчетов должен хорошо выполнять задачу по составлению отчетов, а не заниматься смежными вещами.
Тут концепция аналогична принципу маленьких «острых» утилит в unix подобных системах. Утилита должна уметь блестяще справляться со своей задачей, а не уметь все по чуть чуть. Смежные задачи передавать утилитам блестяще их выполняющим и просто получать от них результат.
Это правило относится полностью к системе. Например, правами доступа к отчетам должен заниматься штатный модуль прав доступа, и все что касается прав доступа — он умеет делать хорошо, и не важно где в системе.
Не зачем в отчетах строить свою систему прав доступа — это костыль, который никогда не будет таким хорошим как модуль, под это заточенный.
Аналогично с планировщиком. Не зачем строить в конфигураторе отчетов запуск заданий по расписанию, лучше поручить это системе, которая умеет это делать хорошо.
Незачем реализовывать редактор для сложных запросов в конфигуаторе отчетов. Это переусложнит интерфейс и отпугнет простых пользователей. Лучше для этих задач заюзать стандартный редактор процедур, который хорошо умеет конфигурировать сложные запросы.
Не нужно конфигуратору отчетов делать индивидуальную систему рассылки, когда можно заюзать штатную и при появлении нового канала доставки не заботится о нем. Пусть каналами доставки оперирует модуль для этого предназначенный.
Аналогичные требования и к конфигуратору — он должен максимально хорошо справляться со своими прямыми задачами и уметь дружить с остальными модулями системы.
Такой подход в системе позволяет хорошо отладить эти узконаправленные функции в модулях, а так же не тратить лишнее время разработчиков на реализацию частично дублированных функций в различных частях системы.
Комментарии (27)
vova1900
13.07.2017 10:18Здравствуйте!
А в 1С Вы смотрели «Систему компоновки данных»?mail-online
13.07.2017 10:29Здравствуйте!
Да, конечно. Я про 1С не могу ничего плохого сказать. У них хорошая система отчетов. Но для неподготовленного пользователя она сложна. У них нет различия, простой отчет или сложный, в любом случае пользователю придется иметь дело с конструктором запросов.
Смысл как раз в том, чтобы конструирования запросов избежать в простых случаях. А в сложных, простой пользователь все равно не сделает и придется программиста привлекать.vova1900
14.07.2017 17:04Да, Вы правы, в сложных случаях без программиста все равно не обойтись.
Мне кажется это хорошая практика, изучать опыт других систем.
В 1С ERP (Это типовая конфигурация 1С, не бухгалтерия), в отчетах можно выделить 3 уровня:
Уровень разработчика это чистая система компоновки данных (СКД) где пользователю ничего не понятно.
На этом уровне задаются:
- Таблицы и связи этих таблиц между собой
- Поля, которые пользователь сможет использовать в отчетах
- Способы агрегации данных
- Дефолтные настройки и их варианты
- и много чего еще
Это рамки, которые задаются разработчиком отчета и за которые пользователь не сможет выйти при использовании отчета.
Уровень неопытного пользователя (простой режим)
На этом уровне пользователь может управлять только самым простым набором настроек, которые предусмотрел разработчик в одном из дефолтных вариантов. Как правило, это фильтры и сортировка, возможно еще включение выключение колонок отчета или простая настройка диаграммы
- Уровень опытного пользователя (расширенный режим)
В этом режиме пользователю доступны все возможности настроек СКД, но при этом в рамках тех таблиц и их связей, которые заданы на уровне разработчика.
Пользователь может произвольно переключаться между уровнями опытного и неопытного пользователя. Конечно неопытный пользователь в "расширенном режиме" может испортить себе отчет, но это легко исправляется наличием дефолтных настроек, к которым можно откатиться.
Я так понимаю, Ваш подход близок к 1С-ному?
Забавно, что Вы тоже к такому пришли.mail-online
17.07.2017 14:52Наверное да. Видимо схожие технические задачи находят схожие и технические решения. У них наверное тоже когда-то вставала такая проблема.
Только скорее у нас есть п.1 и п.2 из Вашего списка. Или простой редактор, или PL\SQL конфигуратор.
Увидел недавно, что в 1С есть «виртуальные таблицы» состоящие из нескольких реальных. Очень хорошая идея, которая решит некоторые проблемы. Думаю тоже такое сделаем.
Вообще у них все немного концептологически по другому устроено. Насколько я понимаю они в БД хранят только данные, а вся обработка данных выполняется в самой программе.
У нас несколько по другому. В базе хранятся не только данные, но и задается обработка этих данных, путем написания процедур и триггеров на PL\SQL. Благодаря такому решению, мы можем обрабатывать массивы информации на уровне БД, а не на уровне ПО. И думаю у нас благодаря этому проще получился сам компилятор. По сути, нам надо провести преобразование конфигурации пользователя в последовательность SQL команд. У них же (есть у меня подозрение) что переводится в сишные команды, а потом компилируется. Но я не знаю на самом деле как у них, это мои догадки. Может у них просто свой интерпретатор, который исполняет команды их внутреннего языка, но мне кажется это неэффективно будет с точки зрения быстродействия.
Есть у нас кое что и на уровне ПО конечно, например постройка интерфейса, проверка прав доступа и т.п. Но далеко не все.
Видимо поэтому им проще разработать сложный конфигуратор отчетов. А нам проще встроить в конфигуратор отчетов PL\SQL редактор и сразу же предоставить механизмы уровня разработчкика.
Вообще если есть здесь специалисты такого уровня по 1С, было бы интересно узнать как в 1С устроен язык программирования на машинном уровне. Это свой интерпритатор, или конфигурация во что-то компилируется.
irbis_al
13.07.2017 10:32+1Вот я не знаю, работа вроде проведена большая… но исключительно по-моему мнению
ошиблись вектором.
Постоянно бродит по ИТ сообществу «призрак конструктора отчёта для неИТшника».
-А может не будем давать возможность водителю делать автомобиль, пусть просто рулит.
-Или пилоту конструировать самолёт.(Помимо знаний аэродинамики и механики, много ещё чего надо)
Так же как и нам… индексы план разбора… оптимизация sql.
Закончится тем, что Вы будите постоянно усложнять Ваш конструктор отчётов… увеличивая сложность вхождения в него.
Запаритесь консультировать «криворуких менеджеров».Сетуя на то, что быстрее сами бы сделали)
Потом добавите в свой конструктор sql(Ибо иначе не справится со всеми требованиями)… И будет это уже Ваш внутренний инструмент.
Тем более, что в каждой отрасти так или иначе существует отчётное насыщение.Вы просто будите подключать по требованию нужный отчёт из вашего отчётного репозитория кода.mail-online
13.07.2017 10:39Потом добавите в свой конструктор sql(Ибо иначе не справится со всеми требованиями)… И будет это уже Ваш внутренний инструмент.
В этом нет необходимости, у нас в отчеты можно встраивать процедуры, а для процедур уже есть редактор PL\SQL. Интерфейс отчетов сам по себе остается простым.irbis_al
13.07.2017 12:55+1Я читал статью и помню про встраивание pl/sql, просто как только это произошло Ваш конструктор потерял формат «генератор отчётов для неИТшника».
Ну и вдогонку… не знаю какие у Вас отчёты просили менеджеры -аналитики… У меня… и со знаниеми sql просто «вынос мозга»… это и lag,lead это rollup,cube order dense rank… И конечно же «поворот» pivot(Причём надо ещё решить pivot делать на уровне СУБД(в частности oracle) позволяет или в генераторе отчётов… а ещё (есть поддержка js) сделать его интерактивным… по нажатию… что там раскрывалось…
К чему это всё я… просто отчёты, а особенно аналитические должны делать специально обученные люди.А «генератор отчётов для неИТшника»… это просто маркетинговый концепт.
x-sive
13.07.2017 10:43Возможно не по теме, но у себя в конторе мы внедрили Jasper Reports
У коммерсантов радость полные штаны =)
guai
13.07.2017 10:47Я б такую задачу попробовал решать не на аддитвном, а на субтрактивном принципе.
Есть куча типовых отчетов. Большинством из них народ пользуется как есть. Но из больших, разлапистых отчетов есть возможность выкинуть лишнее. Это всегда проще: посмотрел, что есть, понял, что из этого тебе не надо, нашел, выкинул, а не запариваешься над каждым добавлением условия, группировки и тп.
Ну и правильно написали выше, такие задачи, мол, сделайте нам универсально, мы потом сами налабаем — они от непонимания бизнес-процессов, очень редко когда такое реально нужно. Типовые задачи покрываются типовыми отчетами. Вы чувакам лучше сделаете, если допинаете их разобраться в своих бизнес-процессах, чем если выкатите универсальную делалку отчетов.
zorggroz
13.07.2017 13:58В 1С есть «Универсальный отчет», конечно там не все можно сделать, но в целом если человек с ним не смог разобраться, то ему уже ничего не поможет.
evilgeek
13.07.2017 14:18+1В итоге у вас получился довольно громоздкий и не особо прозрачный уникальный генератор отчетов.
С заметным порогом вхождения. Но почти вся реальная гибкость — в возможности привязать plsql процедуру.
При это есть куча неочевидных кнопок, какие то странные аббревиатуры (COU_D), слова на басурманском (2 desc).
И все равно программизм прорывается (Параметр №2 Varchar_250).
Как писали выше, есть вполне удачные стандартные средства (Jasper Reports, например). Продуманные, испытанные временем, с документацией, по котором есть чего погуглить.mail-online
13.07.2017 14:39При это есть куча неочевидных кнопок, какие то странные аббревиатуры (COU_D), слова на басурманском (2 desc).
Согласен, это не совсем ясно, но к сожалению ширина экрана ограничена, хочется чтобы все влазило.
«COU» — сокращение от count. Вместо этого можно написать «количество элементов». Вместо «COU_D» можно написать «Количество уникальных элементов». Но вместо 5 букв будет 30 букв. Не удобно. Расползется все в ширь.
Для пояснения есть приписки, если навести мышку на заголовок столбца, то выскакивает пояснение.
Аналогично с сортировкой. Можно написать «Поле 2 сортировка обратная», а можно кратко «2 desc» и соотвественно пояснение что есть что.
В общем из-за экономии ширины экрана пришлось сделать так.
Посмотрим. Если будет прямо массовое непонимание — переименуем в длинное но более читаемое, это не проблема, 5 секунд.
И все равно программизм прорывается (Параметр №2 Varchar_250).
Да, вы правы тут. Давно очень делалось, когда конфигураторами отчетов еще и не пахло. Переименовал в более человеческое.
Как писали выше, есть вполне удачные стандартные средства (Jasper Reports, например).
Не подойдет. Мы не можем пускать абы кого из интернета к исходникам наших баз. Плюс вы заставите писать пользователей SQL запросы в оригинальную базу, которой они не знают. Jasper Reports — хорошо для индивидуальной разработки в локальной сети.
kostus1974
13.07.2017 14:21а вы слышали вообще про Qlik, про Tableau? да хотя бы про DreamReport?
это разве не то? оно всё как раз для этого.
(я изумился вашему обращению к 1С в первую очередь — оно-то здесь каким вообще боком? какие там отчёты? там они ровно так же, как и в delphi и в прочих RAD)mail-online
13.07.2017 17:47Не то.
Можно без проблем выгружать данные в Excel или в упомянутый Вами Tableau и анализировать как угодно. Надо только сначала эти данные получить. Вот получить можно при помощи конфигуратора отчетов и довольно удобным образом. Щелкнули «Ecxel» и пожалуйста, или откроете в экселе, или сохранить как csv и дальше этот же файл можно в Tableau загрузить.
Никто повторить функциональность Tableau не будет в здравом уме (если конечно нет цели войти именно в этот бизнес).
Далее вы не осознаете технических реалий конфигурируемых систем, тем более облачных.
Напрямую дать доступ к базе пользователя из BI системы просто бессмысленно. В конфигурируемых системах база данных не как обычно, а имена таблиц и полей состоят из номеров. Пользователь просто не поймет что есть что, конфигурация системы знает что Задачи это таблица 49, а номер задачи поле в этой таблице с именем 568 и т.п. В общем не вариант. Вы видели когда-нибудь БД 1С?
В ERP-Платформе сырая база еще сложнее, т.к. там помимо хранения данных еще и обработка эти данных, автоматически созданные конфигурацией процедуры, триггеры, системы записи логов и передачи данных и т.п. Это будет как на ассемблере пытаться что-то анализировать… Пользователь общается со всем этим удобным образом через конфигурацию которая знает что есть что на машинном уровне. Пользователю выдает красивые названия и красивый интерфейс. Какие за этим стоят машинные телодвижения — пользователю фиолетово.
Попробуйте в Tableau подключить демо БД от 1С например?
Да и с точки зрения безопасности в облаке никто пускать к себе кого угодно напрямую не будет. В локальной версии еще можно, если это крупная компания и жесткие договорные рамки, но в облачной это просто небезопасно. Работать и выгружать-загружать данные можно только через интерфейс.
Tableau — для тех кто в рамках своей компании занимается разработкой своего продукта, есть своя БД и можно сделать аккаунт на Tableau и анализировать данные из своей БД.
В облачных версиях и в конфигурируемых пользователем системах такое не подходит.kostus1974
14.07.2017 12:14Далее вы не осознаете
дальше всё бессмысленно.irbis_al
14.07.2017 12:58Ну я например и вправду не осознавал, что всё так наворочено(и был ли смысл идти по пути одинэф… хотя это уже оффтоп)… и тогда и вправду Вы не имеете общего репозитория отчётов… или же их переброска затруднительна… тогда и вправду отпадают отчёты с поворотами, rollup и т.д… Тогда и вправду надо получить просто «сырые» данные и их уже загружать в другой отчётный инструментарий(Вот сомнительно для громкого имени ERP… такой «костылёчек»..)…
mail-online
14.07.2017 15:15На самом деле путем 1С никто не шел. Я например базу 1С увидел постфактум и осознал что на самом деле схожие технические задачи просто находят схожие решения. Хотя системы по структуре на самом деле очень сильно отличаются. Чисто визуально базы схожи.
Я не очень люблю на эту тему дискутировать, пробовал уже, но сколько людей — столько и мнений и далеко не все с моим мнением согласны. Но тут как говорится жизнь покажет кто прав а кто нет. Надо просто молча работать над совершенствованием перспективных технологий, пока другие занимаются красивостью виджетов. А далее клиенты уже будут голосовать предпочтением.
У существующих облачных crm на мой взгляд есть очень существенный недостаток. Они не имеют гибкости. Бизнес-процессы они всегда специфичны и глупо всех подгонять под один интерфейс.
Так в целом у всех. Битрикс и КлиентскаяБаза попробовали сделать некую гибкость, предоставив возможность добавлять новые поля, но этого крайне мало. Нужно полностью иметь возможность менять любые элементы интерфейса, создавать любые таблицы, делать любые обработки данных. Причем индивидуально в каждом аккаунте, а не для всех. Только тогда crm система сможет удовлетворить компанию.
Но гибкая система это сложный путь. Надо сначала ее структурировать до мельчайших элементов. Сделать для нее внутренний язык программрования, на котором можно из этих элементов собрать конфигурацию. Обязательное условие, что вся конфигурация системы полность должна быть написана на этом внутреннем языке. Только тогда crm система сможет дать пользователю менять любой из кирпичиков из которых она состоит, или создавать новые конструкции из кирпичиков. Т.е. дать возможность менять интерфейсы, создавать новые структуры хранения данных, новые логики обработки данных.
В ERP-Платформе это в свое время было сделано, и не из соображений что вот есть гибкая 1С и мы тоже так хотим, а именно из соображений описанных выше. На 1С никто даже не смотрел, а смотрели на конкурентов и пытались сделать лучше их.
Сейчас в итоге во первых система может подстраиваться под любого пользователя, во вторых разработка нового идет намного быстрей ибо вместо php можно просто в конструкторе составлять систему.
Благодаря структуризации появился вот тот же конфигуратор отчетов. В обычной статичной crm такого просто не сделают, или сделают опять же статичный, и его надо будет допиливать при каждом изменении системы. А у нас система может меняться, при этом тот же конфигуратор отчетов менять не надо, он все поддерживает.
То же относится и к остальным модулям. На статичной системе где-то изменение сделал, во всех модулях системы это надо менять. У нас же можно сосредоточится на разработке отдельного модуля без заморочек на остальное, оно автоматически все изменения подхватит.
В общем сделать сложно, но в итоге вы увеличите скорость разработки, качество своих сервисов и если клиент попросит что-то подрегулировать под него, вы можете сказать: "Да, мы это можем. Без проблем!".
Да и концепция подтверждена смой жизнью. Как бы кто 1С не любил, но они непоколебимый мастадонт не просто так. По факту ими все пользуются. Каждая компания которую я знаю пользуется 1С. Их не любят из-за фактически монопольного положения, но при этом все равно пользуются и тратят на них деньги. Это потому что у них есть технология, которая позволяет делать индивидуальную подгонку под каждую компанию. Это решающий фактор.
Оглянитесь вокруг, такова жизнь. Кто владеет технологией легкой индивидуальной доработки — тот в будущем будет на коне.
Но это мое мнение. Я не претендую на то что я единственный тут вижу истину, может это не так. Но я думаю жизнь дальнейшая покажет, что выберут клиенты. Пока вот жизнь показывает что выбирают 1С.
Мы кстати с 1С не пытаемся конкурировать, они ушли очень далеко и это непоколебимая скала. Бухгалтерией нет планов заниматься. Но цель вписаться в нишу облачных crm — вполне посильная задача.
тогда и вправду отпадают отчёты с поворотами, rollup и т.д
Я не думаю что простым менеджерам нужны отчеты с поворотами ) это скорее для продвинутых аналитиков надо. Но если прямо вот понадобится и будет востребовано — реализуем. Может быть сами реализуем, а может придумаем способ оптимальной передачи данных в систему которая это умеет. Но пока это не повестка дня.
SergeyUstinov
14.07.2017 14:53«В конфигурируемых системах база данных не как обычно, а имена таблиц и полей состоят из номеров.»
Вот прям таки во всех без исключения? :)))
А статья хорошая — сразу понятен уровень «ERP-Платформы».mail-online
14.07.2017 15:25Знаете, технологии обязывают.
Если в качестве уникальных идентификаторов вместо чисел будете использовать читаемые наименования — флаг вам в руки )
Поделитесь примером где это не так. Интересно.SergeyUstinov
16.07.2017 00:30Ну вот пример из навика:
CREATE TABLE [dbo].[Item Ledger Entry]( -----название таблицы осмысленное [timestamp] [timestamp] NOT NULL, [Entry No_] [int] NOT NULL, ----названия полей тоже понятные [Item No_] [nvarchar](20) NOT NULL, [Posting Date] [datetime] NOT NULL, [Entry Type] [int] NOT NULL, [Source No_] [nvarchar](20) NOT NULL, [Document No_] [nvarchar](20) NOT NULL, [Description] [nvarchar](50) NOT NULL, [Location Code] [nvarchar](10) NOT NULL, [Quantity] [decimal](38, 20) NOT NULL, [Remaining Quantity] [decimal](38, 20) NOT NULL, [Invoiced Quantity] [decimal](38, 20) NOT NULL, [Applies-to Entry] [int] NOT NULL, [Open] [tinyint] NOT NULL, [Global Dimension 1 Code] [nvarchar](20) NOT NULL, [Global Dimension 2 Code] [nvarchar](20) NOT NULL, [Positive] [tinyint] NOT NULL, [Source Type] [int] NOT NULL, [Drop Shipment] [tinyint] NOT NULL, [Transaction Type] [nvarchar](10) NOT NULL, [Transport Method] [nvarchar](10) NOT NULL, [Country_Region Code] [nvarchar](10) NOT NULL, [Entry_Exit Point] [nvarchar](10) NOT NULL, [Document Date] [datetime] NOT NULL, [External Document No_] [nvarchar](35) NOT NULL, [Area] [nvarchar](10) NOT NULL, [Transaction Specification] [nvarchar](10) NOT NULL, [No_ Series] [nvarchar](10) NOT NULL, [Document Type] [int] NOT NULL, [Document Line No_] [int] NOT NULL, [Order Type] [int] NOT NULL, [Order No_] [nvarchar](20) NOT NULL, [Order Line No_] [int] NOT NULL, [Dimension Set ID] [int] NOT NULL, [Assemble to Order] [tinyint] NOT NULL, [Job No_] [nvarchar](20) NOT NULL, [Job Task No_] [nvarchar](20) NOT NULL, -----пропущено много других полей CONSTRAINT [Item Ledger Entry$0] PRIMARY KEY CLUSTERED ( [Entry No_] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY]
Уровень конфигурируемости не скажу что высокий, но много простых задач можно сделать на уровне настроек.mail-online
17.07.2017 11:35Что такое «навик»? Не знаю такого.
Судя по тому что я вижу, это система с заложенной конфигурацией, а не произвольной. Т.е. можно менять только в рамках настроек существующих полей. Или вы можете добавить в интерфейсе какое либо поле [Transaction Type] и оно появится в этой таблице, или в другой если в другой добавите? А если на русском напишите? А как триггер будите компоновать на машинном уровне? Например надо пользователю сделать действие какое-то в другой таблице при апдейте этого поля. «Навик» такое может?
Для системы Вы этим усложните цепочку действий, ей вместо того чтобы подставить ID надо будет по этому ID вычислить наименование поля и подставить его. Вы усложните кучу операций, кучу переборов. Вы столкнетесь с проблемой уникальных наименований, и еще с неизвестно с чем. Наверняка возникнет море дополнительных сложностей.
И кстати каждая дополнительная операция — потеря быстродействия системы, что тоже очень важно.
Осмысленные наименования на машинном уровне — это зло. Это нужно только людям. Я проходил через решения всех этих проблем. Даже без этого было море проблем о которых и предположить изначально было нельзя. Например 2 первые версии внутреннего языка были забракованы и выкинуты на помойку, потому что в какой-то момент приходило осознание что данный путь в никуда и надо были изначально строить все архитектурно по другому. Только с 3 версии получилась боевая программа, которая позволила все сделать.
dukeexil
14.07.2017 15:34Добрый день! Статья интересная, но не продукт. У меня вопрос — Чем вы будете лучше чем Excel? Если вы пытаетесь сделать продукт для менеджеров, то типовых отчетов вполне хватит, если для аналитиков, то ваш продукт будет бесполезен. В любой сфере есть своя специфика, которую не всегда можно типовой функционал подтянуть, Excel дает возможность использовать предустановленое кол-во функций различного рода + написать свою на VBA, сделать анализ, подтянуть данные почти из любого источника (включая API на wsdl) и делай с ними все что угодно… Не понимаю почему многие постоянно пытаются заново велосипед изобретать. Я без критики, вы проделываете несомненно огромную работу, но вопрос — вы построили конкретный портрет своего клиента, и нужен ли этому клиенту конструктор?
mail-online
14.07.2017 15:44Добрый день!
1) Конструктор отчетов должен удовлетворять потребности руководителей малого-среднего звена, по получению интересующих управленческих данных на основе данных системы. Нельзя быть во всех областях специалистом и всего предусмотреть в типовых отчетах.
2) Конструктор отчетов должен удовлетворять потребности простого персонала, путем получения каких-то простых данных, которые не могут дать типовые отчеты или интерфейс системы. В том числе и путем модифицирования типовых отчетов.
3) Для аналитиков — возможность легкого получения набора данных из системы для загрузки в специализированные программы и последующего анализа там.
4) Собственно сама возможность для разработчиков быстрым и удобным образом составлять типовые отчеты и выполнять запросы клиентов.
irbis_al
14.07.2017 16:02В принципе, Вы удовлетворили моё техническое любопытство. :-)
Раз у Вас есть востребованность на практике… наверное оно и вправду надо.
Наверное мы находимся в разных измерениях в автоматизации учёта.(которые не пересекаются)
У меня(http://cis-pos.com/) фирмы мелкий и средний бизнес,- автоматизирую «хорька» HoReCa(Hotel Restoran,Cafe,Shop).
У меня тоже конструктор-компоновщик.(но база данных хардкодная
Типа у всех есть documenttitles и documentscontents,firms и т.д… отраслевой атрибутикой отличаются)… а вот логика представления CRUID это легко конфигурируемое.(Но порог вхождения выше)(Ну и свой генератор отчётов естественно, но для специалиста)
И вот востребованность конструктора отчёта в моей сфере попадает в формат
для:
«Благородного Атоса, это слишком много, а для графа ДеЛяФер слишком мало»…
Т.е простые отчёты покрываются существующим репозиторием отчётов… а сложные «вынос мозга»(у меня есть все те перечисленные случаи и плюс интерактивность)… надо делать специалисту.
Vjatcheslav3345
Почему нельзя было обойтись настроенными представлениями (views) в базах данных, вместо файлов?.