Andrey Epifancev f70522e1e0 docs: срок ответа OCR 20 мин, запись в горячую папку прямо в Input (#84 )

- 05-domain-rules §9.4, 01-project-overview: OCR 20 мин (парсер 5 мин)
- 03-architecture: scan-gateway пишет прямо в Input с перезаписью, как в старом АРМ
- 07-open-questions: дополнены OQ-58, OQ-79, OQ-137; новый OQ-159 (note DBML «OCR — 5 мин»)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-09 16:24:08 +04:00

8.1 KiB

Raw Blame History

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

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

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

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

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

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

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

Сквозной сценарий (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 20 мин (решение владельца 09.10.2026).
Порог «требуется проверка» — уверенность распознавания < 100 %.
Порог расхождения в паре ВГО — 5 % (к меньшей сумме). Пороги по КФО: ББ — 10 % ЧА (или 1 % ВБ, если ЧА < 10 % ВБ); ОФР — 10 % прибыли от продаж (или 1 % выручки при рентабельности < 10 %).
Минимум компаний в периметре — 2. ЮЛ одновременно только в одной ГСК или ГСЗ. Иерархия групп не поддерживается.
Хранение данных — 5 лет с даты прекращения отношений (ТЗ 8.4); срезы ЕХ — бессрочно; выгрузки в S3 exports/ — 7 дней.

8.1 KiB Raw Blame History Unescape Escape