# Проект: Бюджет (личный/семейный финансовый трекер)

Стек: PHP + Bootstrap 5.4 + jQuery + MariaDB, бот на Telegram, ИИ (Claude API) как помощник.

---

## 1. Учёт финансов

### 1.1 Счета
- Кошелёк (наличные)
- Дебетовые карты — % кэшбэка, % по счёту в банке (возможность подтягивать данные с banki.ru или собственный анализатор ставок)
- Кредитные карты — %, льготный период
- Кредиты — %, дата взятия, начальная сумма (см. отдельный раздел 4)
- E-money, счёт в банке
- Инвестиционные инструменты: ПАММ, вклад, акции (см. отдельный раздел 3)

### 1.2 Категории
- Доходы
- Расходы

### 1.3 Транзакции
- Доходы
- Расходы
- Переводы (между своими счетами)

### 1.4 Планирование бюджета
Таблица план/факт по категориям:

| План | Факт | Категория |
|------|------|-----------|
| 1000 | 1200 | Категория 1 |
| 5000 | 4355 | Категория 2 |
| 100  | 100  | Категория 3 |

### 1.5 Семейный бюджет
- Общий или раздельный режим
- Каждый член семьи ведёт свой бюджет в общем кабинете

### 1.6 Модульность
- Клиент платит только за те модули, которые ему нужны (монетизация по модулям)

### 1.7 Период трат
- Подсчёт трат за произвольный период с тегом/названием
- Пример: «анализ трат за отпуск»

---

## 2. Цели
- Добавление / редактирование / удаление целей
- Предварительный расчёт с возможностью сохранить цель в бюджет (зарезервировать сумму)

---

## 3. Инвестиции (отдельный модуль)

### 3.1 План инвестиций
- Процентное соотношение между видами инвестиций
- Предупреждение о разбалансировке портфеля

### 3.2 Профили риска
| Низкий риск | Средний риск | Высокий риск |
|---|---|---|
| Вклады | ПИФ (?) | ПАММ |
| Пенсионный фонд | | Индексы |
| | | Акции |

### 3.3 Готовые стратегии
- **Для новичков:** малый % → вклады
- **Для профи:** малый % → менее рисковое; средний % → ПИФ; высокий % → ПАММ / индексы / акции

### 3.4 Помощник инвестирования (ИИ)
- Анализ рынка
- Поиск оптимального распределения на основании бюджета и выбранной стратегии

---

## 4. Кредиты и кредитные карты

### 4.1 Управление
- Добавление / редактирование / удаление кредита
- Поля: %, дата взятия, дата первого платежа, привязка к счёту (автосписание), штраф за просрочку

### 4.2 Способы выплат
- Стандарт
- Снежный ком (snowball)
- Снежная лавина (avalanche)

### 4.3 Оптимизация
- Анализ всех кредитов и подбор способа выплаты с минимальными затратами (переплатой)

---

## 5. Анализ бюджета

### 5.1 Корректировка бюджета
- Анализ + предложение направить деньги (+/-) на цели

### 5.2 Подушка безопасности
- Отдельный учёт резервного фонда

### 5.3 Визуализация
- Главная страница: графики дохода/расхода, расходов по категориям

### 5.4 ИИ-анализ
- Открытый вопрос — что именно должен анализировать ИИ (см. вопросы ниже)

---

## 6. Финальная схема БД

```sql
users
├── id
├── login          -- уникальный (проверка при регистрации)
├── email          -- уникальный (проверка при регистрации)
├── password
├── date_add
├── date_pay       -- дата оплаты
└── last_login

accounts
├── id
├── user_id        -- FK -> users.id
├── type_acc       -- вид счёта (нал/дебет.карта/кредит.карта/...)
├── title
├── summa
├── is_delete      -- архивация счёта, а не физическое удаление
└── order          -- порядок отображения

categories
├── id
├── user_id        -- FK -> users.id
├── title
├── type           -- вид категории: доход / расход
└── order

transactions
├── id
├── user_id
├── categorie_id   -- FK -> categories.id
├── account_f_id   -- счёт-источник (from)
├── account_in_id  -- счёт-получатель (in), для переводов
├── date
├── summa
└── type           -- вид транзакции: доход / расход / перевод

budgets
├── id
├── categorie_id   -- FK -> categories.id
├── plan_summ      -- план на категорию
├── year
├── month
└── type
```

**Важное архитектурное решение, которое уже принято:** одна таблица `transactions` с полем `type` (доход/расход/перевод) и двумя ссылками на счета (`account_f_id` — откуда, `account_in_id` — куда). Для обычного дохода/расхода используется только одно из полей, для перевода — оба. Это закрывает открытый вопрос "одна таблица или две" из предыдущей версии заметок.

**Архивация вместо удаления:** у счетов есть `is_delete` — счета не удаляются физически (иначе сломается история транзакций), а помечаются как архивные и скрываются из активного списка.

---

## 7. Пошаговый план разработки (Front/Back)

Общая структура интерфейса:
- **Front** (сайт до входа) → лендинг-страница (`info`) с описанием продукта
- **Back** (после входа) → личный кабинет (`ЛК`)

### Шаги реализации
1. **Регистрация** — login/email обязательно уникальны (проверка на дубли), восстановление пароля, вопрос про удаление аккаунта пока открыт ("надо ли???")
2. **Заведение счетов** — нал, дебетовая карта, кредитная карта и т.д.
3. **Заведение категорий** доходов/расходов
4. **Транзакции** — доход/расход/перевод
5. **Бюджет** — таблица план/факт/разница по категориям, по месяцам (структура из раздела 6, таблица `budgets`)
6. **Оплата** — подключение платёжной системы + модульность (клиент платит только за нужные ему модули)

Это, по сути, финальная версия MVP-плана, конкретизирующая раздел 9 — теперь с привязкой к таблицам БД и порядку экранов.

---

## 8. Что нужно проанализировать перед реализацией оплаты
1. Проанализировать сервисы оплаты, как подключить оплату технически
2. Модульность — реализовать так, чтобы клиент платил только за нужные ему модули (архитектурно, не только маркетингово)

---

## 9. Твоя готовность по технологиям (для оценки, сколько доучивать)

| Область | Готовность |
|---|---|
| Основы Web (запрос/ответ, протоколы, методы передачи данных) | 90% |
| PHP и его возможности | 56% |
| MySQL / NoSQL (MongoDB) | 60% |
| База знаний предметной области проекта | 80% |
| Подключение платёжных систем | 0% |
| Ajax, jQuery | 80% |

Судя по цифрам, самое узкое место сейчас — интеграция платёжных систем (0%) и, во вторую очередь, PHP (56%). Логично, что оплата — последний шаг в плане разработки: к моменту, когда до неё дойдёшь, будет время подтянуть тему, а MVP можно собирать и без неё (бесплатная версия с лимитами).

---

## 7. Типы счетов
1. Наличные
2. Дебетовая карта
3. Кредит
4. Депозит
5. Мне должны
6. Долг
7. Кредитная карта
8. Банковский счёт
9. Электронные деньги

Общий признак для всех — **нал / безнал**.

Поля по типу счёта:
| Тип | Поля |
|---|---|
| Дебетовая карта | сумма, остаток, %, cashback, sms-банк |
| Кредитная карта | сумма, %, штраф, льготный период |
| Счёт в банке | сумма |
| Кредит | сумма, %, срок, сумма платежа |
| Вклад (инвестирование) | сумма, %, куда (вклад/карта), период |
| ПАММ | сумма, % |

---

## 8. Что пользователь хочет видеть о деньгах (UX/аналитика)
- Остаток
- На что трачу
- Перерасход по категориям
- Остаток по категориям
- Остаток по кредиту
- Инфо о целях
- Инфо о вкладах/инвестициях

Всё это — с возможностью включить/выключить в настройках (не перегружать интерфейс).

**Графики на главной:**
- Доходы/расходы во времени (линейный график, сравнение двух линий)
- Динамика количества денег (общий баланс во времени)

---

## 9. MVP — минимум, чтобы проект заработал

1. Регистрация пользователя и его последующие настройки
2. Заведение и редактирование счетов
3. Заведение и редактирование категорий доход/расход
4. Транзакции: доход, расход, перевод
5. Составление и редактирование бюджета
6. Разделение на бесплатную версию (с ограничениями) и платную (без ограничений)

### Лимиты бесплатной версии
| Параметр | Лимит |
|---|---|
| Валюта | 1 |
| Счета | 2 |
| Категории дохода | 2 |
| Категории расхода | 5 |
| Транзакции | без ограничений |
| Составление бюджета | на год |
| Импорт данных | есть (+) |
| Экспорт данных | нет (−) |

Платная версия снимает эти ограничения (сколько угодно счетов/категорий/валют + экспорт).

---

## 10. Открытые вопросы из заметок (нерешённые, требуют ответа до/во время разработки)

1. Создавать категории сразу с планированием в таблице, или бюджет отдельно?
2. Ставить ограничение «трата > дохода» — предупреждать пользователя? Как это должно работать?
3. Делать ли годовую отчётность? Делать ли усреднение по месяцам?
4. Какую ещё статистику можно делать (кроме уже перечисленной)?
5. Как сделать ведение бюджета удобным для пользователя (UX)?
6. Куда «откладывать» цели — делать ли для них что-то вроде отдельного счёта? Как пользователь будет физически хранить деньги на цель?
7. Делать ли привязку цели к конкретному счёту?
8. От куда и куда переходят деньги при использовании цели, как это учитывается в транзакциях?
9. Можно ли редактировать транзакции после того, как месяц уже прошёл (задним числом)?
10. Как лучше построить схему/таблицу доходов-расходов (план/факт/разница по месяцам)?
11. Как лучше сделать переход бюджета на следующий год?
12. Как вести статистику в течение года — по каждой категории с периодом или без периода?
13. Выводить бюджет помесячно или сразу на весь год?
14. Общий или раздельный бюджет для семьи — как разграничить видимость (реализация).
15. Модульность — как технически ограничивать доступ (флаги в БД/подписка).

---

## 11. Более общие вопросы (из первой части заметок)

1. ~~Какие модули входят в MVP~~ — уже определено в разделе 9.
2. ~~Модульность: как технически ограничивать доступ~~ — уже частично отвечено (бесплатный/платный тариф, раздел 9), но сам механизм проверки прав ещё не спроектирован.
3. Семейный бюджет: как разграничивать видимость чужих трат при "раздельном" режиме?
4. Интеграция с banki.ru или сбор ставок — вручную, парсинг или ручной ввод пользователем?
5. ИИ-помощник — на каких данных он строит рекомендации по бюджету и инвестициям (только внутренние транзакции, или + внешние рыночные данные)?
6. Монетизация — разовая оплата модуля, подписка, freemium? (Раздел 9 намекает на freemium-модель.)

---

## Рекомендация по приоритету (MVP)

Судя по заметкам, ядро без которого остальное не имеет смысла:
1. Счета + категории + транзакции (1.1–1.3)
2. Планирование бюджета план/факт (1.4)
3. Базовая аналитика/графики (5.3)
4. Telegram-бот для быстрого ввода трат

Всё остальное (инвестиции, кредиты с оптимизацией, ИИ-советник, модульность/монетизация) — логичные модули фазы 2+, они опираются на данные, накопленные в ядре.