# 01. Обзор проекта АРМ КА

## Кто, зачем, что

**Заказчик:** Департамент крупного бизнеса (ДКБ) АО «Россельхозбанк». Бизнес-инициативы BIQ-34 (АРМ КА: загрузка,
распознавание, консолидация) и BIQ-34649 (Единое хранилище финансовых данных клиентов, ЕХ).

**Пользователи:** кредитные аналитики региональных филиалов (КА РФ) и головного офиса (КА ГО), их руководители (РКА),
клиентские менеджеры (КМ), кураторы ГО, эксперты, администратор.

**Проблема сегодня:** аналитик вручную собирает Excel-консолидацию группы компаний (см. эталон
`Консолидация_Группа РБ.xlsx` в тестовых данных): переносит цифры из сканов ББ/ОФР, вручную ищет взаимные
обязательства между компаниями группы по ОСВ, вычитает их, считает доли, гудвилл, сверяет с консолидацией клиента.
Результат живёт в файлах, не переиспользуется, не версионируется.

**Что строим:** веб-систему, которая:

1. ведёт справочник групп компаний (ГК), групп связанных компаний/заёмщиков (ГСК/ГСЗ) и юридических лиц (ЮЛ/ИП) с историей;
2. принимает первичную отчётность по каждой компании периметра за отчётный период: ББ и ОФР (PDF/скан → ИС Сканирование → JSON),
   ОСВ по счетам (xls/xlsx из 1С → наш табличный парсер);
3. даёт аналитику проверить распознанное (подсветка низкой уверенности, логические проверки формул ББ/ОФР), исправить и подтвердить;
4. строит **сводную ОСВ** группы, сопоставляет контрагентов со справочником, помечает строки как ГСК / ГК / Внешний;
5. автоматически ищет **встречные ВГО** (компания А должна компании Б ↔ Б должна А) по разрешённым парам счетов, строит **шахматку** расхождений;
6. ведёт **корректировки** (исключение ВГО из строк ББ/ОФР), расчёт **гудвилла**, сравнение с КФО клиента;
7. формирует **КФО ГСК** (консолидированный ББ и ОФР по кодам строк ФСБУ 4/2023), контролирует пороги расхождений;
8. проводит КФО по **статусной модели** РФ → ГО до статуса «Верифицирован» (с номером и датой решения УОБ);
9. замораживает верифицированный результат и исходники в **ЕХ** (срез по ГСК на отчётную дату), даёт просмотр/выгрузку;
10. пишет **журнал действий** по всему перечисленному.

## Сквозной сценарий (happy path)

```
КА РФ создаёт консолидацию (ГК + период + сценарий + подход)     → consolidation / consolidation_version / consolidation_member
  ↓ загружает по каждой компании периметра файлы                 → stored_file + s3_object + recognition_job (outbox → NATS)
  ↓ tabular-parser / scan-gateway → JSON в S3 → NATS result       → arm-core создаёт document (ББ / ОФР / ОСВ по счёту)
  ↓ arm-core маппит JSON                                          → osv_entry | financial_statement_meta/column/line/value
  ↓ аналитик проверяет, правит, подтверждает документы            → document.status = CONFIRMED, audit_event
  ↓ чек-лист обязательных документов закрыт                       → required_document_rule × периметр − document CONFIRMED = ∅
  ↓ «Консолидировать»                                              → вычисляется: сводная ОСВ, типы контрагентов, пары ВГО, шахматка
  ↓ аналитик вносит correction, goodwill, при сценарии CONFIRM — client_kfo_line
  ↓ kfo_result + kfo_result_line (+ _company), пороги              → ADJUSTMENT при расхождении ≥ 5 %
  ↓ маршрут: CONSOLIDATION_RF → VERIFICATION_RF → CONSOLIDATION_GO → VERIFIED (№/дата УОБ)
  ↓ ex_snapshot + ex_snapshot_member + ex_snapshot_item            → версия read-only
```

## Что НЕ входит в наш код

- ИС Сканирование (Content AI) — внешняя. Мы пишем только `scan-gateway`: положить файл, забрать JSON, нормализовать.
- РАИСА / SSO — внешняя. Мы принимаем JWT и ищем пользователя по email.
- ЕЦП CRM — источник справочника ГК/ЮЛ; на старте — разовый импорт из файла, онлайн-интеграции нет.
- Инфраструктура: git, CI/CD, NATS, S3, кластер — платформенная команда банка. У нас — локальный `docker-compose`.
- Data lake для архива ЕХ — только ссылка `ex_snapshot.data_lake_ref`.

## Два сценария и два подхода (ТЗ 5.1)

| Параметр версии | Значения | Смысл |
|---|---|---|
| `scenario` | `CREATE` — «Создание КФО»; `CONFIRM` — «Подтверждение КФО клиента» | В `CONFIRM` аналитик дополнительно вводит КФО, полученную от клиента (`client_kfo_line`), система считает расхождения |
| `approach` | `BASIC` — ББ, ОФР, ОСВ 01, 58, 60, 62, 66, 67, 76, 90; `EXTENDED` — + ОСВ 02, 03, 08, 44, 26, 91, 51, 52, 59, 80, 83, 86, 97, 001, 008, 009, 011 | Определяет чек-лист обязательных документов (`required_document_rule`) |
| `goodwill_enabled` | bool | Включать ли расчёт гудвилла |

## Ключевые цифры и ограничения

- Отчётные даты: 01.04 (1 кв.), 01.07 (полугодие), 01.10 (9 мес.), 01.01 следующего года (год). Отчётность — нарастающим итогом.
- Файлы до 50 МБ; форматы XLS/XLSX/XLSB → табличный парсер; PDF/PNG/JPG → ИС Сканирование. Таймаут OCR 5 мин.
- Порог «требуется проверка» — уверенность распознавания < 100 %.
- Порог расхождения в паре ВГО — 5 % (к меньшей сумме). Пороги по КФО: ББ — 10 % ЧА (или 1 % ВБ, если ЧА < 10 % ВБ);
  ОФР — 10 % прибыли от продаж (или 1 % выручки при рентабельности < 10 %).
- Минимум компаний в периметре — 2. ЮЛ одновременно только в одной ГСК **или** ГСЗ. Иерархия групп не поддерживается.
- Хранение данных — 5 лет с даты прекращения отношений (ТЗ 8.4); срезы ЕХ — бессрочно; выгрузки в S3 `exports/` — 7 дней.