diff --git a/Банкротство.Про.md b/Банкротство.Про.md new file mode 100644 index 0000000..fd3e091 --- /dev/null +++ b/Банкротство.Про.md @@ -0,0 +1,312 @@ + +# КОММЕРЧЕСКОЕ ПРЕДЛОЖЕНИЕ +**Тема:** Разработка автоматизированной системы управления делами о банкротстве физических лиц «Банкротство.Про» (рабочее название) + +## 1. Цели и бизнес-ценность +**Проблема:** Ведение сотен дел вручную приводит к риску пропуска процессуальных сроков (что грозит отстранением АУ и убытками), рутине при рассылке запросов в госорганы и сложности в контроле этапов (РДГ, РиГ). +**Решение:** Создание единой цифровой среды, где каждый шаг алгоритма (согласно загруженному файлу) превращается в автоматическую задачу, а рутина (запросы, публикации, расчеты) делегируется системе. +**Результат:** +* Снижение трудозатрат на 1 дело на **60-70%**. +* Исключение пропусков процессуальных сроков (система не даст провести дело дальше, если не закрыт предыдущий блок). +* Возможность вести на одного юриста не 20-30, а **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 мес.** | **~ 1 650 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 макростатусов (этапов)**, внутри которых система автоматически контролирует микро-шаги и дедлайны. + +--- + +### 📊 Модель статусов дела (Kanban / Pipeline) + +Каждое дело в системе имеет один из следующих статусов. Переход между статусами может быть как ручным (подтверждение юристом), так и автоматическим (при выполнении условий). + +| № | Статус дела (Этап) | Триггер входа в статус | Ключевые задачи внутри статуса (из 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 дней). + +--- + +Ниже представлена детализированная постановка задачи (Техническое Задание, ТЗ) для команды разработки, адаптированная под ваши уточнения: **отказ от Канбан-доски в пользу табличного интерфейса**, упрощенная ролевая модель (Юрист, Руководитель) и специфическая функция руководителя. + +ТЗ структурировано так, чтобы разработчик мог сразу декомпозировать его на задачи (Jira/YouTrack). + +--- + +# ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Система учета дел о банкротстве (Этапы 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. Технические требования и стек (Рекомендация для разработчика) + +* **Backend:** Node.js +* **Frontend:** Vue.js 3 + UI-библиотеки с мощными таблицами. +* **База данных:** PostgreSQL (строгая типизация обязательна для финансовых данных и связей) + MongoDB. +* **Хранение файлов:** Локальное хранилище на сервере или S3-совместимое (Yandex Object Storage) для надежности. +* **Безопасность:** + * Реализация механизма Impersonation через временные JWT-токены с ограниченным временем жизни (например, 15 минут), чтобы руководитель мог безопасно "войти как юрист". + * Хэширование паролей (bcrypt). + +--- + +## 5. Критерии приемки (Definition of Done) для Этапа 1 + +1. Руководитель может создать пользователя-юриста, назначить ему дело и нажать "Войти как", оказавшись в интерфейсе юриста в новой вкладке. +2. Юрист может ввести дату для шага 1.00, и система автоматически рассчитает и подсветит дедлайн для шага 4.00. +3. Юрист не может отметить шаг 13.50 как "Выполненный", пока не загрузит файл в поле "Определение о включении в РТК". +4. Все данные отображаются в таблицах с возможностью сортировки по дедлайнам и фильтрации по статусам (🟢/🟡/🔴). Канбан-элементы отсутствуют.