Appearance
Дорожная карта проекта Nimbus на 3 месяца
Разбивка оставшегося функционала на этапы: MVP (критический функционал), Интеграции, Отчётность. Используется для планирования спринтов и распределения задач (в т.ч. для Junior — см. junior_tasks.md).
Обзор этапов
| Этап | Месяц | Фокус | Критичность |
|---|---|---|---|
| 1. MVP: Ядро биллинга | 1 | Начисления, перерасчеты, закрытие периода | Критический |
| 2. MVP: Платежи и учёт | 1–2 | Платежи, долги, пени, Ledger-принципы | Критический |
| 3. Интеграции | 2 | Банки (1С/клиент-банк, API), ГИС ЖКХ, платежный шлюз | Высокий |
| 4. Отчётность и выгрузки | 2–3 | Отчёты, Excel/PDF, дашборды | Высокий |
| 5. Полировка и стабилизация | 3 | Тесты, документация, UX, баг-фиксы | Высокий |
Этап 1. MVP: Ядро биллинга (месяц 1)
Цель: завершить базовый цикл «начисление → перерасчёт → закрытие периода» без изменения правил ПП 354.
1.1 Движок начислений (billing-service)
- Расчёт по тарифам и нормативам на основе данных из core-service (ЛС, помещения, услуги, тарифы, показания).
- Учёт формул ПП 354 (коды формул уже есть в core; billing только применяет их).
- Массовый расчёт по периоду (месяц/год), сохранение в
Charge/ аналог. - Не трогать: сами формулы и коды в core-service — только вызов/интеграция.
1.2 Перерасчёты
- Корректировки при изменении показаний/тарифов (только через корректирующие операции, без правки истории).
- Ограниченный перерасчёт по выбранным ЛС/периодам.
1.3 Закрытие периода
- Фиксация периода (блокировка изменений по закрытому периоду).
- Базовые проверки перед закрытием (нет незавершённых расчётов и т.п.).
Результат этапа: УК может провести начисление за месяц, сделать перерасчёт и закрыть период.
Этап 2. MVP: Платежи и учёт (месяц 1–2)
Цель: учёт платежей, долгов и пеней в соответствии с архитектурой Ledger (без UPDATE балансов).
2.1 Модели и API платежей
- Сущность платежа (дата, сумма, назначение, связь с ЛС).
- Распределение платежа по начислениям (погашение долга по периоду/услуге).
2.2 Долг и пени
- Реализация/доработка моделей по DEBT_AND_PENALTY_ARCHITECTURE.md:
AccountBalance(текущий баланс ЛС) только как производная от проводок.DebtItem, при необходимости —PenaltyCalculation,InterestRate.
- Правило: изменение долга/баланса только через проводки (двойная запись), не через UPDATE полей баланса.
- Реализация/доработка моделей по DEBT_AND_PENALTY_ARCHITECTURE.md:
2.3 Расчёт пеней
- Алгоритм по инструкции: первые 30 дней без пеней, далее 1/300, с 91-го дня 1/130, учёт ключевой ставки и льгот до 2027.
2.4 UI: платежи и долги
- Список платежей по ЛС/организации, отображение долга и пеней по ЛС.
Результат этапа: полный цикл «начисление → оплата → долг/пени» с соблюдением принципов Ledger.
Этап 3. Интеграции (месяц 2)
Цель: обязательная интеграция с ГИС ЖКХ и построение финансового хаба (банки/платежи).
3.1 Финансовый хаб: банки и платежи
- Поддержка текстового формата 1С (клиент-банк):
- загрузка файлов выписок/реестров в формате 1С;
- парсинг строк, сопоставление с ЛС и созданием платежей в
billing-service; - правила маппинга (назначение платежа → ЛС/организация/услуга), полуавтоматический разбор «неидентифицированных» платежей.
- Прямые API‑интеграции с банками:
- модуль Bank Integrator (отдельный сервис/подсистема) для подключения к API банков;
- периодическая загрузка выписок и статусов платежей по защищённым каналам;
- унифицированный внутренний формат, который использует
billing-serviceдля создания Ledger‑проводок.
- Интеграция с платёжной системой (например, ЮKassa) для приёма онлайн‑оплат и синхронизации статусов.
- Поддержка текстового формата 1С (клиент-банк):
3.2 Compliance‑модуль: ГИС ЖКХ
- Подключение к API ГИС ЖКХ (по актуальной спецификации) как двусторонней интеграции:
- выгрузка домов, ЛС, начислений, показаний и статусов услуг;
- загрузка оплат и статусов их обработки;
- синхронизация ключевых справочников (виды услуг, единицы измерения, основания начислений).
- Учёт флагов в доменной модели core (
ExportToGIS,DontExportToGisIfZero, режимы тестовой/боевой выгрузки). - Логирование и мониторинг: журнал обмена с ГИС ЖКХ, контроль ошибок и ретраев.
- Подключение к API ГИС ЖКХ (по актуальной спецификации) как двусторонней интеграции:
Результат этапа: система выступает как единый финансовый хаб: получает реальные данные от банков (файлы 1С + API), синхронизирует их с Ledger и выполняет требования по отчётности и обмену данными с ГИС ЖКХ.
Этап 4. Отчётность и дашборды (месяц 2–3)
Цель: отчёты для УК, дашборды по сбору платежей и инструменты работы с дебиторкой.
4.1 Базовые отчёты
- Отчёт по начислениям за период (по домам/ЛС/услугам).
- Отчёт по платежам и задолженности.
- Отчёт по пеням (при наличии модуля пеней).
4.2 Выгрузки
- Экспорт отчётов в Excel (xlsx) и PDF.
- Выгрузка списков (ЛС, помещения, услуги, тарифы) в Excel для сверок и аудита.
4.3 Дашборды, аналитика и Messenger MAX
- Расширение дашборда: сводки по долгам, платежам, начислениям, статусы интеграций (банки, ГИС ЖКХ).
- Простые графики (динамика начислений/оплат по месяцам, топ должников и т.п.).
- Интеграция мессенджера MAX в дашборды:
- встраивание MAX‑виджета (iframe/JS‑SDK) в веб‑интерфейс Nimbus;
- быстрый переход из карточки должника/дома к диалогу в MAX;
- использование MAX как канала уведомлений по долгам, начислениям и изменениям статуса ЛС (B2B2C‑сценарии).
Результат этапа: УК может строить отчёты и выгружать их в привычных форматах.
Этап 5. Полировка и стабилизация (месяц 3)
Цель: повышение надёжности и удобства перед выходом к клиентам.
5.1 Тестирование
- Unit-тесты для расчётов (в т.ч. по сценариям Golden Test).
- Интеграционные тесты API (core, billing, auth).
- Регрессия после изменений в формулах ПП 354.
5.2 Документация и онбординг
- Актуализация README, API-документации.
- Онбординг новых разработчиков (в т.ч. onboarding.md, junior_tasks.md).
5.3 UX и баг-фиксы
- Исправление критических и высокоприоритетных багов.
- Улучшение форм и списков (валидация, сообщения об ошибках, загрузки).
Результат этапа: стабильная версия, готовая к пилотам с первыми УК.
Сводная таблица по месяцам
| Недели | Этап | Основные задачи |
|---|---|---|
| 1–2 | 1 | Движок начислений, массовый расчёт |
| 3–4 | 1–2 | Перерасчёты, закрытие периода; модели платежей и Ledger |
| 5–6 | 2 | Долг/пени, расчёт пеней, UI платежей и долгов |
| 7–8 | 3 | ГИС ЖКХ, импорт выписок, платежный шлюз |
| 9–10 | 4 | Базовые отчёты, экспорт Excel/PDF, дашборды + интеграция MAX |
| 11–12 | 5 | Тесты, документация, баг-фиксы, UX |
Связь с задачами для Junior
Задачи, не затрагивающие ядро расчётов и ПП 354, выделены в junior_tasks.md. Их можно выполнять параллельно этапам 1–5 (справочники, CRUD, UI-компоненты, выгрузки в Excel по уже готовым данным). Перед началом любой задачи Junior должен прочитать onboarding.md и не вносить изменений в правила из раздела 2.