Здесь собрано сравнение текущего рабочего проекта и прототипа новой админки, чтобы было понятно, что уже есть, что хотят сделать и где главные отличия.
Текущий проект (как сейчас в работе)
Что это: backend для личного кабинета клиента и обработки платежей
Главное: клиент регистрируется → создаёт компанию → оформляет контракт → платит → всё идёт через Telegram с менеджером
Центр системы: три связанные сущности — «Операция» (контракт), «Платёж по операции», «Процесс в Telegram» (OperationProcess)
Telegram: реально работает — бот, чаты, топики, кнопки
Документы: хранятся в разных местах (паспорт, договор, счёт и т.д.)
Личный кабинет: есть API, через него клиент всё делает
Проще говоря: контракт — это Operation, платёж — OperationPayment, обработка в Telegram — отдельно OperationProcess. Но отдельной сущности «Договор» (Contract) как в прототипе — нет.
Прототип новой админки (ADMIN_MOM_2)
Что это: макет, как должна выглядеть админка «по-новому»
Главное: Клиент → Компания → Договор → Платёж — всё разложено по полочкам
Документы: одна общая таблица на всё
Telegram: только записи в базе, бота нет
Личный кабинет: API нет, только страницы админки
Контейнеры и учёт: там много, но это отдельный этап (пока не трогаем)
Это образец интерфейса и логики, а не готовый проект для продакшена.
Куда хотим прийти (по ТЗ)
Взять удобный формат из прототипа, но не сломать текущий личный кабинет
Разложить код по разделам: клиенты, договоры, документы, Telegram, справочники
Telegram не переписывать с нуля — доработать то, что уже работает
Этап 1: клиенты, компании, контрагенты, договоры, платежи, документы
Этап 2: контейнеры сделок и бухучёт (позже)
Главное, что нужно запомнить
Сейчас три таблицы: Operation = контракт, OperationPayment = платёж, OperationProcess = процесс в TG (отдельно). В прототипе — Contract + Payment, без OperationProcess.
«Контрагент» сейчас и клиент, и получатель — в новой схеме это лучше разделить.
Документов много разных таблиц — в прототипе одна. Нужно аккуратно свести, не потеряв файлы.
Статусов платежа 9 в текущем и 12 в прототипе — надо договориться с бизнесом, какие оставить.
Telegram в текущем проекте рабочий — его сохраняем и только подстраиваем под новую админку.
Раскройте блок — увидите по шагам, как устроен процесс в текущем проекте и чем отличается прототип.
Каждая карточка — одна «вещь» в системе. Внутри: как устроено сейчас, что в прототипе, конкретно что меняется, что не трогаем.
Таблица редактируемая: правьте ячейки, добавляйте и удаляйте строки. Сохранение — автоматически через 1,5 сек.
Сравнение по полям моделей prod и прототипа. Блок = сущность или таблица. Поле = конкретное имя в коде (Model.field). Блоки идут в логическом порядке сделки.
Открытые вопросы по схеме