#работа/дэшборды #1с

Требования к дашбордам

Дашборд по сотрудникам / отделам

Задача, которую выполняет дашборд: дашборд должен отображать количество задач по каждому показателю в разрезе любой структурной единицы.

Требования к дашборду

1. Отображение количества задач по фин. службе / департаменту / управлению / отделу / сотруднику.
   • Реализация : (Front-end) Отображение два фильтра (зависимые фильтры ) :
     1. Уровень структурной единиц (по фин. службе / департаменту / управлению / отделу / сотруднику)
     2. Название структурной единицы
   • Вопросы : Логика присвоения задач к высшим структурным единицам.
     1. Если задача присвоена сотруднику, то она тогда и только тогда присвоена всем вышестоящим подразделениям?
     2. Ничейная задача в каком-то проекте не присвоена никакой структурной единице?

Этот фильтр должен давать возможность подтянуть базу сотрудников и структуру компании с возможностью выбора структурной единицы. То есть фильтр представляет собой выпадающий список.

2. Разбиение задач должно идти по следующим показателям:

• суммарное количество задач (всего задач);

• количество задач в работе (в работе);

• количество выполненных задач (завершены);

• количество просроченных задач (просрочены);

• количество задач на согласовании у постановщика (на согласовании);

• количество задач не в работе (не начаты).

• В скобках отображены условные обозначения для дашборда. Пояснение: задача может обладать одновременно несколькими статусами, например, она может быть в работе и просрочена или завершена и просрочена, поэтому количество задач всего = количество задач в работе + количество завершенных задач + количество не начатых задач + количество задач на согласовании + количество задач не начатых.

  • Комментарий :

    • a) Статусов может быть всего 2:
      1. Общий статус (7 состояний):

         - STATE_NEW = 1;
         - STATE_PENDING = 2;
         - STATE_IN_PROGRESS = 3;
         - STATE_SUPPOSEDLY_COMPLETED = 4;
         - STATE_COMPLETED = 5;
         - STATE_DEFERRED = 6;
         - STATE_DECLINED = 7;

      2. Статус просрочки (вычисляется в зависимости от заданной даты и установленного дедлайна)
    • b) Общее кол-во задач, получается, просто все задачи назначенные (суммировать ничего не нужно)

  • Вопросы : Нужно ли хранить историю изменения дедлайнов? Может возникнуть следующая ситуация. Мы хотим узнать состояние задачи за неделю (в определенный день). На момент окончания этой недели задача была просрочена, но на следующий день - ей передвинули дедлайн, и она стала не просроченной. Если мы не будем хранить историю дедлайнов, а только послденнее состояние. То мы так и не узнаем, что задача когда либо была просрочена, ведь по последним данным, она была закрыта до делайна.

  • Релизация : Хранить историю изменения статуса (и возможно дедлайна)

• Как посчитать количество задач по каждому показателю?

  • Реализация: Описано выше

  • Количество задач (всего) – суммируется количество задач, назначенных на определенного ответственного (суммирование идет по полю задачи ID).

  • Количество задач в работе – задачи, обладающие системным статусом “Выполняется” на конец выбранного временного интервала (то есть нажата кнопка “Начать выполнение” и не нажата кнопка “Завершить”).

  • Количество завершенных задач – закрытые задачи к концу временного интервала, обладающие системным статусом “Завершена” (нажата кнопка “Завершить”, причем эта задача принята постановщиком, если результат должен быть согласован или задача завершается без согласования результата).

  • Количество просроченных задач – задачи, в статусе “Просрочена” (это системный статус, но другой!). У таких задач текущее время > времени, указанном в поле задачи “Крайний срок”. Не нажата кнопка “Начать выполнение” или кнопка “Завершить” до наступления крайнего срока.

    • Комментарий: Разве не только те, которые завершены? Просроченные задачи в работе тоже бывают.

  • Количество задач на согласовании – задачи с системным статусом “Ждет контроля”, то есть ответственный нажал кнопку “Завершить”, но в задаче включена опция согласования с результата с постановщиком и постановщик не принял задачу (то есть она завершена ответственным, но не постановщиком).

    • Вопрос: Считаются ли еще не принятые задачи на согласовании просроченными?

  • Количество не начатых задач – все остальные задачи с системным статусом “Ждет выполнения” (может быть системный статус “Отложена”), то есть не нажата кнопка “Начать выполнение”.

3. Выбор временного интервала отображения:
   • Комментарий: Некорректно описаны метрики с интервалами. То, что вы описали в методологии подсчета кол-ва задач никак не относится к самому интервалу, а только к его концу. Пример : Если мы будем брать завершенные карточки например за 2023 год, то, по вашей методологии, мы должны посмотреть карточки, у которых статус к моменту времни 2023-12-31 23:59 был Завершено. НО вы в итоге получите вообще все карточки, которые были завершены даже в 2022 и ранее. То есть вы всегда получаете СРЕЗ состояния карточек на момент КОНЦА завершения указанного интервала. И начало интервала никак не учаcтвует. Если вам нужно не так, то необходимо указывать, что карточка ИЗМЕНИЛА свое состояние в данном диапазоне времени на завершено. Если берем такую метрику, то далее возникают вопросы :
     1. К концу интервала ее могу вернуть в работу, учитывать ли ее в подсчете завершенных карточек?
     2. Ее могу завершить несколько раз за интервал, учитывать эти несколько раз или всего один?
     3. Картчока за один интервал может быть принята в работу, отправлена на проверку и завершена, учитывать ли ее во всех данных метриках?

• день;

• неделя;

• месяц;

• квартал;

• год;

• интервал (с … по …).

4. Визуализация:

• раскрывающаяся таблица;

• pie chart;

• линейный график;

• гистограмма.

Каждое представление может быть представлено для любой структурной единицы Битрикс24 в зависимости от настройки фильтра в пункте 1 требований. В идеале фильтр визуализации должен представлять собой множественный выбор для возможности одновременного представления на одном экране.

Раскрывающаяся таблица должна состоять из нескольких уровней, далее они будут описаны по терминологии иерархии компании в Битрикс24: 0 уровень – фин. служба, 1 уровень – департамент, 2 уровень – управление, 3 уровень – отдел, 4 уровень – сотрудник. Если в структуре между 2 и 3 уровнем присутствует заместитель начальника управления, то статистика по этому сотруднику должна отображаться отдельно. Таблица может содержать все 5 уровней и меньше в зависимости от выбранного фильтра (см. пункт 1 требований). То есть, если выбрана фин. служба, то в таблице 5 уровней, если выбран департамент, то 4 и т.д. В левом столбце таблицы – раскрывающийся многоуровневый список согласно структуре компании в Битрикс24, то есть каждый следующий уровень “выпадает” из предыдущего. Остальные столбцы – показатели задач (см. пункт 2 требований). 

• Комментарий: Реализация возможна, но тяжело будет динамически ограничивать уровень раскрытия иерархии

Схематичное представление таблицы

Остальная часть по фронту скрыта

Архитектурная реализация

Структура БД (без истории дедлайнов)

![[bitrix.pgerd.png]]

Загрузка данных

Данные могут загружаться двумя путями:

1. Периодическое обновление (более простой) С указанным интервалом будет производиться выгрузка карточек обновленных за интервал
2. Вебхуки (Более сложный) Битрикс будет сам при наступлении обновления карточек кидать нам хук, который мы будем обрабатывать. Все изменения будут отражаться в реальном времени.

Для обеих случаев нужно продумать механизм соединения, так как битрикс и суперсет лежат в разных контурах. Возможно, из-за этого нормально реализуем только 1ый вариант (просто будем подключаться по ВПН).

Нужные нам bitrix API запросы:

• Департаменты
• Таски
• Юзеры