Продажи и типы продаж (Order-centric исполнение)

Раздел описывает продажаы, типы продаж, связь с продуктами, версионирование и отказоустойчивость (DLQ).

---

Продажа создаётся из сделки

Когда сделка доходит до стадии «клиент согласен» — менеджер создаёт продажа(ы). Тип продажи определяется продуктом.

Тип продажи (Order Type)

Тип продажи — конфигурируемый шаблон процесса оформления:

Тип продажи содержит:
├── Название
├── Кастомные поля (конструктор форм)
│   ├── Тип: текст / число / дата / выбор / файл / чекбокс
│   ├── Обязательность
│   ├── Значение по умолчанию
│   └── Валидация
├── Этапы оформления (статусная модель)
│   ├── Название этапа
│   ├── Условия перехода
│   └── Действия при переходе
├── Шаблоны документов (с переменными для подстановки)
├── Финальное действие (webhook / email / задача / ничего)
│   └── Обработка ошибок — индивидуально для каждого шаблона
└── Версия схемы (schema_version)

Связь: Продукт → Тип продажи → Продажа

Продукт «ЗП Премиум»
  └── Тип продажи = «Зарплатный проект»

Сделка «Банк Ромашка» (стадия: согласовано)
  └── «Создать продажа» → система видит продукт → подставляет тип продажи
      → динамическая форма с полями этого типа

Одна сделка — несколько продаж

Сделка «Банк Ромашка — комплекс услуг»
├── Продажа #1: Зарплатный проект (тип: ЗП) → свои поля, этапы, webhook
└── Продажа #2: РКО (тип: РКО) → свои поля, этапы, webhook

Каждый продажа независим: свой статус, свой ответственный.

Канбан для продаж

Продажи тоже можно просматривать как канбан-доску по этапам (аналогично сделкам по стадиям воронки). Включается в настройках модуля Продажи.

/p/:pid/orders         → список продаж (по умолчанию)
/p/:pid/orders/kanban  → канбан по этапам (опционально)

Снимок контактных данных (Drift Detection)

Для продаж drift detection критически важен: данные контакта и компании подставляются в шаблоны документов и финальные действия (webhook). Если реквизиты изменились после создания продажи — это может привести к ошибкам в документах.

Поведение для продаж:
  ├── При создании продажи: снимок контакта и компании фиксируется
  ├── При изменении данных контакта/компании:
  │   ├── В карточке продажи: ⚠ «Реквизиты компании изменены»
  │   ├── При генерации документа: предупреждение перед генерацией
  │   │   «Реквизиты компании изменились с момента создания продажи.
  │   │    Проверьте данные перед генерацией документа.»
  │   └── При финальном действии (webhook): предупреждение
  └── Действие: «Принять изменения» → снимок обновляется

Подробное описание механизма — в разделе Контакты и компании → Drift Detection.

---

Версионирование типов продаж

Типы продаж версионируются для обратной совместимости:

OrderType хранит schema_version.
Каждый Order хранит order_type_version (на момент создания).
Новые обязательные поля применяются только к новым продажим.
Для старых — поле nullable или со значением по умолчанию.

Детальная стратегия версионирования будет проработана отдельно
с учётом всех сценариев работы с версиями шаблонов.

Отказоустойчивость финальных действий (DLQ)

Финальные действия продаж (webhook, email) могут завершиться ошибкой (внешняя система недоступна, таймаут, 5xx, невалидные данные).

Механизм Dead-Letter Queue (DLQ):
  ├── При ошибке финального действия:
  │   ├── Retry policy (настраивается per Order Type)
  │   │   ├── Количество повторов
  │   │   ├── Интервал (экспоненциальная задержка)
  │   │   └── Максимальное время ожидания
  │   ├── После исчерпания попыток → статус «Ошибка отправки»
  │   │   ├── Продажа помечен на канбане (визуально выделен)
  │   │   ├── Уведомление ответственному менеджеру
  │   │   └── Кнопка «Повторить отправку» (Manager+)
  │   └── Логирование: каждая попытка, код ответа, тело ошибки
  │
  ├── Редактирование в статусе «Ошибка отправки»:
  │   ├── Менеджер МОЖЕТ редактировать поля продажи
  │   │   (ошибка может быть из-за невалидных данных — опечатка в ИНН и т.п.)
  │   ├── После исправления → «Повторить отправку»
  │   └── В аудите: изменение полей + повторная отправка
  │
  ├── Продажа НЕ блокируется полностью — можно работать с любыми полями
  └── В аудите: все попытки отправки с результатами