# ТЗ: Evrone Repay — обслуживание займов

Демонстрационная версия документа · категория «Финансы» · №12

> Это демонстрационное техническое задание: оно показывает структуру и глубину
> документа, который передаётся вместе с прототипом. Боевое ТЗ по этому солюшену
> готовится и заменит этот файл.

## 1. Суть решения

График платежей, кабинет заёмщика, автосписания, стадии просрочки.

Всё, что после выдачи: график платежей (аннуитетный/дифференцированный), кабинет заёмщика (оплата, досрочное погашение, реструктуризация), автосписания с ретраями, стадии просрочки с автокоммуникациями (SMS/email/робозвонки), кабинет коллектора, отчётность. Credit + Repay вместе образуют полный конвейер, но продаются и по отдельности.

## 2. Технологический стек

| Слой | Решение |
|---|---|
| Backend | Ruby on Rails 8, PostgreSQL |
| Frontend | Hotwire (Turbo + Stimulus), Tailwind CSS |
| Фоновые задачи | Solid Queue |
| Файлы | Active Storage, S3-совместимое хранилище |
| Деплой | Docker, Kamal, production + staging |

## 3. Роли

- Заёмщик
- Оператор взысканий
- Бухгалтер

## 4. Модель данных

### 4.1. Loan

```
contract_id: references
schedule_kind: enum # аннуитет, дифференцированный
balance: integer
state: enum
```

### 4.2. Payment

```
loan_id: references
amount: integer
kind: enum # плановый, досрочный, частичный
state: enum
retry_count: integer
```

### 4.3. Delinquency

```
loan_id: references
bucket: enum # 1-30, 31-60, 61-90, 90+
actions: has_many
```

## 5. Ключевые сценарии

1. Заёмщик видит график платежей и гасит очередной платёж в кабинете
2. Автосписание идёт по расписанию с повторными попытками при отказе
3. При просрочке включаются автокоммуникации по стадиям
4. Досрочное погашение пересчитывает график

## 6. Интеграции

- Платёжный шлюз с рекуррентными списаниями
- SMS и email
- Робозвонки
- Бухгалтерская выгрузка

## 7. Нефункциональные требования

- Серверный рендеринг, работоспособность ключевых страниц без JavaScript
- Мобильная адаптивность обязательна
- Роли и права проверяются на уровне сервера, а не интерфейса
- Логирование действий пользователей по значимым операциям
- Покрытие тестами моделей и ключевых сценариев
- Развёртывание одной командой, окружения production и staging

## 8. Состав MVP

График + оплата + обработка просрочки.

## 9. Критерии приёмки

1. Все сценарии из раздела 5 проходят end-to-end на тестовом стенде
2. Роли из раздела 3 видят только то, что им положено
3. Интеграции из раздела 6 работают через слой адаптеров и переключаются конфигурацией
4. Прототип разворачивается из репозитория одной командой
5. Документация по запуску и переменным окружения лежит в README