Действия сотрудника (T20)

staff_actions.py — что сотрудник банка делает с заявкой в статусе in_review (SPEC §11): одобряет, меняет предложение, отказывает, запрашивает данные или перезапускает автоматический расчёт. Код причины и комментарий обязательны для каждого действия. Статус меняется только через transition и store_decision из workflow.py (WORKFLOW.md), поэтому каждое действие попадает в журнал.

Действия

Действие	Переход	Что происходит
approve	in_review → offered	Сотрудник оставляет все предложения системы или часть из них (offer_ids)
change	in_review → offered	Сотрудник задаёт до 3 предложений: сумма, срок, при желании продукт и обеспечение. Каждое пересчитывается тем же quote (T16), по маршруту своей суммы, как предложения движка (quote_on_route, offers.py)
decline	in_review → declined	Повторное обращение через 90 дней
request_data	in_review → needs_data	Список документов попадает в Decision.requested_documents. Клиент отвечает выписками или продолжает без них, заявка пересчитывается (needs_data → enriching, T23, STATEMENTS.md)
rerun	in_review → submitted	Повтор автоматического расчёта: число попыток обнуляется. Только для заявки без скоринга: обязательный источник был недоступен (route_source_unavailable), карта не подошла к признакам, или три автоматических расчёта упали (decision = null)

Решение сотрудника — новый Decision поверх решения системы: статус, предложения, маршрут, а в reasons добавляется причина staff_<код>. В staff_text у неё название кода, должность и комментарий. В client_text — только то, что заявку рассмотрел специалист: код причины клиенту не показываем, среди кодов есть ПОД/ФТ (SPEC §1.11). Срок предложений (valid_until, 10 дней) считается от дня одобрения, а не от расчёта движка.

Чего нельзя. Сумма не может быть больше лимита: в контракте Offer.amount ≤ limit.limit, поэтому на сумму выше лимита API отвечает 422 с доступной суммой. Ставка выше потолка 30% или сумма ниже минимума продукта — тоже 422. Без скоринга (score = null) условия не посчитать: остаются отказ, запрос данных и перезапуск.

Полномочия и комитет

Каждое одобренное или изменённое предложение заново проходит матрицу полномочий: route_application(сумма предложения, ...) с грейдом, флагами и качеством данных из решения системы (ROUTING.md). Нужен самый строгий маршрут среди предложений.

• Маршрут underwriter (или auto) — решение применяется сразу, хватает одной подписи.
• Маршрут committee (сумма больше 15 млн ₽, или грейд D/E и сумма больше 5 млн ₽) — действие становится предложением комитету: оно сохраняется в loan_applications.pending_review, заявка остаётся в in_review. Решение применяется после второй подписи (sign).

Комитет — это две подписи (SPEC §15): андеррайтера и риск-менеджера, двух разных людей. Подписывать можно в любом порядке. Пока предложение ждёт подписи, другие действия по заявке недоступны (409). Второй подписант может отклонить предложение с кодом причины — тогда pending_review очищается, и заявку снова можно рассматривать.

Если сотрудник снизил сумму так, что она ушла из полномочий комитета, хватает одной подписи. Отказ и запрос данных — всегда одна подпись: это консервативные действия, им не нужны полномочия на сумму.

Коды причин

GET /api/v2/staff/reason-codes:

Действие	Коды
approve	confirmed_by_review, flag_explained, data_verified
change	risk_not_in_model, term_for_cash_flow, collateral_added, product_changed, client_request
decline	fraud_suspected, aml_risk, business_risk, data_unreliable, repayment_capacity
request_data	statement_needed, documents_needed, revenue_unconfirmed
rerun	source_restored, technical_failure
отклонение решения комитетом	terms_disagreed, more_review_needed, authority_exceeded

Комментарий — не короче 10 символов.

Насколько сотрудники согласны с системой

GET /api/v2/staff/overrides считает по всем применённым approve / change / decline (SPEC §11: «отдельно считаем, как часто андеррайтеры не соглашаются с системой»):

• согласие — одобрены все предложения системы, или отказ, когда предложений не было;
• несогласие (override) — одобрена только часть предложений, предложение изменено, или отказ, когда система предложения посчитала.

Ответ: decisions, overrides, override_rate, разбивка по действиям by_action и коды причин несогласий override_reasons. request_data и rerun — не решения, в счёт не идут. Флаг override хранится в событии review журнала.

Журнал

kind	Когда	data
review	Действие применено	action, reason_code, comment, override, route, position, signatures (для комитета — обе)
proposal	Предложение комитету (первая подпись)	то же и offers
signature	Вторая подпись или отклонение	approve, comment, position, proposal; при отклонении reason_code

После review идут обычные события decision и status от store_decision. Исполнитель — staff:<id>.

API (/api/v2, только сотрудник)

Метод	Что
POST /api/auth/staff	{"password", "position"}: position — underwriter (по умолчанию) или risk_manager
POST /applications/{id}/review	{"action", "reason_code", "comment", "revision", "offer_ids"?, "changes"?, "documents"?}; changes — [{"amount", "term_months", "product"?, "collateral"?}]. Ответ {"outcome": "applied" | "proposed", "application"}
POST /applications/{id}/review/sign	{"approve", "comment", "revision", "reason_code"?} (код обязателен при approve = false). Ответ {"outcome": "applied" | "rejected", "application"}
GET /staff/reason-codes	Коды причин
GET /staff/overrides	Статистика несогласий

Ошибки: 409 — устарел revision, заявка не в in_review или ждёт подписи; 422 — неверный код причины, короткий комментарий, сумма выше лимита, не та должность или тот же сотрудник на второй подписи. GET /applications/{id} для сотрудника отдаёт pending_review.

Упрощения

• # SIMPLIFICATION: один пароль STAFF_PASSWORD на все должности; должность сотрудник выбирает при входе. В банке должность и полномочия берутся из справочника сотрудников, а комитет подписывает квалифицированной ЭП.
• # SIMPLIFICATION: коды причин — константы в коде, а не справочник кредитной политики с версиями в config/ (перенос — отдельный PR в общую папку, docs/v2/NOTES.md, Unassigned).
• Комитет — две подписи, а не заседание с протоколом (SPEC §15).
• Сотрудник не может одобрить сумму выше лимита: это потребовало бы изменить контракт Offer.