dtorov/projects
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
projects/Bankrot.Pro.md

38 KiB
Raw Permalink Blame History

КОММЕРЧЕСКОЕ ПРЕДЛОЖЕНИЕ

Тема: Разработка автоматизированной системы управления делами о банкротстве физических лиц «Банкротство.Про» (рабочее название)

1. Цели и бизнес-ценность

Проблема: Ведение сотен дел вручную приводит к риску пропуска процессуальных сроков (что грозит отстранением АУ и убытками), рутине при рассылке запросов в госорганы и сложности в контроле этапов (РДГ, РиГ). Решение: Создание единой цифровой среды, где каждый шаг алгоритма (согласно загруженному файлу) превращается в автоматическую задачу, а рутина (запросы, публикации, расчеты) делегируется системе. Результат:

  • Снижение трудозатрат на 1 дело на 60-70%.
  • Исключение пропусков процессуальных сроков (система не даст провести дело дальше, если не закрыт предыдущий блок).
  • Возможность вести на одного юриста 100-150 дел одновременно.

2. Архитектура и Этапы разработки

Разработка разделена на 3 последовательных этапа, что позволит быстро получить работающий инструмент (MVP) и постепенно внедрять сложный функционал.

ЭТАП 1: Базовый интерфейс и цифровой архив (Фундамент)

Цель этапа: Оцифровать все дела, создать единое пространство для документов и жесткий контроль процессуальных сроков.

Функционал:

  1. Ролевая модель и Авторизация: Руководитель, Арбитражный Управляющий, Юрист.
    • Юрист (Исполнитель): Видит только свои дела. Заполняет данные, загружает документы, отмечает выполнение шагов алгоритма. Не может удалять дела или менять глобальные настройки.
    • Арбитражный Управляющий (Исполнитель): Видит дела заданного стиска Юристов. Заполняет данные, загружает документы, отмечает выполнение шагов алгоритма. Не может удалять дела или менять глобальные настройки.
    • Руководитель (Администратор): Видит все дела всех юристов. Имеет доступ к сводному Дашборду рисков. Ключевая функция «Войти как»: В таблице дел рядом с ФИО юриста есть кнопка. При нажатии открывается новая вкладка браузера, где руководитель автоматически авторизуется под учетной записью этого юриста (без ввода пароля), чтобы проверить корректность заполнения карточки глазами сотрудника.
  2. Карточка Дела (Досье должника): Создаётся на основе запоненной "Формы должника" разработанной ранее.
    • Паспортные данные, СНИЛС, ИНН, контакты, занятость, семейное положение и т.д.
    • Блок «Кредиторы» (с привязкой к очередям РТК), дорабатывается в процессе хода дела.
    • Блок «Доходы и Имущество» (электронная опись), дорабатывается в процессе хода дела.
    • Блок «Иные задолженности» (электронная опись), дорабатывается в процессе хода дела.
  3. Умный Календарь и Трекер сроков (Критически важно):
    • Автоматический расчет сроков на основе алгоритма (например: «+2 месяца от даты Ъ для требований кредиторов», «+15 дней от утверждения ФУ для запросов в ГИБДД/ФНС»).
    • Цветовая индикация (зеленый/желтый/красный) и push/email уведомления ответственным за 3 дня до дедлайна.
  4. Хранилище документов: Загрузка, тегирование и привязка документов к конкретным шагам алгоритма (Определения суда, чеки ЕФРСБ, ответы ЗАГС/ФНС).
  5. Список дел: Визуализация портфеля дел по статусам (Сбор документов -> РДГ -> ФА/СК -> РиГ -> Завершение).
  6. Генератор документов:
    • Автоматический генератор документов с возможностью редактирования перед печатью или выгрузкой в ms Word(базовый функционал для дальнейшего использования - генерация документа, окно редактирования документа, печать и выгрузка)
    • Автоматическая генерация пакетов запросов в госорганы (ГИБДД, ГИМС, ЗАГС, ФНС, ПФР, Роспатент - 14 направлений) и банки.
    • Автоматическая генерация отчета АУ на основании имеющихся данных
  • Срок реализации: 2 месяца
  • Стоимость: 200 000 ₽

ЭТАП 2: Внешние интеграции и автоматизация рутины

Цель этапа: Убрать ручное составление типовых запросов, интеграция с внешними сервисами для публикации и сбора данных. Возможность интеграции определяется на момент заключения договора. Функционал:

  1. Генератор документов:
    • Автоматическая генерация документов по ходу дела.
    • Интеграция с API Почты России / сервисами электронного документооборота (СДЭК, Диадок) для автоматической отправки бумажных и ЭД писел.
  2. Интеграция с ЕФРСБ и Коммерсантъ:
    • Прямая API-интеграция (или полуавтоматическая выгрузка XML/JSON макетов) для публикации сообщений о введении РДГ, итогах СК, переходе в РиГ.
    • Автоматическое получение появляющихся документов из ЕФРСБ
    • Автоматическое сохранение чеков и ID публикаций в карточку дела (Блок расходов).
  3. Интеграция с «Мой Арбитр» (Кад Арбитр):
    • Парсинг событий по делу (автоматическое подтягивание новых Определений суда в карточку).
    • Формирование пакетов документов для подачи через систему ЭДО «Мой Арбитр».
  4. Клиентский портал / Telegram-бот:
    • Уведомление должника о ходе процесса.
    • Автоматическая отправка должнику запросов на предоставление недостающих документов (чек-листы). Одноразовая страница загрузки данных.
  • Срок реализации: 2 месяца
  • Стоимость: 200 000 ₽

ЭТАП 3: Интеллект, Финансовый анализ и сложные документы

Цель этапа: Автоматизировать самую сложную и дорогую часть работы юриста/помощника — анализ сделок, подготовку отчетов и проведение Собраний кредиторов (СК). Функционал:

  1. AI Модуль Финансового Анализа (ФА) и Заключений:
    • Импорт выписок по счетам (парсинг PDF/Excel/1C).
    • Автоматический расчет движения денежных средств, выявление транзакций, подпадающих под признаки оспариваемых сделок (неравноценное встречное исполнение, вывод активов).
    • Генератор черновиков «Заключения о наличии/отсутствии признаков фиктивного/преднамеренного банкротства».
  2. Продвинутый генератор процессуальных документов:
    • Автоматическое формирование «Отчета АУ», «Ходатайства о переходе в РиГ», «Возражений на требования кредиторов» (на основе данных из РТК и карточки дела).
  3. Автоматизация Собрания Кредиторов (СК):
    • Автоматическая генерация Бюллетеней для голосования на основе утвержденного РТК.
    • Модуль подсчета голосов (при заочном голосовании): загрузка сканов/ЭЦП, автоматический расчет кворума и принятия решений.
    • Генерация Протокола СК и автоматическая подготовка макета публикации результатов в ЕФРСБ.
  4. Аналитика для Руководства:
    • Дашборды: загрузка сотрудников, рентабельность каждого дела (Доходы минус РХ на публикации/почту), карта рисков (дела, где скоро истекают критические сроки).
  • Срок реализации: 2.5 месяца
  • Стоимость: ~500 000 ₽

3. Сводные сроки и бюджет

Этап Описание Сроки Стоимость (ориентир)
Этап 1 CRM, Карточки дел, Календарь сроков, Роли, Архив 1.5 мес. 170 000 ₽
Этап 2 Интеграции (ЕФРСБ, Почта, Кад Арбитр), Бот для клиентов, Авто-запросы 2 мес. 200 000 ₽
Этап 3 ФА, Парсинг выписок, Генерация Отчетов АУ, Модуль СК 2.5 мес. 500 000 ₽
ИТОГО Полный цикл разработки и внедрения ~ 6 мес. ~ 870 000 ₽

Примечание: После сдачи проекта предполагается выделение 10-15% от бюджета на ежемесячную техническую поддержку, обновление интеграций (т.к. API госорганов и ЕФРСБ периодически меняются) и доработку мелкого функционала. Также, необходим выделенный виртульный сервер для размещения проекта, стартовая стоимость 3-5т.р./мес

4. Предлагаемый Стек технологий

Учитывая требования к надежности, масштабируемости и современным стандартам веб-разработки, предлагается следующий стек:

  • Backend (Серверная часть): Node.js (NestJS или Express) — отлично подходит для высоконагруженных систем, работы с очередями задач (отправка писем, парсинг) и интеграциями.
  • Frontend (Интерфейс): Vue.js 3 (Composition API) + Vuetify или Element Plus — быстрый, отзывчивый интерфейс, удобные таблицы для РТК и канбан-доски.
  • База данных: PostgreSQL — строгая реляционная БД критически важна для финансовых данных, РТК, связей "Дело-Кредитор-Транзакция" и обеспечения целостности данных. MongoDB - пользователи, статуса, конфигурация процесса.
  • Инфраструктура: Docker, CI/CD (GitLab/GitHub Actions), развертывание на выделенном VPS или в облаке (Yandex Cloud / Selectel) с ежедневным бэкапом БД.

5. Окупаемость (ROI) для юридической фирмы

  • Текущие потери: Допустим, компания ведет 300 дел. Ручная подготовка запросов, контроль сроков и составление отчетов съедает до 40% рабочего времени пула юристов и помощников. Ошибка в сроках стоит от 50 000 до 200 000 ₽ (штрафы, отстранение, репутация).
  • Эффект от ПО: Высвобождается эквивалент 2-3 фул-тайм сотрудников. Система окупается за 4-6 месяцев исключительно за счет экономии на фонде оплаты труда (ФОТ) линейного персонала и отсутствия штрафов за пропущенные сроки.

📊 Модель статусов дела

Для удобства управления большим количеством дел в ПО не удобно использовать плоский список из 20+ шагов. Вместо этого алгоритм группируется в 7 макростатусов (этапов), внутри которых система автоматически контролирует микро-шаги и дедлайны.

Каждое дело в системе имеет один из следующих статусов. Переход между статусами может быть как ручным (подтверждение юристом), так и автоматическим (при выполнении условий).

№ Статус дела (Этап) Триггер входа в статус Ключевые задачи внутри статуса (из Excel)
1 Старт и введение РДГ Загружено Определение суда о введении РДГ (п. 1.00–3.00) Внесение данных должника, публикация в ЕФРСБ/Ъ (3 дня), уведомление кредиторов и должника (7 дней).
2 Сбор информации и опись Утвержден Финансовый управляющий (ФУ) / получены первые ответы (п. 6.00–12.00) Рассылка запросов в госорганы (15 дн.) и банки (5 дн. после ФНС). Опись имущества. Обработка ответов или отсутствие ответов.
3 Формирование РТК Опубликована заметка в «Коммерсантъ» (п. 13.00–13.50) Прием требований (2 мес.), подготовка возражений (за 10 дн. до суда), включение в РТК (5 раб. дней после определения).
4 Аналитика и отчетность РТК сформирован или назначена дата СК/суда (п. 14.00–17.00) Финансовый анализ (ФА), заключения (о сделках, о фиктивном/преднамеренном банкротстве), Отчет АУ.
5 Подготовка и проведение СК Готовы отчеты и заключения (п. 18.00–18.30) Назначение заочного СК, рассылка бюллетеней, проведение, составление протокола (5 дн.), публикация итогов.
6 Судебное заседание и переход в РиГ Проведено СК (п. 19.00–19.40) Подача пакета документов в АС (за 10 дн. до суда), ходатайство о переходе в РиГ, контроль согласия СРО, финальная публикация в ЕФРСБ (10 дн.).
7 Завершение и передача в бухг. Вынесено решение о переходе в РиГ или завершении РДГ (п. 20.00–20.10) Передача заявки в бухгалтерию на выплату (35 дн.), контроль выплат, архивация дела.

⏱️ Схема контроля сроков (Логика работы ПО)

Система не просто показывает дату, она динамически рассчитывает дедлайны на основе «Даты-триггера» и управляет действиями исполнителя.

Правило расчета сроков:

Дедлайн = Дата-триггер + Срок из алгоритма (в днях) Система хранит все "Даты-триггеры" (дата определения, дата публикации в Ъ, дата отправки запроса).

Детальная схема контроля по статусам:

Статус 1: Старт и введение РДГ

  • Триггер: Дата определения суда о введении РДГ.
  • Контроль 1: Триггер + 3 дня → Дедлайн публикации в ЕФРСБ и Ъ. (Если не загружен чек: статус задачи "Красный", уведомление юристу).
  • Контроль 2: Дата публикации в Ъ + 7 дней → Дедлайн уведомления кредиторов.
  • Контроль 3: Дата определения + 7 дней → Дедлайн уведомления должника.

Статус 2: Сбор информации и опись (Критический блок автоматизации)

  • Триггер: Дата утверждения ФУ / Дата отправки конкретного запроса.
  • Контроль 1 (Госорганы): Дата утверждения ФУ + 15 дней → Дедлайн рассылки запросов (ГИБДД, ЗАГС, ФНС и т.д.).
  • Контроль 2 (Банки): Дата ответа ФНС + 5 дней → Дедлайн рассылки запросов в банки.
  • АВТОМАТИЧЕСКИЙ КОНТРОЛЬ "35 ДНЕЙ" (п. 6.20, 7.20, 8.20, 9.20, 10.20):
    • Система ставит внутренний таймер на каждый отправленный запрос.
    • Если через 35 дней в поле "Ответ получен" нет галочки → Система автоматически меняет статус подзадачи на "Нет ответа" и создает задачу помощнику: "Сформировать заявление в АС об истребовании / в полицию" (срок исполнения: 5 дней с 35-го дня).

Статус 3: Формирование РТК

  • Триггер: Дата публикации в «Коммерсантъ».
  • Контроль 1: Дата публикации + 2 месяца → Дедлайн поступления требований кредиторов. Система блокирует возможность закрытия этапа раньше этого срока (если нет досрочного закрытия).
  • Контроль 2 (Возражения): Дата судебного заседания (из карточки дела) - 10 дней → Жесткий дедлайн подготовки и отправки возражений. (Уведомление юристу за 15 дней до дедлайна).
  • Контроль 3: Дата определения о включении + 5 раб. дней → Дедлайн публикации о включении в РТК и обновления реестра в ПО.

Статус 4: Аналитика и отчетность

  • Триггер: Дата проведения СК или Дата судебного заседания (указывается вручную или парсится из «Мой Арбитр»).
  • Контроль: Дата СК/Суда - 35 дней (или -50 дней до суда) → Единый дедлайн для загрузки в систему: ФА, Заключения (о сделках, о преднамеренном банкротстве), Отчета АУ.
  • Логика: Система не даст перевести дело в Статус 5, пока не будут загружены эти 4 документа.

Статус 5: Подготовка и проведение СК

  • Триггер: Готовность отчетов.
  • Контроль 1: Дата проведения СК - 15 дней → Дедлайн фактического проведения заочного ознакомления/голосования.
  • Контроль 2: Дата проведения СК + 5 дней → Дедлайн публикации протокола и результатов СК в ЕФРСБ (при наличии кворума).

Статус 6: Судебное заседание и переход в РиГ

  • Триггер: Дата проведения СК.
  • Контроль 1: Дата проведения СК + 5 раб. дней (но не позднее чем Дата суда - 10 дней) → Дедлайн подачи пакета документов (Отчет, ФА, заключения, бюллетени) и Ходатайства о переходе в РиГ через «Мой Арбитр».
  • Контроль 2: Дата определения о введении РиГ + 10 дней → Дедлайн размещения финального отчета на ЕФРСБ.

Статус 7: Завершение и передача в бухг.

  • Триггер: Дата решения о взыскании / переходе в РиГ.
  • Контроль: Дата решения + 35 дней → Дедлайн передачи заявки в бухгалтерию АС на выплату вознаграждения/расходов.

⚙️ Технические требования к модулю контроля сроков (для разработчиков)

  1. Цветовая индикация (Светофор):

    • 🟢 Зеленый: До дедлайна > 3 дней.
    • 🟡 Желтый: До дедлайна ≤ 3 дней (отправка push/email уведомления ответственному).
    • 🔴 Красный: Дедлайн пропущен (уведомление руководителю практики + блокировка возможности закрыть этап без комментария).

  2. Каскадное обновление дат: Если дата судебного заседания переносится (парсинг из «Мой Арбитр» или ручной ввод), система должна автоматически пересчитать все зависимые дедлайны (например, дедлайн подачи возражений или отчетов), которые отсчитываются "от даты суда".

  3. Чек-листы обязательности: Для перехода из Статуса 2 в Статус 3 система должна проверить наличие в карточке:

    • Чеки ЕФРСБ/Ъ
    • Заполненная опись имущества (или акт о том, что имущество не найдено)
    • Подтверждение отправки запросов в госорганы.

  4. Дашборд просрочек: На главной странице руководителя должен быть виджет "Дела с критическими рисками", показывающий дела, где пропущен срок подачи возражений, срок публикации или срок ответа на запрос (35 дней).

ТЕХНИЧЕСКОЕ ЗАДАНИЕ: (Этапы 1 и 2)

1. Ролевая модель и права доступа (RBAC)

В системе предусмотрено ровно две роли. Разграничение прав строгое.

  1. Юрист (Исполнитель):
    • Видит только назначенные ему дела.
    • Может создавать и редактировать карточки дел, загружать документы.
    • Может менять статусы шагов алгоритма, вводить триггерные даты.
    • Не может удалять дела или изменять глобальные настройки алгоритма.
  2. Руководитель (Администратор практики):
    • Видит все дела всех юристов.
    • Имеет доступ к сводному Дашборду.
    • Функция "Войти как" (Impersonation): Рядом с ФИО любого юриста в таблице есть кнопка "Войти как [Имя]". При нажатии открывается новая вкладка браузера, в которой система автоматически авторизует руководителя под учетной записью выбранного юриста (без запроса пароля), чтобы увидеть интерфейс и данные ровно так, как их видит сотрудник.

2. ЭТАП 1: Базовый интерфейс, учет и контроль сроков

2.1. Модели данных (Core Entities)

Разработчику необходимо создать следующие сущности в БД:

  • User: id, role, full_name, login, password_hash.
  • Debtor (Должник): id, full_name, inn, snils, birth_date, address.
  • Case (Дело): id, debtor_id, lawyer_id, case_number (А40-...), current_macro_status, created_at.
  • Creditor (Кредитор): id, case_id, name, inn, debt_amount, queue_number (1, 2, 3, реестровые/текущие).
  • Document: id, case_id, file_name, file_url, document_type (из справочника), uploaded_at.
  • WorkflowStep (Шаг алгоритма): id, case_id, step_code (напр., "1.00"), step_name, trigger_date, deadline_date, status (pending, warning, overdue, completed), required_doc_type.

2.2. Пользовательский интерфейс (UI) – Табличное представление

Весь интерфейс строится на данных таблицах (Data Grid) с фильтрацией и сортировкой. Возможен вариант в виде Kanban досок.

  1. Экран "Дашборд Руководителя" (Главная):
    • Виджеты: "Всего дел в работе", "Просроченных дедлайнов (Красных)", "Дел по каждому юристу".
    • Таблица "Все дела": Колонки: № дела, Должник, Ответственный юрист, Текущий этап, Ближайший дедлайн (с цветовой индикацией), Действия (кнопка "Войти как").
  2. Экран "Мои дела" (для Юриста):
    • Таблица дел, где lawyer_id = id текущего пользователя.
    • Колонки: № дела, Должник, Текущий макро-статус, Ближайший дедлайн, Прогресс выполнения шагов (напр., "15/40").
  3. Экран "Карточка дела" (Детальная):
    • Вкладки:
      • Основное: Данные должника, номер дела, выбор ответственного юриста.
      • Кредиторы (РТК): Простая таблица (Добавить/Редактировать/Удалить) с полями из п. 4.00/13.50 Excel (Наименование, ИНН, Очередь, Сумма).
      • Документы: Список загруженных файлов с типом документа и датой. Кнопка "Загрузить".
      • Чек-лист алгоритма (Ключевой модуль): Список шагов из конфигурации (1.00, 2.00, 4.00 и т.д.).
        • Вид строки шага: [Чекбокс выполнения] | Название шага | Введенная дата-триггер | Рассчитанный дедлайн | Статус (🟢/🟡/🔴) | Кнопка "Загрузить документ".

2.3. Бизнес-логика и Контроль сроков (Workflow Engine)

Система должна динамически рассчитывать сроки на основе данных из конфигурации.

  • Правило расчета: Дедлайн = Дата-триггер + Смещение (в днях).
  • Пример реализации (п. 1.00 -> п. 4.00):
    1. Юрист в шаге "1.00" вводит "Дату принятия заявления" и загружает "Определение суда".
    2. Система автоматически рассчитывает дедлайн для шага "4.00" как Дата_триггер + 3 дня.
    3. Если до дедлайна > 3 дней: статус 🟢.
    4. Если до дедлайна ≤ 3 дней: статус 🟡 (желтый), отправка email-уведомления юристу.
    5. Если дедлайн прошел: статус 🔴 (красный), дело попадает в виджет "Просрочено" на дашборд руководителя.
  • Валидация закрытия шага: Шаг нельзя отметить галочкой "Выполнено", если не загружен документ, указанный в колонке "Документы подтверждающие" (например, для п. 13.50 обязательно наличие "определение о включении в РТК").
  • Автоматический контроль "35 дней" (п. 6.20, 7.20, 8.20, 9.20, 10.20):
    • Система ежедневно (cron job) проверяет шаги типа "Запрос отправлен".
    • Если Текущая дата >= Дата_отправки + 35 дней И статус ответа ≠ "Получен", система автоматически меняет статус шага на 🔴 и создает внутреннюю задачу: "Подготовить заявление в АС об истребовании".

3. ЭТАП 2: Внешние интеграции, генерация документов и оповещения

3.1. Модуль генерации документов (Document Generator)

  • Механизм: Как использование шаблонов .docx с плейсхолдерами (например, {{debtor_full_name}}, {{case_number}}, {{court_name}}, {{current_date}}), полная генерация по харкрду, возможно доработка с ИИ.
  • Автоматизация по триггерам:
    • При срабатывании правила "35 дней без ответа" (п. 6.20, 7.20 и т.д.) система автоматически генерирует готовый .docx файл "Заявление в АС об истребовании", подставляя данные должника, номер дела и наименование госоргана, в который изначально шел запрос. Файл сразу прикрепляется к карточке дела как черновик.
    • Генерация "Возражений на требования кредиторов" (п. 13.30): Юрист выбирает кредитора из таблицы РТК, система генерирует шаблон возражения с подставленными суммами и датами.

3.2. Интеграции (API / Парсинг)

  1. Кад.Арбитр (Мой Арбитр):
    • Функция: По номеру дела (А40-...) система должна уметь получать базовые данные о последних судебных актах (через открытый API или парсинг, если API недоступен).
    • Цель: Автоматическое предложение юристу обновить статус дела при появлении нового "Определения о введении РДГ" (п. 3.00) или "Определения о включении в РТК" (п. 13.50).
  2. Почтовые сервисы (SMTP / Yandex Mail API):
    • Возможность отправить "Уведомление должника" (п. 6.00) или "Уведомление кредиторов" (п. 5.00) прямо из интерфейса системы. Система подставляет шаблон письма, прикрепляет сгенерированный PDF и отправляет, фиксируя факт отправки в истории дела.
  3. ЕФРСБ / Коммерсантъ (Подготовка макетов):
    • Полная авто-публикация на Этапе 2 не требуется (из-за сложности ЭЦП), но система должна генерировать готовый текст макета для копирования в личный кабинет ЕФРСБ, подставляя ИНН, ФИО и номер дела, а также предоставлять поле для загрузки чека об оплате (п. 4.00, 13.20).

3.3. Оповещение клиентов (Должников)

  • Канал: Telegram/МАКС-бот или Email-рассылка.
  • Сценарий: При создании дела или переходе на этап "Сбор информации" (п. 6.00), система позволяет юристу нажать кнопку "Отправить запрос документов должнику".
  • Действие: Клиенту приходит сообщение: "Уважаемый [Имя], для продолжения процедуры банкротства по делу № [Номер] пожалуйста, загрузите следующие документы: [Список из п. 6.00]. Ссылка для загрузки: [ссылка на простую веб-форму]".
  • Веб-форма для клиента: Простая страница без авторизации (по уникальной одноразовой ссылке), где должник может загрузить сканы своих документов. Загруженные файлы автоматически попадают в раздел "Документы" карточки дела с пометкой "От должника".

4. Критерии приемки (Definition of Done) для Этапа 1

  1. Руководитель может создать пользователя-юриста, назначить ему дело и нажать "Войти как", оказавшись в интерфейсе юриста в новой вкладке.
  2. Юрист может ввести дату для шага 1.00, и система автоматически рассчитает и подсветит дедлайн для шага 4.00.
  3. Юрист не может отметить шаг 13.50 как "Выполненный", пока не загрузит файл в поле "Определение о включении в РТК".
  4. Все данные отображаются в таблицах с возможностью сортировки по дедлайнам и фильтрации по статусам (🟢/🟡/🔴).