Обзор системы CRM RMS
CRM RMS — это проектная CRM/RMS-платформа: она связывает клиентов, проекты, команды, задачи, оборудование, логистику, финансы, документы и коммуникации в один рабочий контур.
Общая схема
В текущей версии backend состоит из доменных модулей под internal/modules/*, HTTP API под /api/v1 и VitePress-документации под docs/.
Основной рабочий маршрут:
Администратор: "Настраиваю пользователей, отделы, роли и должности"
↓
Менеджер: "Создаю компанию, контакт и проект"
↓
Система: "Проект в planned, доступы считаются по отделу, менеджеру и ролям"
↓
Менеджер: "Готовлю спецификацию, команду и смету"
↓
Команда: "Работает по задачам, пишет время, общается в чатах"
↓
Логистика: "Подбирает оборудование, строит маршруты и согласует суммы"
↓
Бухгалтерия/финансы: "Ведут cost items, платежи, отчеты и payroll"
↓
Юристы/документы: "Готовят договоры, счета, акты и контролируют сроки"
↓
Менеджер: "Сверяет бюджет, закрывает проект и архивирует историю"Как читать документацию
Если вы новый разработчик
- Основные сущности — карта данных и связей.
- Жизненный цикл проекта — актуальные статусы проекта, задач и закрытия.
- Архитектура — слойность backend и правило обновления docs.
- Security & RBAC — доступы, роли, оргструктура и видимость.
- Матрица прав RMS — 16 объектов × 11 ролей, охваты «все / свой / нет», как сужаются списки и вырезаются поля.
- Scalar API Reference — точные endpoint-ы, параметры и схемы.
Если вы делаете фронт
- Клиенты и контакты — CRM-карточки и связи.
- Оргструктура и админский UI — пользователи, отделы, должности, роли.
- Матрица прав RMS — что показывать и скрывать по
permissionsиз/org/me. - Соглашение о неразглашении (NDA) — блокирующий экран при первом входе и код
nda_not_accepted. - Табели — свой табель, сдача, сводный список и утверждение.
- Глобальный поиск — единая поисковая страница.
- Система чатов — список чатов, сообщения, реакции, файлы, WebSocket.
- Система уведомлений — notification center, badge, email outbox.
- Дашборд руководства — блоки главной, права на каждый блок, динамика бюджета проекта.
- Финансовые ворота — «без ТЗ нет денег», «без расходов нет оплаты», мини-ТЗ, история сделок поставщика.
- Смета из ТЗ — блоки, часы, ставки отделов, резерв на риски, перенос в бюджет и отчёт о незапланированных работах.
Если вы работаете с операционным контуром
- Логистический контур — заявки на оборудование и логистические операции.
- Заявки на оборудование: роли — кто принимает решения в equipment request workflow.
- Командировки — статусы, задачи вокруг поездки и финансовая интеграция.
- Управление командой — проектные роли, ставки, team requests.
Если вы работаете с финансами и документами
- Система бюджета и сметы — Finance -> Budget -> Documents.
- Деньги, округление и НДС —
money.Money, точность и НДС. - Касса, платежи и взаиморасчеты — accounts, payments, reconciliation, reports.
- Юридический реестр договоров — contracts, deadlines, legal card.
- Реестр обязательств — обязательства, постоянные платежи, статусы по срокам и эскалация.
- Зарплата — compensation profiles и payroll runs.
- Система документов — files, generated documents и templates.
Доменные контуры
CRM и проекты
companies,contacts,companycontacts,requisites,entitylinks— клиентская база и связи.projects,projectteam,teamrequests— проект, команда и заявки на ресурс.tasks,timeentries— задачи, рабочие сессии и учет времени.timesheets— табели: месяц сотрудника, сдача и утверждение поверхtime_entries.search— глобальный поиск по рабочим сущностям.
Операции
locations,equipment,suppliers— склады, площадки, оборудование и поставщики.equipmentrequests,logistics— фасад заявок и реальные логистические операции.trips— командировки и попутные задачи.
Финансы, бухгалтерия и юристы
finance,budget— cost items, выручка, P&L и смета.payments— счета/кассы, платежи, взаиморасчеты, ДДС, дебиторка, НДС-регистр.contracts— юридический реестр договоров, сроки и legal card.payroll— условия оплаты и зарплатные ведомости.obligations— реестр обязательств и постоянные платежи финотдела.
Контент и коммуникации
files,documents— загруженные файлы, папки, шаблоны и generated documents.chats,notifications— чаты, WebSocket, notification center и email delivery worker.
Организация и доступы
auth,users,rbac— аутентификация, профили, роли и permissions.departments,org,directory— отделы, должности, руководители и справочники.permissions(internal/permissions) — матрица прав RMS, разрешаемая по ролям пользователя.nda— версии соглашения о неразглашении, журнал принятия и серверный гейт.
Где проверять точность
Концептуальные страницы объясняют бизнес-процессы, но не являются ручным API reference.
| Вопрос | Источник |
|---|---|
| Какие endpoint-ы реально есть | Scalar API Reference и docs/assets/data/endpoints.json |
| Какие DTO принимает backend | internal/modules/*/transport_http.go |
| Какие статусы валидны | model.go, status.go, service validation |
| Какие права нужны | internal/permissions/matrix.go, internal/app/app.go, internal/modules/rbac, Матрица прав RMS, docs/rbac_matrix.md |
| Как устроена БД | migrations/*.sql |
После изменений API нужно регенерировать:
bash
go run ./cmd/generate_contracts
go run ./cmd/generate_endpointsКлючевые правила
1. Документация должна идти от реального кода
Не используйте старые статусы или endpoint-ы, если их нет в transport_http.go и OpenAPI.
2. Концепции объясняют процесс, Scalar фиксирует контракт
В markdown показываем смысл, роли, этапы, ошибки и frontend-поведение. Полные схемы JSON держим в Scalar.
3. API меняется вместе с документацией
Если задача меняет маршруты, DTO, права, валидацию, бизнес-поведение или БД, обновляются и VitePress, и сгенерированные OpenAPI/endpoints artifacts.