# ТЗ на `hub.bent.ge`

Дата: 16 марта 2026  
Версия: draft 0.2

## 1. Идея продукта

`hub.bent.ge` — новая внутренняя платформа для управления бизнесом бронирований, автопарком, клиентами, ценами, документами, заявками и публичными процессами.

Это не перенос старой базы "как есть".  
Это новый продукт с новой, более правильной и гибкой моделью.

## 2. Цель

Система должна стать единым центром управления для команды и закрыть:

- операционную работу с бронированиями;
- CRM и клиентскую историю;
- управление автопарком;
- pricing и availability;
- документы, подписи и оплаты;
- заявки и публичные формы;
- отчёты, аудит и права доступа;
- единый API для публичного сайта и внутренних интерфейсов.

## 3. Ключевые принципы новой системы

- Новая система не должна повторять старую структуру БД.
- Доменная модель должна строиться от бизнес-сущностей, а не от legacy-таблиц.
- Все справочники и статусы должны быть максимально настраиваемыми.
- Бизнес-логика должна быть единой для backoffice и публичных сценариев.
- Права доступа, аудит и журнал изменений должны быть встроены в основу системы.
- Система должна быть готова к росту: новые каналы, новые типы бронирований, новые интеграции.
- Важные сценарии не должны быть "зашиты" в хаотичные endpoint-ы или ad-hoc правила.

## 4. Технологические замечания

Технологический стек на этом этапе не фиксируется окончательно.

Предварительное направление:

- frontend: `React` или `Vue`;
- backend: `Laravel`.

Выбор стека будет обсуждаться отдельно.  
Это ТЗ описывает продукт и требования, а не финальную реализацию.

## 5. Границы продукта

### Входит в `hub.bent.ge`

- внутренняя операционная панель;
- backend/API;
- модуль бронирований;
- клиенты и CRM;
- машины и автопарк;
- locations и delivery points;
- pricing engine;
- документы;
- подписи;
- платежные сценарии;
- лиды и формы;
- контент и служебные публичные данные;
- права доступа;
- аудит;
- отчёты;
- импорт и миграция данных из старой системы.

### Не является целью первого этапа

- полная замена публичного маркетингового сайта;
- AI как обязательная часть продукта;
- бухгалтерия полного цикла;
- мобильное приложение;
- сложный маркетинг automation.

## 6. Основные роли

Система должна поддерживать как минимум:

- `Admin`
- `Operator`
- `Manager`
- `Agent`
- `Content manager`
- `Finance`
- `Public client`

### Требование к ролям

Роли должны быть:

- настраиваемыми;
- расширяемыми;
- независимыми от жёстко прошитых правил интерфейса;
- привязанными к разрешениям, а не только к названию роли.

## 7. Права доступа

Права должны работать на нескольких уровнях:

- модуль;
- сущность;
- действие;
- чувствительные поля;
- специальные бизнес-действия.

Минимальный набор действий:

- `read`
- `create`
- `update`
- `delete`
- `export`
- `approve`
- `cancel`
- `manage_payment`
- `manage_documents`

Система должна позволять:

- задавать политики по ролям;
- задавать исключения для конкретных пользователей;
- скрывать модули и действия из интерфейса;
- вести аудит изменений прав.

## 8. Продуктовые модули

### 8.1. Dashboard

Главный экран должен показывать:

- ключевые операционные метрики;
- список ближайших событий;
- проблемные бронирования;
- задачи и напоминания;
- быстрые действия;
- активность команды;
- предупреждения по оплатам, документам и изменениям.

### 8.2. Бронирования

Ключевой модуль системы.

Должен поддерживать:

- список бронирований;
- карточку бронирования;
- создание;
- редактирование;
- отмену;
- перевод по статусам;
- назначение ответственного;
- историю изменений;
- поиск и фильтрацию;
- группировки и представления;
- timeline / calendar view;
- быстрые действия из карточки.

Бронирование должно быть самостоятельной сущностью с понятным жизненным циклом.

### 8.3. Гибкая модель статусов и сценариев

Статусы не должны быть жёстко зашиты в код как неизменяемый набор.

Нужно поддержать:

- настраиваемый справочник статусов;
- принадлежность статуса к этапу workflow;
- цвет, тип и поведение статуса;
- разрешённые переходы между статусами;
- системные статусы и пользовательские статусы;
- отдельные правила для разных типов бронирований.

### 8.4. Типы бронирований и сервисов

Система должна позволять работать не только с классической арендой, но и с другими типами услуг.

Модель должна поддерживать:

- тип бронирования;
- сервис/направление;
- канал поступления;
- источник;
- партнёрский канал;
- кастомные атрибуты на уровне типа услуги.

Типы услуг должны быть конфигурируемыми, а не прошитыми жёстко.

### 8.5. Клиенты и CRM

Система должна содержать полноценный клиентский модуль:

- список клиентов;
- карточка клиента;
- контакты;
- документы;
- история бронирований;
- история коммуникаций;
- история изменений;
- заметки команды;
- сегментация;
- поиск дублей;
- объединение дублей;
- ручная проверка конфликтов данных.

### 8.6. Автопарк

Модуль автопарка должен поддерживать:

- список машин;
- модели;
- категории;
- типы кузова;
- коробки передач;
- топливо;
- страховки;
- принадлежность к provider/owner;
- VIN / регистрационные данные;
- состояние автомобиля;
- доступность;
- статусы машины;
- медиа;
- история привязки к бронированиям.

### 8.7. Locations

Система должна иметь единый модуль locations:

- города;
- офисы;
- аэропорты;
- delivery points;
- pickup/dropoff правила;
- активность точки;
- контакты;
- часы работы;
- геоданные;
- зоны обслуживания;
- текстовые ключи для поиска.

Locations должны использоваться единообразно во всех сценариях:

- booking;
- pricing;
- availability;
- сайт;
- документы;
- отчёты.

### 8.8. Pricing engine

Один из центральных модулей.

Система должна поддерживать:

- базовые тарифы;
- правила по периодам;
- правила по длительности;
- правила по location;
- rules для extras;
- скидки и promo;
- сезонность;
- курсы валют;
- prepayment rules;
- deposit rules;
- партнёрские комиссии;
- breakdown итоговой цены.

### 8.9. Extras и дополнительные услуги

Extras должны быть отдельным конфигурируемым каталогом.

Для каждого extra должны поддерживаться:

- название;
- код;
- описание;
- иконка;
- тип применения;
- логика тарификации;
- правила совместимости;
- правила обязательности;
- видимость в разных каналах;
- доступность по location / category / model / service.

### 8.10. Availability engine

Проверка доступности должна быть отдельной бизнес-функцией.

Она должна:

- одинаково работать для backoffice и публичного сайта;
- учитывать даты и время;
- учитывать статус брони;
- учитывать резервирование машины;
- учитывать service type;
- учитывать location restrictions;
- уметь объяснять причину недоступности.

### 8.11. Документы

Нужен отдельный модуль документов:

- шаблоны документов;
- генерация PDF;
- привязка к бронированию и клиенту;
- хранение версий;
- публичные ссылки;
- внутренний доступ;
- контроль обязательных документов;
- история генерации и отправки.

### 8.12. Подписи

Нужно поддержать:

- внутреннюю подпись;
- публичную подпись клиентом;
- привязку подписи к конкретному документу/броне;
- проверку доступа к подписанию;
- аудит времени и канала подписания.

### 8.13. Платежи

Платежный модуль должен поддерживать:

- расчёт суммы к оплате;
- prepayment;
- full payment;
- payment link generation;
- хранение статуса платежа;
- callback/webhook handling;
- повторную проверку статуса;
- ручное подтверждение при необходимости;
- историю платёжных событий;
- возможность подключать разных платёжных провайдеров.

Платежный модуль должен быть расширяемым и не зависеть от одного конкретного провайдера.

### 8.14. Лиды и формы

Все входящие заявки должны попадать в единый модуль лидов.

Система должна поддерживать:

- request forms;
- contact forms;
- callback requests;
- custom request types;
- квалификацию лида;
- назначение ответственного;
- привязку к клиенту;
- превращение лида в бронирование;
- этапы обработки;
- внутренние комментарии;
- источники и каналы.

### 8.15. Контент и служебная CMS

Нужен управляемый модуль контента для служебных и публичных данных:

- статьи;
- FAQ;
- справочный контент;
- SEO-страницы;
- промо-блоки;
- тексты для публичных сценариев;
- локализуемый контент;
- media assets.

Контентный слой должен быть отдельным модулем, а не побочным эффектом админки.

### 8.16. Задачи и workflow

Нужно предусмотреть модуль задач/kanban или эквивалентный workflow-инструмент.

Он должен поддерживать:

- колонки/этапы;
- карточки;
- due dates;
- ответственных;
- связи с бронями, клиентами, машинами;
- комментарии;
- drag-and-drop;
- быстрые действия;
- уведомления.

### 8.17. Отчёты и аналитика

Система должна поддерживать:

- операционные отчёты;
- финансовые отчёты;
- отчёты по загрузке машин;
- отчёты по статусам;
- отчёты по каналам;
- отчёты по источникам заявок;
- отчёты по сотрудникам;
- отчёты по изменениям и отменам;
- экспорт данных.

## 9. Основные сценарии

### 9.1. Backoffice booking flow

Оператор должен иметь возможность:

- найти клиента или создать нового;
- выбрать машину;
- проверить доступность;
- применить pricing;
- добавить extras;
- определить prepayment/deposit;
- сгенерировать документы;
- отправить клиенту ссылку;
- контролировать статус до завершения брони.

### 9.2. Public booking flow

Публичный сценарий должен поддерживать:

- поиск;
- выбор оффера;
- выбор extras;
- ввод данных клиента;
- создание бронирования;
- оплату;
- получение документов;
- дальнейшее управление бронированием.

### 9.3. Manage booking flow

Клиент должен иметь ограниченный безопасный доступ к:

- просмотру своей брони;
- запросу изменения параметров;
- запросу отмены;
- загрузке/проверке документов;
- оплате;
- подписанию документов.

Изменения со стороны клиента не должны бесконтрольно переписывать бронирование.

### 9.4. Lead to booking flow

Система должна позволять:

- принимать входящий лид;
- квалифицировать его;
- связывать с клиентом;
- конвертировать в бронирование;
- сохранять весь контекст.

## 10. Настраиваемость системы

Новая система должна быть гибкой.

В настройках должны управляться:

- роли и политики;
- статусы и переходы;
- типы сервисов;
- каналы и источники;
- marketplaces;
- providers;
- locations;
- vehicle categories;
- extras;
- pricing rules;
- discount rules;
- payment providers;
- document templates;
- публичные тексты и шаблоны сообщений;
- причины отмен и служебные справочники.

## 11. Что важно не делать

- Не строить модель по старым таблицам.
- Не тащить старые названия сущностей как основу новой архитектуры.
- Не делать generic CRUD вместо нормальных модулей.
- Не смешивать backoffice, CMS, pricing и public API в один хаотичный слой.
- Не завязывать бизнес-правила на UI.
- Не хранить критическую логику в ad-hoc endpoint-ах.

## 12. Архитектурные требования

Система должна быть:

- модульной;
- API-first;
- audit-friendly;
- role-aware;
- testable;
- расширяемой;
- пригодной для интеграций;
- пригодной для постепенной миграции.

Нужно разделить:

- доменную логику;
- API-слой;
- внутренний интерфейс;
- публичный интерфейс;
- интеграционный слой;
- storage/files;
- jobs/notifications.

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

- Предсказуемая производительность на списках и поиске.
- Защищённый доступ к данным и файлам.
- Полный audit trail по критическим действиям.
- История изменений ключевых сущностей.
- Поддержка фоновых задач.
- Удобный экспорт.
- Возможность постепенного развития без переписывания основы.
- Поддержка локализации.
- Поддержка тестирования core-логики.

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

Система должна быть готова к интеграциям с:

- публичным сайтом;
- платёжными провайдерами;
- маркетплейсами;
- каналами уведомлений;
- email;
- SMS;
- messenger-каналами;
- внешними import/export источниками.

Интеграции должны быть реализованы через отдельный слой, а не через размазанную логику по модулям.

## 15. Миграция со старой системы

Миграция должна рассматриваться как перенос данных и сценариев, но не как копирование старой структуры.

Нужно:

- выделить целевую новую модель;
- составить mapping legacy → new;
- очистить дубли и мусор;
- перенести только нужные данные;
- сохранить историю там, где она имеет реальную ценность;
- иметь повторяемый процесс миграции;
- иметь отчёт по качеству миграции.

## 16. MVP

### В MVP обязательно должны войти

- auth и роли;
- права доступа;
- bookings;
- clients;
- vehicles;
- locations;
- pricing engine;
- availability engine;
- extras;
- documents;
- signatures;
- payments;
- leads;
- dashboard;
- audit log;
- public API для ключевых сценариев.

### Может быть перенесено на следующий этап

- расширенная CMS;
- сложные отчёты;
- продвинутый workflow;
- расширенные интеграции;
- automation;
- AI.

## 17. Открытые решения на следующий этап

Отдельно позже нужно согласовать:

- React или Vue для frontend;
- структуру frontend-приложений;
- Laravel-архитектуру backend;
- формат API;
- storage strategy;
- notification strategy;
- deployment model;
- финальную схему модулей и bounded contexts.

## 18. Результат, который нужен

На выходе `hub.bent.ge` должен быть:

- новой системой, а не обновлённой копией старой;
- единым центром управления;
- более гибким и масштабируемым продуктом;
- нормальной платформой для дальнейшего роста бизнеса.