25 KiB
25 KiB
АРМ КА — описание сущностей модели данных v5.13
Источник истины по структуре — data-model-v5.13.dbml (полный). Диаграммы по частям — diagrams_v5.13.zip (part01…09 svg/png + full_model.svg). Здесь — что каждая таблица значит для бизнеса, как связана с соседями и откуда взялась.
Что изменилось в v5.13 (ревью 30.09–01.10)
| № | Замечание | Решение |
|---|---|---|
| 1 | Вместо RBAC «в коде» — роли и права | permission + role_permission возвращены; права только через роли, прямых назначений пользователю нет. Исключения — заведением роли |
| 2 | osv_entry.parent_entry_id не нужен — храним только строки с контрагентами |
Отложено. Открыт вопрос: хранить ли строки уровня ACCOUNT для сверки «Σ контрагентов = итог счёта»; аналитика «Парсинг ОСВ» п.11 пока говорит «все строки» |
| 3 | osv_group_schema не особо нужна |
Убрана. Схема шапки — recognition_job.group_schema jsonb; тип строки — osv_entry.group_type |
| 4 | financial_statement_value.needs_review непонятен |
Убран: производное от confidence / is_recognized, порог может меняться |
| 5 | В recognition_job не нужны и result, и raw_result |
Оставлен только result_s3_object_id. Сырой ответ ИС Сканирование — S3 raw/{job_id}.json по конвенции, в БД не регистрируется |
| 6 | stored_file.fields_modified — что это |
Счётчик «исправлено полей» с карточки документа (v5.7). Убран — COUNT(is_modified) по данным |
| 6-бис | document_type не предусматривает несколько ОСВ или ББ+ОФР в одном файле |
Разделение файл / документ: stored_file — физический файл, document — логическая единица (1:N). Чек-лист, проверки, подтверждение, FK разобранных данных, consolidation_document, ex_snapshot_item — на document. Замена (superseded_by) — файл целиком |
| 7 | file_type: убрать Р7 |
Убран. xls/xlsx/xlsb → tabular-parser, pdf/png/jpg → scan-gateway |
Принципы модели (коротко):
- Первичка не редактируется: файлы и распознанные значения хранятся как пришли; правки аналитика — рядом (
is_modified,original_*) и в аудите. - Производные консолидации в работе (сводная ОСВ, пары ВГО, шахматка) не хранятся — считаются запросом. Хранятся только ручные решения (корректировки, гудвилл, подтверждение КФО клиента).
- При верификации всё замораживается в Единое хранилище (ЕХ) как самодостаточный срез, который не зависит от таблиц консолидации.
- Единственный писатель в БД — ядро
arm-core; сервисы распознавания видят только NATS и S3. - Права — данные (
role_permission), ограничения по ЗО/филиалу/статусу — policy-слой поверх прав.
Часть 01 — Группы компаний, организации, филиалы
| Сущность | Что это | Ключевые связи | Откуда |
|---|---|---|---|
regional_office |
Филиал банка: головной офис (ГО, is_head_office) и региональные филиалы (РФ). Определяет зону видимости пользователя и закрепление ГК. |
← company_group.base_regional_office_id, legal_entity.regional_office_id, app_user.regional_office_id |
ТЗ 8.1 |
company_group |
Группа компаний (ГК) — верхний уровень справочника клиентов. Текущее состояние (SCD4). crm_id из ЕЦП CRM (NULL, если создана вручную Куратором), внутренний code, закрепление за филиалом, флаг архива. |
→ regional_office; ← legal_entity, related_group, consolidation |
ТЗ 6.1, Прил. 2; макет |
company_group_history |
Прошлые снимки ГК: каждое изменение — новая строка с valid_from/valid_to. |
→ company_group |
ТЗ 6.10, 8.2 |
legal_entity |
Юридическое лицо / ИП. Натуральный ключ — ИНН. company_group_id = текущая ГК; NULL = монозаёмщик. close_date — закрыто/архивировано. |
→ company_group, regional_office; ← related_group_member, stored_file, document, osv_entry.counterparty_id, consolidation_member |
ТЗ 6.1, Прил. 2; ЕХ 6.1 |
legal_entity_history |
Прошлые снимки ЮЛ + вид события (создание, изменение, переход в другую ГК, закрытие, вывод из ГК) и дата вступления в силу. | → legal_entity |
ТЗ 8.2; макет |
legal_entity_alias |
Словарь написаний контрагента: как имя встречается в ОСВ и нормализованный ключ для матчинга. Пополняется при ручном сопоставлении. | → legal_entity |
ТЗ 6.5 |
related_group |
ГСК или ГСЗ внутри ГК; kind различает. Для ГСК формируется КФО. Иерархия не поддерживается. |
→ company_group; ← related_group_member, consolidation.related_group_id |
ТЗ 6.1, Прил. 2 |
related_group_member |
Состав ГСК/ГСЗ — история членства (SCD2). ЮЛ одновременно только в одной ГСК или ГСЗ. | → related_group, legal_entity |
ТЗ 6.1 |
Часть 02 — Пользователи, роли, права
| Сущность | Что это | Ключевые связи | Откуда |
|---|---|---|---|
app_user |
Пользователь АРМ. Аутентификация внешняя (РАИСА/SSO, external_id). Филиал (ГО/РФ), зона ответственности (ДКБ/ДМСБ/ДМ), табельный номер. Видимость данных = права роли + филиал + ЗО. |
→ regional_office; ← user_role, все *_by поля |
ТЗ 8.1, Прил. 2 |
role |
Роли: seed из ТЗ 8.1 (КА РФ, КА ГО, РКА, КМ, Куратор ГО, Эксперт, Администратор; is_system) + роли, заведённые администратором для исключений. v5.13: код роли в бизнес-логике не проверяется — только права. |
← user_role, role_permission |
ТЗ 8.1 |
permission |
v5.13. Атомарное право «объект × действие»: DIRECTORY/DOCUMENT/CONSOLIDATION/KFO/EX/EXPORT/USERS/AUDIT × VIEW/EDIT/APPROVE/VERIFY/DELETE/EXPORT/ADMIN. Seed, привязан к коду — администратор новые коды не создаёт. Право говорит «может»; policy-слой (ЗО, филиал, статус КФО) — «эту ли и сейчас ли». |
← role_permission |
ТЗ Прил. 2, сноска 29 |
role_permission |
v5.13. Матрица доступов как данные: effective_permissions(user) = ∪ permissions(roles(user)). Редактируется администратором на экране «Изменение ролей и прав доступа»; история — audit_event(ROLE_PERMISSION_CHANGE). Прямых прав у пользователя нет. |
→ role, permission |
ТЗ Прил. 2; макет |
user_role |
Назначение ролей пользователю (M:N). История — в аудите. | → app_user, role |
ТЗ 8.1 |
Часть 03 — Бухгалтерские справочники и правила
| Сущность | Что это | Ключевые связи | Откуда |
|---|---|---|---|
chart_of_account |
План счетов с иерархией, тип A/P/AP, признак забалансового. Seed — полный план 1С; нестандартные субсчета клиентов добавляет администратор. | ← osv_entry.account_id, elimination_rule_account, required_document_rule |
ТЗ 6.2/6.5, Прил. 3/4 |
elimination_rule |
Правило элиминации из Прил. 3 (ББ) / Прил. 4 (ОФР) как данные: пара статей, сторона, мера, режим, НДС, акцизы. Версионируется. | ← elimination_rule_account, correction.rule_id; версия фиксируется в consolidation_version |
ТЗ 6.4, Прил. 3/4 |
elimination_rule_account |
Счета/субсчета каждой стороны правила, включая исключения («76 кроме 76.7.1»). | → elimination_rule, chart_of_account |
ТЗ Прил. 3/4 |
required_document_rule |
Какие документы обязательны по подходу. v5.13: сверяется с document (тип + счёт + период), а не с файлом: выполнено = есть document CONFIRMED у каждого ЮЛ периметра. |
→ chart_of_account |
ТЗ 5.1, 6.2, сноска 12 |
Часть 04 — Файлы, документы, S3, задания распознавания
| Сущность | Что это | Ключевые связи | Откуда |
|---|---|---|---|
s3_object |
Реестр всех объектов в S3: бакет-роль, ключ, размер, sha256, срок жизни, ссылка на архив в data lake. Единая точка ретеншна (5 лет по ТЗ 8.4) и дедупа. | ← stored_file, recognition_job |
ТЗ 6.2, 8.4; ЕХ 8.3 |
stored_file |
v5.13: только физический файл одной загрузки: чей (ЮЛ), формат, hash, кто/когда загрузил, статус обработки (UPLOADED → PROCESSING → PROCESSED / ERROR / SUPERSEDED), версия при замене. Что внутри файла — document. Замена — файл целиком со всеми документами. |
→ legal_entity, s3_object, recognition_job; ← document, recognition_job |
ТЗ 6.2, 8.2; UC-01…05 |
document |
v5.13, новая. Логический документ внутри файла: ББ, ОФР, ОСВ по счёту (osv_account_code), расшифровка, прочее. Период, отчётная дата, где в файле (locator: лист / страницы), статус проверки (RECOGNIZED / NEEDS_CHECK / CONFIRMED / ERROR), результаты проверок периода и контрагента, кто подтвердил. Один файл → N документов (PDF с ББ+ОФР; xlsx с несколькими ОСВ). Создаёт ядро при маппинге результата recognition_job. На документ ссылаются разобранные данные, чек-лист, консолидация и ЕХ. |
→ stored_file, legal_entity, app_user; ← osv_entry, financial_statement_meta, consolidation_document, ex_snapshot_item |
ТЗ 6.2, 5.1, 8.2; макет (чек-лист, «Подтвердить данные») |
recognition_job |
Одна попытка распознать/распарсить файл. Единственная точка обмена с NATS (outbox/inbox, дедуп по result_msg_id, DLQ). Хранит сервис и версию, одну ссылку на нормализованный JSON-результат в S3 (v5.13), метрики, и схему группировок шапки ОСВ по листам (group_schema jsonb, v5.13 — вместо osv_group_schema). |
→ stored_file, s3_object; ← osv_entry, financial_statement_meta |
ТЗ 6.2, 6.10; DECISION-4 |
Часть 05 — Разобранные ОСВ
| Сущность | Что это | Ключевые связи | Откуда |
|---|---|---|---|
osv_entry |
Строка ОСВ: документ (счёт + период), владелец, тип строки по схеме шапки (group_type, v5.13), уровень и родитель (parent_entry_id — открыт вопрос, замечание 2), код счёта и резолв в план счетов, сырое имя/ИНН контрагента и резолв в ЮЛ, шесть сумм, тип данных (БУ/валюта/кол-во), «подакцизный» для 90-го. Ручные правки: is_modified, original_values, modified_by. Признак ГСК/ГК/Внешний не хранится — выводится из периметра версии. |
→ document, recognition_job, legal_entity ×2, chart_of_account |
ТЗ 6.2/6.5, Прил. 2; «Парсинг ОСВ» |
Часть 06 — Распознанные формы ББ/ОФР
| Сущность | Что это | Ключевые связи | Откуда |
|---|---|---|---|
financial_statement_meta |
Шапка распознанной формы (1:1 с document BALANCE/INCOME): ИНН и наименование как в документе, отчётная дата, единица измерения, реквизиты. Ревью формы (reviewed_by/at) и акцепт КА непройденных логических проверок с комментарием. Проверки (ТЗ 6.3) не хранятся — считаются на лету. Подтверждение документа — document.confirmed_by. |
→ document, recognition_job, app_user; ← column, line |
ТЗ 6.2/6.3; FNR01; макет |
financial_statement_column |
Колонки-периоды формы с датой — нужны для межформенной проверки (1370 на начало года) и гудвилла. | → meta; ← value |
ТЗ 6.3 п.7, 6.7 |
financial_statement_line |
Строка формы с кодом ОКУД и наименованием как распознано. Только строки с кодом; порядок и разделы — шаблон формы на фронте. | → meta; ← value |
ТЗ 6.2, Прил. 2 |
financial_statement_value |
Число в ячейке (строка × колонка): сумма, уверенность, is_recognized, ручная правка с исходным значением. v5.13: подсветка «требует проверки» = confidence < порог OR NOT is_recognized — считается, флаг needs_review убран. |
→ line, column, app_user |
ТЗ 6.2, Прил. 2 |
Часть 07 — Консолидация
| Сущность | Что это | Ключевые связи | Откуда |
|---|---|---|---|
consolidation |
Логическая консолидация: ГК + отчётный период. ГСК фиксируется/создаётся при верификации по фактическому периметру. Уникальна по (ГК, год, квартал). | → company_group, related_group; ← consolidation_version |
ТЗ 6.10, 7.2 |
consolidation_version |
Версия консолидации: номер, статус, сценарий, подход, гудвилл, инициатор и его офис (маршрут), кто утвердил / верифицировал, решение УОБ, отклонения от Методики, версия правил элиминации, ссылка на предыдущую. После VERIFIED — read-only. | → consolidation, app_user, regional_office, self; ← всё в частях 07–08 |
ТЗ 5.1, 6.4, 6.10; макет |
consolidation_status_history |
Каждый переход статуса: из → в, кто, когда, комментарий (обязателен при возврате). | → consolidation_version, app_user |
ТЗ 6.10, 8.2 |
consolidation_lock |
«Взять в работу»: кто редактирует версию, перехват с причиной. Из макета — ANL-036. | → consolidation_version, app_user |
макет |
consolidation_member |
Периметр версии — зафиксированный список ЮЛ; is_head_entity для гудвилла. |
→ consolidation_version, legal_entity |
ТЗ 6.1, 6.10 |
consolidation_document |
v5.13: какие документы (не файлы) участвуют в версии. Чек-лист = required_document_rule × периметр − consolidation_document. Переиспользование одного документа в нескольких версиях/периодах, монозаёмщики из ЕХ. |
→ consolidation_version, document |
ТЗ Прил. 2; ЕХ 7 |
Не хранятся (DECISION-5), считаются запросом по версии: сводная ОСВ, признак контрагента ГСК/ГК/Внешний, пары ВГО, шахматка, результирующая таблица ВГО.
Часть 08 — Корректировки, гудвилл, результат КФО
| Сущность | Что это | Ключевые связи | Откуда |
|---|---|---|---|
correction |
Ручная корректировка ВГО: пара (правило + компания 1 + компания 2 — естественный ключ), ББ/ОФР, строки и суммы по Дт и Кт, дочерние строки для распределения, причина, обязательный комментарий, статус, номер версии (история — в аудите). КФО = свод − Σ корректировок. | → consolidation_version, elimination_rule, legal_entity ×2, chart_of_account ×2, self |
ТЗ 6.4, 6.8, Прил. 9 |
goodwill |
Строка расчёта гудвилла: головная × дочерняя, доля владения, ФВ по 58.01, УК (1310) и добавочный капитал (1350 — вопрос методологам), гудвилл, «включить в КФО», комментарий. | → consolidation_version, legal_entity ×2, app_user |
ТЗ 6.7, Прил. 3 п.2, Прил. 8 |
kfo_result |
Шапка результата КФО: когда посчитан, заморожен ли, ЧА и ВБ, выручка, прибыль, расхождения, пороги, обоснование, итог гудвилла. | → consolidation_version (1:1); ← kfo_result_line |
ТЗ 6.4, 6.8, Прил. 10 |
kfo_result_line |
Строка консолидированного ББ/ОФР по коду ФСБУ 4/2023: сумма → авто-элиминация → корректировки → гудвилл → итог; «в т.ч. ВГО», источник, расхождение, комментарий. | → kfo_result; ← kfo_result_line_company |
ТЗ 6.4, Прил. 10; макет |
kfo_result_line_company |
Разрез строки КФО по компаниям периметра: сумма и доля. | → kfo_result_line, legal_entity |
ЕХ 6.6; макет |
client_kfo_line |
Сценарий «подтверждение КФО клиента»: по строке — значение и ВГО от клиента (ручной ввод), значение и ВГО банка, расхождение, причина. | → consolidation_version, app_user |
ТЗ 5.1, 6.10; макет |
Часть 09 — Комментарии, аудит, Единое хранилище
| Сущность | Что это | Ключевые связи | Откуда |
|---|---|---|---|
comment |
Полиморфный комментарий к объекту (документу, ячейке шахматки по ключу пары, строке КФО). | → app_user; object_type + object_id без FK |
ТЗ 6.3/6.4; макет |
audit_event |
Журнал действий (append-only): кто, когда, действие, раздел, объект, версия консолидации, before/after, результат, IP/браузер. Покрывает историю правок распознанных данных, корректировок, выгрузок, импорта справочников, входов, изменений матрицы прав (v5.13), подтверждения документов. | → app_user, consolidation_version |
ТЗ 8.2, Прил. 2; макет |
ex_snapshot |
Срез ЕХ: одна ГСК на одну отчётную дату, версия, статус (актуальный/архив), когда и кем верифицирован и записан. Самодостаточен — на консолидацию ссылается только данными. | → related_group, company_group, app_user, self; ← member, item |
ЕХ ТЗ 6.2, 6.4, 5.3 |
ex_snapshot_member |
Периметр среза на дату: ЮЛ с ИНН и наименованием на момент верификации. | → ex_snapshot, legal_entity |
ЕХ ТЗ 6.3 |
ex_snapshot_item |
Содержимое среза. Два вида: исходный документ → ссылка на document (v5.13; скачать — через его файл) и всё производное → payload jsonb. |
→ ex_snapshot, document, legal_entity |
ЕХ ТЗ 5.2, 6.7 |
Как читать модель по сценарию «сформировать КФО»
- Справочники (01–03): ГК → ЮЛ → ГСК/ГСЗ; план счетов; правила элиминации; что обязательно загрузить.
- Создание консолидации (07):
consolidationот ГК + период →consolidation_version→consolidation_member(периметр). - Загрузка (04):
stored_file+s3_object→recognition_job(queued → NATS → сервис → результат в S3 → done) → ядро создаётdocumentна каждый ББ / ОФР / ОСВ по счёту, найденный в файле. - Разбор (05–06): ОСВ →
osv_entry; ББ/ОФР →financial_statement_meta/column/line/value. Аналитик проверяет, правит, подтверждает документ; логические проверки — на лету; сопоставляет контрагентов (→osv_entry.counterparty_id,legal_entity_alias). Чек-лист закрывается поdocument CONFIRMED. - Консолидация (вычисляется): сводная ОСВ, пары ВГО, шахматка — из
osv_entry× периметр × правила. Аналитик вноситcorrection, заполняетgoodwill, при сценарии подтверждения —client_kfo_line. Результат —kfo_result(_line). - Согласование (07):
consolidation_status_historyпо маршруту; блокировкаconsolidation_lock. Что можно — решаетrole_permission+ policy-слой по статусу/ЗО. - Верификация → ЕХ (09):
ex_snapshot+member+item(документы по ссылке, остальное — payload). Версия → read-only. Всё это время —audit_event.
Открытые вопросы после v5.13
- Замечание 2 (
osv_entry.parent_entry_id, какие строки ОСВ хранить) — отложено; затрагивает и аналитику «Парсинг ОСВ» п.11. - Замена по-документно (одна ОСВ из файла с пятью) — сейчас не предусмотрена, замена файлом целиком. Если понадобится —
superseded_byпереезжает вdocument. - Статус
document.RECOGNIZED(ручная проверка не требуется по порогу) — подтвердить с аналитиками, нужен ли, или все документы проходят черезNEEDS_CHECK → CONFIRMED.