UC-OVR-006. Сделка: от брони до регистрации (инвестор-инициатор)

Назначение

Под-воронка «UC Сделка» (матрица, 9 этапов, инвестор-инициатор): от подтверждённой брони объекта до завершения сделки и регистрации. Оркеструет crm/booking и crm/deal, синхронизирует статус объекта с chessboard. Продолжает UC-OVR-003 и является фазами 6–8 сквозной воронки UC-OVR-004. Платёжная интеграция (эквайринг) — отложена (структуры оплат проектируются).

Metadata

Поле	Значение
Статус	`draft`
Owning team	`crm`
Primary capability	`booking-to-deal-registration`
Risk level	`high`

Scope И Участники

Участник	Роль
Инвестор	Оплачивает бронь, загружает документы/паспорт, вводит эскроу
Агент / Менеджер застройщика	Ведут сделку по этапам, запрашивают документы
`crm/booking`	Бронь: подтверждение, оплата, истечение
`crm/deal`	Сделка: канбан-этапы, документы, эскроу, завершение
`chessboard`	Статус объекта (Бронь → Продан)
`notifications` / `messenger`	Уведомления и системные карточки в чате сделки

Preconditions

Есть подтверждённая бронь объекта (UC-BKG-002) и созданная сделка (UC-OVR-005).
У застройщика настроены этапы воронки и требования к документам.

Основной Сценарий

Оплата брони. Инвестор оплачивает бронь (чек прикрепляется); менеджер подтверждает (UC-BKG-004) → pin.crm.booking-paid.v1.
Конвертация. Бронь конвертируется в активную сделку; объект удерживается в «Бронь» (chessboard).
Документы. Застройщик запрашивает документы (document-requested); инвестор загружает паспорт/сканы, статусы документов меняются (document-status-changed); системные карточки — в чат сделки (messenger).
Этапы. Сделка двигается по канбану (UC-CRM-003) → pin.crm.deal-stage-changed.v1.
Эскроу. Инвестор указывает номер эскроу-счёта (маска ****NNNN); таймлайн-событие EscrowProvided.
Регистрация. Договор регистрируется; сделка достигает финального этапа.
Завершение. Сделка завершается (UC-CRM-005) → pin.crm.deal-completed.v1; chessboard переводит объект в «Продан»; далее — портфель собственника (UC-OVR-004, шаг 9).

Sequence

Постусловие

После успешного завершения гарантированно:

Booking оплачена и подтверждена; опубликовано pin.crm.booking-paid.v1; бронь конвертирована в активную сделку, объект удерживается в «Бронь» до завершения;
Deal прошёл требуемые канбан-этапы (deal-stage-changed на каждом переходе), документы приняты (статусная машина DealDocument), эскроу зафиксирован (Sensitive, хранится под маской ****NNNN);
сделка достигла Completed (guard: договоры → эскроу(Ddu) → Росреестр → завершение); опубликовано pin.crm.deal-completed.v1 — ровно один раз;
chessboard перевёл объект в «Продан»; далее объект попадает в портфель собственника (UC-OVR-004, шаг 9).

Промежуточные состояния для пользователя: объект «Бронь» весь период ведения сделки; системные карточки этапов/запросов документов появляются в чате сделки; статус «Продан» виден после обработки deal-completed контекстом chessboard (< 1 мин).

Альтернативные Сценарии И Отказы

Ситуация	Поведение
Бронь не оплачена в срок	`pin.crm.booking-expired.v1` → объект «Свободен» (UC-BKG-003); сделка не конвертируется
Документ отклонён	Статус документа «Отклонён»; запрашивается повторно (возврат к шагу 3); этап не двигается вперёд
Попытка завершить сделку до Росреестра/эскроу	Отклоняется guard-порядком этапов (INV-DEAL-7); `deal-completed` не публикуется
Повторное завершение уже завершённой сделки	`CRM_DEAL_ALREADY_TERMINAL`; события нет (терминал неизменяем, INV-DEAL-9)
Сделка отменена на этапе	`deal-cancelled`; объект возвращается в «Свободен»; `deal-completed` не публикуется
`deal-completed` доставлен `chessboard` повторно	Идемпотентно (first-seen по `DealId`) — «Продан» не применяется дважды
Инвестор-инициатор vs агент-инициатор	Единый flow; отличие — кто создаёт бронь/сделку (двойная точка входа)

Согласованность И Идемпотентность

Саги для многошаговости и компенсации. Резерв → Бронь → передача в продажу и fan-out завершения сделки координируются сагами (booking-saga, deal-completion-saga); при отказе на шаге публикуется компенсирующее/терминальное событие, а не откат чужих зафиксированных фактов.
Порядок жизни сделки гарантирован ключом DealId (стадии, оплата, завершение — на одной партиции); chessboard/messenger/notifications дедуплицируют по MessageId, статус — first-seen по DealId.
Guard-порядок этапов. Завершение допускается только после договоров/эскроу(Ddu)/Росреестра (INV-DEAL-7); deal-completed терминален и публикуется один раз (INV-DEAL-9).
Sensitive-данные. Эскроу-счёт и паспортные сканы — Sensitive; в события/логи/таймлайн не попадают (маска ****NNNN), consumer-ы deal-completed получают только IDs + FinalPrice.
Окно eventual-consistency. Статус «Продан» и запись в портфель материализуются после обработки события (< 1 мин для статуса, < 5 мин для портфеля/уведомлений).

Acceptance Criteria (Given/When/Then)

Happy (бронь → регистрация). Дано: подтверждённая бронь и созданная сделка, у застройщика настроены этапы и требования к документам. Когда: инвестор оплачивает бронь, загружает документы, вводит эскроу; менеджер ведёт сделку до Росреестра и завершает. Тогда: booking-paid, deal-stage-changed, deal-completed опубликованы; объект переведён в «Продан».
Бронь не оплачена. Дано: бронь ждёт оплаты. Когда: истёк срок. Тогда: booking-expired, объект «Свободен», сделка не конвертируется.
Завершение до Росреестра. Дано: сделка без подтверждённой регистрации. Когда: попытка завершить. Тогда: отклонение guard-порядком, deal-completed не публикуется.
Повторное завершение. Дано: сделка уже Completed. Когда: повтор завершения. Тогда: CRM_DEAL_ALREADY_TERMINAL, события нет.
Отмена сделки. Дано: сделка в работе. Когда: сделка отменяется. Тогда: deal-cancelled, объект «Свободен», deal-completed не публикуется.
Приватность. Дано: инвестор ввёл эскроу и загрузил паспорт. Когда: события/логи формируются. Тогда: номер счёта под маской, PII не в логах/таймлайне/событиях.

Source Of Truth И Данные

Данные	Владелец	Consistency rule
`Booking` / таймеры	`crm/booking`	Таймеры — параметры программы; истечение событием
`Deal` / `DealDocument` / эскроу	`crm/deal`	Эскроу — Sensitive (маска); документы — статусная машина
Статус объекта	`chessboard`	Бронь → Продан только по событиям crm

Контракты И Зависимости

API: confirm-booking-payment, move-deal-step.md.
Events: booking-paid.md, deal-stage-changed.md, deal-completed.md, document-requested.md.
UC сервисов: UC-BKG-004, UC-CRM-003, UC-CRM-005.
Sagas (кросс-сервисная координация + компенсация): booking-saga (Резерв → Бронь → передача в продажу), deal-completion-saga (fan-out завершения сделки).
ADR: 0055 own-mini-messenger.

Наблюдаемость

critical metrics: конверсия бронь→сделка→завершено; time-in-stage; доля отклонённых документов.
trace path: crm (booking → deal) → шина событий → chessboard/messenger/notifications.
alerts: сделки, застрявшие на этапе; рассинхрон статуса объекта.

Риски И Guardrails

Риск: утечка эскроу/паспортных данных. Control: Sensitive-поля с маской, PII не в логах/таймлайн.
Риск: объект «завис» в «Бронь». Control: истечение брони событием; сверка crm↔chessboard.

Обратные ссылки

Автоссылки: где используется этот документ.

Назначение​

Metadata​

Scope И Участники​

Preconditions​

Основной Сценарий​

Sequence​

Постусловие​

Альтернативные Сценарии И Отказы​

Согласованность И Идемпотентность​

Acceptance Criteria (Given/When/Then)​

Source Of Truth И Данные​

Контракты И Зависимости​

Наблюдаемость​

Риски И Guardrails​

Обратные ссылки​