# КОММЕРЧЕСКОЕ ПРЕДЛОЖЕНИЕ **Тема:** Разработка автоматизированной системы управления делами о банкротстве физических лиц «Банкротство.Про» (рабочее название) ## 1. Цели и бизнес-ценность **Проблема:** Ведение сотен дел вручную приводит к риску пропуска процессуальных сроков (что грозит отстранением АУ и убытками), рутине при рассылке запросов в госорганы и сложности в контроле этапов (РДГ, РиГ). **Решение:** Создание единой цифровой среды, где каждый шаг алгоритма (согласно загруженному файлу) превращается в автоматическую задачу, а рутина (запросы, публикации, расчеты) делегируется системе. **Результат:** * Снижение трудозатрат на 1 дело на **60-70%**. * Исключение пропусков процессуальных сроков (система не даст провести дело дальше, если не закрыт предыдущий блок). * Возможность вести на одного юриста **100-150 дел** одновременно. --- ## 2. Архитектура и Этапы разработки Разработка разделена на 3 последовательных этапа, что позволит быстро получить работающий инструмент (MVP) и постепенно внедрять сложный функционал. ### ЭТАП 1: Базовый интерфейс и цифровой архив (Фундамент) **Цель этапа:** Оцифровать все дела, создать единое пространство для документов и жесткий контроль процессуальных сроков. **Функционал:** 1. **Ролевая модель и Авторизация:** Руководитель, Юрист. * Юрист (Исполнитель): Видит только свои дела. Заполняет данные, загружает документы, отмечает выполнение шагов алгоритма. Не может удалять дела или менять глобальные настройки. * Руководитель (Администратор): Видит все дела всех юристов. Имеет доступ к сводному Дашборду рисков. Ключевая функция «Войти как» (Impersonation): В таблице дел рядом с ФИО юриста есть кнопка. При нажатии открывается новая вкладка браузера, где руководитель автоматически авторизуется под учетной записью этого юриста (без ввода пароля), чтобы проверить корректность заполнения карточки глазами сотрудника. 2. **Карточка Дела (Досье должника):** Создаётся на основе запоненной "Формы должника" разработанной ранее. * Паспортные данные, СНИЛС, ИНН, контакты, занятость, семейное положение и т.д. * Блок «Кредиторы» (с привязкой к очередям РТК), дорабатывается в процессе хода дела. * Блок «Имущество» (электронная опись), дорабатывается в процессе хода дела. 3. **Умный Календарь и Трекер сроков (Критически важно):** * Автоматический расчет сроков на основе алгоритма (например: *«+2 месяца от даты Ъ для требований кредиторов»*, *«+15 дней от утверждения ФУ для запросов в ГИБДД/ФНС»*). * Цветовая индикация (зеленый/желтый/красный) и push/email уведомления ответственным за 3 дня до дедлайна. 4. **Хранилище документов:** Загрузка, тегирование и привязка документов к конкретным шагам алгоритма (Определения суда, чеки ЕФРСБ, ответы ЗАГС/ФНС). 5. **Список дел:** Визуализация портфеля дел по статусам (Сбор документов -> РДГ -> ФА/СК -> РиГ -> Завершение). * **Срок реализации:** 1.5 месяца * **Стоимость:** 170 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 система должна проверить наличие в карточке: * [x] Чеки ЕФРСБ/Ъ * [x] Заполненная опись имущества (или акт о том, что имущество не найдено) * [x] Подтверждение отправки запросов в госорганы. 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. Все данные отображаются в таблицах с возможностью сортировки по дедлайнам и фильтрации по статусам (🟢/🟡/🔴).