314 lines
42 KiB
Markdown
314 lines
42 KiB
Markdown
# Конспект ТЗ АРМ КА (13 документов) — для агента-разработчика
|
||
|
||
Условные обозначения: ББ — бухгалтерский баланс, ОФР — отчёт о финансовых результатах, ОСВ — оборотно-сальдовая ведомость, ВГО — внутригрупповые обороты/обязательства, ГК/ГСК/ГСЗ — группа компаний / группа связанных компаний / группа связанных заёмщиков, ГО/ДО — головная/дочерняя организация, КФО — консолидированная финансовая отчётность.
|
||
|
||
Общее замечание по устареванию: все документы ТЗ написаны под модель данных v4 (`АРМ КА.Техническое задание - 01_2. Модель данных`). Актуальная модель — v5.13 (`claude/data-model-v5.13.dbml`). Ключевые переименования, которые надо держать в голове при чтении любого конспекта ниже:
|
||
|
||
| В ТЗ (v4) | В v5.13 |
|
||
|---|---|
|
||
| `stored_file.period_year/period_quarter/document_type` | `document.period_year/period_quarter/document_type/osv_account_code/is_cumulative`; `stored_file` — только физический файл |
|
||
| `stored_file.status` ("Загружен/Обработка/Требуется проверка/Ошибка") | `stored_file.status` (UPLOADED/PROCESSING/PROCESSED/ERROR/SUPERSEDED) — техника; статус проверки — `document.status` (RECOGNIZED/NEEDS_CHECK/CONFIRMED/ERROR) |
|
||
| `stored_file.current_recognition_job_id` | ссылка `document → recognition_job`, строки через `document_id` |
|
||
| `osv_entry.legal_entity_id` | `osv_entry.owner_legal_entity_id` |
|
||
| `osv_entry.group_schema_id → osv_group_schema` / `osv_grouping_schema` | `osv_entry.group_type` (enum), схема шапки — `recognition_job.group_schema jsonb` |
|
||
| `fin_report_header`, `Fin_report_rows`, `financial_statement_line.amount`, `report_id`, `row_code`, `value_current/value_prior_year/value_prior2_year` | `financial_statement_meta` (шапка) / `financial_statement_column` (дата колонки, `period_date`, `is_current`) / `financial_statement_line` (`line_code`) / `financial_statement_value` (`amount`, `confidence`, `is_recognized`) |
|
||
| `Consolidation_package`, `Company`, `Organizations`, `Osv_report_rows`, `Company_data`, `Consolidation_template`, `Intercompany_reconciliation` | `consolidation` / `consolidation_version` / `consolidation_member`, `legal_entity`, `osv_entry`, `kfo_result(_line)`; пары ВГО, шахматка, сводная ОСВ — **не хранятся, считаются** из `osv_entry × consolidation_member × правила` |
|
||
| `vgo_pair_match`, `chess_cell` | не существуют (вычисляемые) |
|
||
| `ref_crm_region`, `consolidation_group`, `group_membership`, `organization.full_name/org_type_code/is_gsk/is_gsz` | `regional_office`, `company_group`, `legal_entity`, `related_group` + `related_group_member` (kind gsk/gsz) |
|
||
|
||
---
|
||
|
||
## 1. "Шахматка" (DOC-221277)
|
||
|
||
**Назначение.** Визуальная матрица «компания × компания» для выявления расхождений во взаимных расчётах внутри периметра консолидации по данным ОСВ. Ничего не изменяет и не исключает; исключение — в таблице корректировок. Вторая часть документа — «Результирующая таблица»: сводка ВГО компании против группы по статьям ББ.
|
||
|
||
**Алгоритм шахматки.**
|
||
- Входной параметр: `consolidation_version_id`. Строки и столбцы — все `consolidation_member` версии; пары `A = B` не считаются.
|
||
- Период: `consolidation.year/quarter` через `consolidation_version`.
|
||
- Отбор строк ОСВ: только актуальный прогон распознавания (`current_recognition_job_id`), `counterparty_id` заполнен и входит в периметр, `legal_entity_id != counterparty_id`, `account_id` заполнен, `group_type = 'COUNTERPARTY'`, `data_type IN ('BU','SUM')` (CURRENCY/QUANTITY исключаются). Итоговые строки счетов/подразделений/договоров не участвуют.
|
||
- Пользователь выбирает набор дебетовых счетов (`chart_of_account.kind IN ('A','AP')`) и кредитовых (`kind IN ('P','AP')`); `row_type IN ('row','subaccount')`.
|
||
- `amount_a = SUM(closing_debit)` строк компании A с `counterparty_id = B` по дебетовым счетам.
|
||
- `amount_b = SUM(closing_credit)` строк компании B с `counterparty_id = A` по кредитовым счетам. Нет строк → 0.
|
||
- `variance_amount = ABS(amount_a - amount_b)`; `variance_percent = variance_amount / MIN(amount_a, amount_b) * 100`.
|
||
- Ячейки с `variance_percent > 5` подсвечиваются.
|
||
- Ячейка показывает три числа: amount_a, amount_b, (variance). Пример: 5000 / 6000 / (1000).
|
||
|
||
**Результирующая таблица.** Строка — статья, столбец — компания, ячейка — сумма ВГО компании по счетам статьи против всех остальных членов периметра; колонка «Итого по группе» = SUM по компаниям.
|
||
|
||
| Статья | Сторона | Поле | Счета |
|
||
|---|---|---|---|
|
||
| Дебиторская задолженность | A, AP | closing_debit | Д60.02, 60.22, 60.32, 62.01, 62.03, 62.21, 62.31, 76 (кроме 76.7.5, 76.7.9) |
|
||
| Кредиторская задолженность | P, AP | closing_credit | К60.01, 60.03, 60.21, 60.31, 62.02, 62.22, 62.32, 76 (кроме 76.7.1) |
|
||
| Фин. вложения | A, AP | closing_debit | Д58.01, Д58.03 |
|
||
| Долгосрочные кредиты и займы | P, AP | closing_credit | К67, К67.03 |
|
||
| Краткосрочные кредиты и займы | P, AP | closing_credit | К66, К66.03, К66.04 |
|
||
|
||
Фильтры строк те же, что для шахматки.
|
||
|
||
**Таблицы БД (по ТЗ).** `consolidation`, `consolidation_version`, `consolidation_member`, `legal_entity`, `stored_file`, `osv_entry`, `chart_of_account`, `osv_group_schema`/`osv_grouping_schema`.
|
||
|
||
**Открытые вопросы.** В документе непоследовательно `osv_group_schema` vs `osv_grouping_schema`, `group_schema_id` vs `grouping_schema_id`. Не определено, как выбирать «набор счетов» по умолчанию (FNR03 говорит о трёх предустановленных таблицах: 58.03 vs 67.03+66.03; 60+62+76 vs 60+62+76; все счета). Не описан расчёт «Итого» по строке/столбцу шахматки.
|
||
|
||
**Устарело относительно v5.13.** `stored_file.period_year/period_quarter/document_type` → `document`; фильтр «актуальный прогон» → через `document → recognition_job`; `osv_entry.legal_entity_id` → `owner_legal_entity_id`; `group_schema_id → osv_group_schema.group_type` → `osv_entry.group_type`; `chart_of_account.row_type` в v5.13 — `account_row_type` (account/subaccount/analytic), не `row`. Результат шахматки не хранится — чистая функция от версии консолидации.
|
||
|
||
---
|
||
|
||
## 2. Гудвилл (DOC-259025)
|
||
|
||
**Назначение.** Расчёт разницы между финансовыми вложениями ГО в ДО (сч. 58.01) и долей ГО в уставном капитале ДО. Таблица по каждой ГО, строка — одна ДО. Включение строки в КФО — чек-бокс «Включить в расчёт КФО».
|
||
|
||
**Алгоритм.**
|
||
1. `members = consolidation_member(version_id)`.
|
||
2. Для каждой ГО — актуальные строки ОСВ по счёту 58.01 на отчётную дату.
|
||
3. ДО = `osv_entry.counterparty_id`.
|
||
4. `FV = SUM(closing_debit) GROUP BY ГО, ДО` (несколько строк 58.01 по одной ДО суммируются).
|
||
5. `UK` = строка 1310 ББ дочерней организации на ту же отчётную дату (в FNR03 альтернатива: К80 + К83 ДО, при отсутствии — 1310).
|
||
6. `share` (доля владения, 0..100) — ручной ввод; пока нет — расчётные поля не считаются.
|
||
7. `participation = UK * share / 100`.
|
||
8. `goodwill = FV - participation` (может быть < 0).
|
||
9. `include_in_kfo` — ручной чек-бокс.
|
||
10. Итого по ГО; `kfo_goodwill = SUM(goodwill WHERE include_in_kfo)`.
|
||
|
||
Единицы — тыс. руб. Пример: ФВ 4 060 000; УК 371 173; доля 99,99% → участие 371 135,88 → гудвилл 3 688 864,12.
|
||
|
||
**Таблицы БД.** `consolidation_version`, `consolidation_member`, `legal_entity`, `osv_entry`, `chart_of_account` (упомянуто `account_code` — в модели это `code`), `financial_statement_line` (`line_code=1310`, `amount`). В v5.13 есть таблица `goodwill` (ввод доли и флага).
|
||
|
||
**Открытые вопросы.** Источник доли владения отсутствует — ручной ввод. Нет правила, что делать при отсутствии ББ ДО на отчётную дату. Не оговорено, попадает ли ДО вне периметра версии.
|
||
|
||
**Устарело.** `financial_statement_line.amount` → `financial_statement_value.amount` + выбор колонки по `financial_statement_column.period_date`/`is_current`; `chart_of_account.account_code` → `code`; «актуальные строки ОСВ» — через `document` (OSV, `osv_account_code = '58'`, период).
|
||
|
||
---
|
||
|
||
## 3. Корректировка данных (DOC-227278)
|
||
|
||
**Назначение.** Таблица `correction` фиксирует, из каких строк ББ исключается подтверждённая сумма ВГО по Дт- и Кт-стороне после сопоставления. Первичка не меняется (overlay). Три источника записей: пары со 100% совпадением, пары, требующие уточнения/распределения, нераспределённые строки ОСВ (ручная обработка).
|
||
|
||
**Структура `correction`.** `id`, `parent_correction_id` (NULL — основная), `legal_entity_id`, `debit_line_code`, `debit_adjustment`, `credit_line_code`, `credit_adjustment`, `deviation_amount`, `deviation_percent` (в v5.13 ещё `debit_account_code`, `credit_account_code`, `comment`, `consolidation_version_id`, аудит-поля).
|
||
|
||
**Правила.**
|
||
- Основная запись — по компании и строке ББ одной стороны; если сумма стороны распределяется на несколько строк ББ, каждая доп. строка — отдельная запись с `parent_correction_id = id основной`.
|
||
- Набор «основная + дочерние» обрабатывается при формировании КФО как единое целое.
|
||
- Контроль: `total_debit_adjustment = SUM(debit_adjustment)` и `total_credit_adjustment = SUM(credit_adjustment)` по связанным записям должны быть равны либо расходиться не более чем на 5%; иначе ВГО считается распределённым не полностью.
|
||
- Если ВГО после уточнения не подтверждено — записи не создаются.
|
||
- `deviation_amount = ABS(amount_dt - amount_kt)`; `deviation_percent = deviation_amount / MIN(amount_dt, amount_kt) * 100`.
|
||
|
||
Пример: пара Дт 1000 / Кт 500, подтверждено 1000 → A: 1230/1000 (основная); B: 1520/500 (основная) + B: 1550/500 (дочерняя).
|
||
|
||
**Таблицы БД.** `correction`.
|
||
|
||
**Открытые вопросы.** Опечатка `parrent_correction_id`. Не указано, как связать `correction` с исходной парой ВГО (пары не хранятся) — в v5.13 цель задаётся кодами строк/счетов, не FK. Не задано, обязателен ли комментарий (в BIQ-ТЗ — обязателен).
|
||
|
||
**Устарело.** Документ в целом совместим с v5.13 (`correction` есть). Расхождение: ТЗ не упоминает `consolidation_version_id`, `comment`, `*_account_code`.
|
||
|
||
---
|
||
|
||
## 4. 8. Формирование отчётов (DOC-221279)
|
||
|
||
**Назначение.** Пустая родительская страница раздела; содержит только заголовок. Дочерние документы: Шахматка, Автоматическое сопоставление ВГО, Гудвилл, Корректировка данных, Сводная ОСВ. Ни алгоритмов, ни таблиц, ни TODO. Ничего устаревшего, кроме того, что порядок шагов консолидации (сводная ОСВ → сопоставление ВГО → шахматка → корректировки → гудвилл → КФО) здесь не зафиксирован — он выводится из v5.13 (раздел «Как читать модель по сценарию»).
|
||
|
||
---
|
||
|
||
## 5. 10. Автоматические логические проверки отчётности (DOC-221281)
|
||
|
||
**Назначение.** Контроль непротиворечивости распознанных ББ/ОФР (PDF/JPG из ИС Сканирование или XLSX) сразу после распознавания и после каждой ручной правки. Результат определяет статус документа.
|
||
|
||
**Правила выполнения.** Проверки не меняют значения; выполняются отдельно по каждой колонке-дате формы; расхождение по любой дате = непройденная проверка. Сравнение в единице измерения формы.
|
||
|
||
| Событие | Результат |
|
||
|---|---|
|
||
| Распознавание завершено | все проверки по всем колонкам; статус «Загружен» если ОК, иначе «Требуется проверка» |
|
||
| Пользователь сохранил правки | повторный прогон, блок «Логические ошибки» обновляется |
|
||
| Пользователь отменил правки | данные не меняются, проверки не выполняются |
|
||
| «Подтвердить данные» без правок | контрольный прогон; ОК → «Загружен», иначе остаётся «Требуется проверка» |
|
||
|
||
**Формулы ББ.**
|
||
1. `1700 - 1600 = 0`
|
||
2. `1100 = 1110 + 1150 + 1160 + 1170 + 1180 + 1190`
|
||
3. `1200 = 1210 + 1215 + 1220 + 1230 + 1240 + 1250 + 1260`
|
||
4. `1300 = 1310 + 1320 + 1340 + 1350 + 1360 + 1370`
|
||
5. `1400 = 1410 + 1420 + 1430 + 1450`
|
||
6. `1500 = 1510 + 1520 + 1540 + 1550`
|
||
|
||
**Формулы ОФР.**
|
||
1. `2100 = 2110 - 2120`
|
||
2. `2200 = 2100 - 2210 - 2220`
|
||
3. `2300 = 2200 + 2310 + 2320 - 2330 + 2340 - 2350`
|
||
4. `2400 = 2300 - 2410 + 2420`
|
||
|
||
**Межформенная.** `1370(отчётная дата) - 1370(начало года) = 2400(ОФР за период)`. По BIQ-ТЗ при расхождении — акцепт КА с комментарием.
|
||
|
||
**UI.** Блок «Логические ошибки» над таблицей (карточка на проверку: имя, соотношение кодов строк, величина расхождения), подсветка ячеек, отдельная подсветка низкого confidence, режим «Редактировать» → «Сохранить» → перепрогон, «Подтвердить данные».
|
||
|
||
**UC-01** (система): выбор проверок по типу формы → расчёт по колонкам → статус. **UC-02** (КА РФ/КА ГО): правка по подсвеченным ячейкам; A1 — ошибка в исходном документе клиента, перезагрузка; A2 — значение не распознано, ручной ввод.
|
||
|
||
**Таблицы БД.** Явно не названы; подразумеваются строки/значения форм и статус документа.
|
||
|
||
**Открытые вопросы.** Статусы «Загружен/Требуется проверка» названы как статусы документа, хотя в v4 это `file_status`. Не описан механизм «принятия» расхождений пользователем (упомянуто в описании), только исправление.
|
||
|
||
**Устарело.** Статусы → `document.status` (NEEDS_CHECK/CONFIRMED). Данные → `financial_statement_column/line/value`; проверки не хранятся (считаются на лету); акцепт непройденных проверок — `financial_statement_meta.checks_accepted_at/comment`. Понятие «начало года» для 1370 — через `financial_statement_column.period_date`.
|
||
|
||
---
|
||
|
||
## 6. 6. Справочник «Группы компаний и организации» (DOC-221280)
|
||
|
||
**Назначение.** Описание экрана и сценариев ведения справочника ГК/ЮЛ/ГСК/ГСЗ/РФ и импорта из файла.
|
||
|
||
**UI.** Меню «Справочники → ГК и организации», кнопка «Импорт из файла». Фильтры: «Базовый РФ» (по умолчанию «Все РФ»), поиск по наименованию/CRM ID. Левая панель — список ГК (имя, CRM ID, счётчик организаций, создание ГК). Правая — состав ГК, вкладки ЮЛ (чек-бокс «Архив»), ГСК, ГСЗ, создание в каждой.
|
||
|
||
**Модальные формы (первая, актуальная часть документа).**
|
||
- ГК: `name` (обяз.), `crm_id` (обяз., уникальный), `base_regional_office_id` (выбор из `regional_office`).
|
||
- ЮЛ: `inn` (10 знаков ЮЛ / 12 ИП), `crm_id` (уник.), `entity_type` (ЮЛ/ИП), `name`, `legal_entity_alias` (несколько), «Входит в ГСК» (`related_group_member kind=gsk`, одна ГСК из текущей ГК), «Входит в ГСЗ» (kind=gsz).
|
||
- Перевод ЮЛ в другую ГК: снимок в `legal_entity_history`, меняется `company_group_id`; поле «Дата перевода» помечено «??».
|
||
- Вывод ЮЛ из ГК: архив с событием «Закрытие»/«Переход в другую ГК», `close_date`, комментарий; текущие версии членства в ГСК/ГСЗ закрываются.
|
||
- ГСК/ГСЗ: `related_group.code` (уник.), `name`, `created_date`; состав ведётся через карточку ЮЛ.
|
||
- Импорт: ИНН → `legal_entity.inn`, Наименование → `name`, Тип → `entity_type`, Базовый РФ → `regional_office` по имени, ID ГК → `company_group.crm_id` (поиск, иначе создание). Ошибочная строка → лог, продолжение; дубль ИНН — стратегия «пропуск/обновление».
|
||
|
||
**UC-01…UC-05 (вторая, старая часть).** Используют другую модель: `ref_crm_region` (`region_code` varchar(20), `region_name`, `crm_system_id`), `consolidation_group` (`crm_group_id` формат `^1-[A-Z0-9]{7}$`, уникальность `group_name` в пределах региона, статус active/archived), `Organizations` (`full_name` varchar(300), `org_type_code` FK `ref_org_type`: ЮЛ/ИП/ФЛ/нерез.), `group_membership` (`membership_from`, `is_gsk`, `is_gsz`). Импорт UC-04: при >20% ошибочных строк — запрос подтверждения; дубль ИНН → не создавать, добавить membership, warning. Пустые is_gsk/is_gsz = false.
|
||
|
||
**Таблицы БД.** Актуальная часть: `regional_office`, `company_group`, `legal_entity`, `legal_entity_history`, `legal_entity_alias`, `related_group`, `related_group_member`. Старая часть: `ref_crm_region`, `consolidation_group`, `Organizations`, `group_membership`, `ref_org_type`.
|
||
|
||
**Открытые вопросы.** «?? Дата перевода». Нумерация UC сбита (UC-03 дважды, UC-04/UC-05 в заголовках). Противоречие: в модальном окне `crm_id` ГК обязателен, в UC-02 — нет (в v5.13 `crm_id` nullable, добавлен `code`).
|
||
|
||
**Устарело.** Вся часть UC-01…UC-05 (имена таблиц/полей). В v5.13 добавлены `company_group.code`, `is_archived`, `legal_entity.crm_id`, `is_mono_borrower`, `company_group_id` nullable, `regional_office.is_head_office`.
|
||
|
||
---
|
||
|
||
## 7. Пользовательские сценарии подробно (DOC-221274)
|
||
|
||
**Назначение.** Черновой список сценариев по ролям и заметка о порядке расчёта.
|
||
|
||
**Содержание.** Админ: импорт ГК/ГСК/ГСЗ/ЮЛ; добавление/удаление справочных данных; добавление пользователей; «внесение корректировок (каких?)». Пользователь: создание новой КФО; корректировки первичных данных; корректировки расчётных отчётов; добавление/удаление ЮЛ из ГСК. Два процесса: заполнение справочников (импорт/ручной ввод/удаление) и создание КФО (выбор из справочника → загрузка → правка → отчёты → смена статусов). Диаграмма — только картинка (не читается).
|
||
|
||
**Ключевая идея (выделена жирным).** «Возможно стоит сначала считать ОСВ и КФО сразу по всем первичкам, а потом на основе фильтров пересчитывать отчёты и сохранять КФО с отфильтрованными дочками (ГСК)». Это согласуется с v5.13: производные консолидации вычисляются от `consolidation_version` + периметра, а не хранятся.
|
||
|
||
**Таблицы БД.** Нет. **Открытые вопросы.** «(каких?)» — не определены корректировки администратора. **Устарело.** Ничего предметного; документ не фиксирует модель.
|
||
|
||
---
|
||
|
||
## 8. 3. Пользовательский сценарий (DOC-037736)
|
||
|
||
**Назначение.** Верхнеуровневый сценарий в виде трёх картинок (основной сценарий; этап создания отчёта и загрузки первички; этап работы с записью) плюс критерии приёмки.
|
||
|
||
**Критерии приёмки — загрузка/ИС Сканирование.** PDF/XLSX до 50 МБ; UUID v4 при старте задачи; таймаут ожидания JSON 5 мин, повторных попыток 0; ошибки ИС Сканирование логируются, статус задачи = FAILED.
|
||
|
||
**Критерии приёмки — парсинг/маппинг.** Коды строк ОКУД 1110–2500 → `row_code`; числа `decimal(18,2)`, минус сохраняется; `confidence` ниже порога → `needs_review = true`; FK `report_id` на шапку.
|
||
|
||
**Таблицы БД.** Косвенно `row_code`, `report_id` (старая модель `fin_report_header/rows`).
|
||
|
||
**Открытые вопросы.** Порог confidence не задан числом (в других документах — «ниже 100%»). Схемы не распарсены (картинки).
|
||
|
||
**Устарело.** `report_id/row_code/needs_review` → `financial_statement_meta/line/value` (`line_code`, `confidence`, `is_recognized`); «статус задачи FAILED» → `recognition_job.status = error/dlq`; «0 повторных попыток» противоречит v5.13 (outbox с повторной публикацией, replay через `attempt+1`).
|
||
|
||
---
|
||
|
||
## 9. Периоды загружаемой отчётности (DOC-259006)
|
||
|
||
**Назначение.** Правила отчётных периодов комплекта (ББ + ОФР + ОСВ) и приведения поквартальных ОСВ к нарастающему итогу.
|
||
|
||
**Правила.**
|
||
- Комплект за один период; по умолчанию нарастающим итогом с начала года. Периоды: 1 квартал (янв–мар), 6 мес (янв–июн), 9 мес (янв–сен), 12 мес (янв–дек).
|
||
- Для каждой ОСВ система определяет: год, период, дату начала, дату конца, способ: `CUMULATIVE` или `QUARTER`.
|
||
- Вариант 1 (CUMULATIVE) — преобразование не требуется.
|
||
- Вариант 2 (QUARTER) — перед КФО строится расчётное представление нарастающим итогом:
|
||
- обороты Дт/Кт = сумма оборотов всех кварталов периода;
|
||
- начальное сальдо = начальное сальдо первой ОСВ года (Q1);
|
||
- конечное сальдо = конечное сальдо последнего квартала периода.
|
||
- Пример 6 мес: opening = Q1.opening; turnover = Q1 + Q2; closing = Q2.closing.
|
||
|
||
**Таблицы БД.** Не названы. В v5.13: `document.is_cumulative`, `period_year`, `period_quarter`.
|
||
|
||
**Открытые вопросы.** Не описано поведение при отсутствии промежуточного квартала (пропуск Q2 при наличии Q1 и Q3). Не описано, на каком уровне агрегировать (строка контрагента/договора — соединение по ключу «счёт + контрагент + договор» не задано). В FNR01 маппинг периода помечен «нужно уточнить: может ли ОСВ с номером квартала считаться нарастающей».
|
||
|
||
**Устарело.** Ничего: документ новый (DOC-259006), совместим с `document.is_cumulative`; расчётное представление — вычисляемое, не хранится.
|
||
|
||
---
|
||
|
||
## 10. FNR02 Модуль передачи PDF файлов в ИС Сканирование (DOC-221275)
|
||
|
||
**Назначение.** Интеграция с ИС Сканирование (Content AI) через «горячие папки» для распознавания ББ (Форма-1) и ОФР (Форма-2) из PDF/JPG; структура JSON-результата; маппинг в старые таблицы.
|
||
|
||
**Процесс.**
|
||
1. Модуль переименовывает PDF по маске `UUID + имя` и кладёт в папку «Входящие».
|
||
2. СС опрашивает папку каждые 10 сек; создаёт пакет в проекте `FINANCE_STATEMENT`; предобработка → классификация (первые страницы документов) → сборка пакета по документам → подбор шаблона → распознавание; уверенность поля = среднее побитовой маски, округление до сотых (01111101 → 0.67).
|
||
3. Скрипт формирует JSON; в «Исходящие» создаётся подпапка `UUID`, в ней `UUID.json` — по одному JSON на документ; исходник удаляется из «Входящие».
|
||
4. Модуль забирает JSON, ищет запись по `file_uid = Consolidation_package.uuid`, маппит.
|
||
|
||
**JSON.** `file_uid` (`^[a-zA-Z0-9_-]+$`, ≤255); `error` (null или `{code, message≤255}`; коды: `FILE_READ_ERROR`, `INVALID_FORMAT` (не pdf/jpeg), `INVALID_DOCUMENT` (шаблон не наложен), `RECOGNITION_FAILED` (>80% полей не распознано), `UNKNOWN_ERROR`); `data_ocr`: `label{form_name, confidence}`, `organization{full_name, confidence}`, `inn{inn, confidence}`, `units{measurement, confidence}`, `date` (в примерах), `table_structure[]` → `rows[]{row_index, cells[]{column_index, value, confidence}}`. Строка 0 — заголовки колонок. В реальных примерах (`aep_9.json`) confidence в процентах (100.0), а не долях, и структура полей отличается от ТЗ (`organization.form_name` вместо `full_name`).
|
||
|
||
**Маппинг (старая модель).** `Fin_report_header` (`report_id`, `package_id`, `company_id`, `report_type` BALANCE/OFR, `reporting_date`, `currency` RUB, `unit`, `okud_code` 0710001/0710002, `okpo_code`, `audit_required`); `Company` (`inn`, `kpp`, `okpo`, `okopf`, `okfs`, `name`).
|
||
|
||
**Таблицы БД.** `Consolidation_package`, `Fin_report_header`, `Company` (все старые).
|
||
|
||
**Открытые вопросы.** Ссылка на DOC-111205 (постановка OCR) недоступна. `reporting_date` — «ждём обновлённый JSON от ИС Сканирование» (FNR01). Формат confidence (0..1 vs 0..100) расходится между ТЗ и примерами. Нет описания таймаутов/повторов (есть только в DOC-037736: 5 мин, 0 повторов).
|
||
|
||
**Устарело.** Горячие папки → в v5.13 `recognition_pipeline = image` через scan-gateway + NATS, `recognition_job` как outbox/inbox, результат в S3 `raw/{job_id}.json`. `Consolidation_package/Fin_report_header/Company` → `recognition_job` + `document` + `financial_statement_meta/column/line/value`, организация — `legal_entity`. Ошибки → `recognition_job.status = error`, `error_message`; порог «confidence < 100 → NEEDS_CHECK» (`fields_low_confidence`).
|
||
|
||
---
|
||
|
||
## 11. FNR03 Модуль работы с созданной записью (DOC-221276)
|
||
|
||
**Назначение.** Самый объёмный документ: что делает система при открытии записи КФО — валидация распознанного, контроль сумм, затем по кнопке «Провалидировать и создать консолидированный отчёт» — построение КФО ГСК, шахматки, таблицы корректировок (`Intercompany_reconciliation`), Гудвила, формы 276-ОД и финальных проверок порогов.
|
||
|
||
**Шаг 1. Валидация при открытии.** Подсветка ячеек с `confidence < порог`, запись в лог «ЮЛ, форма — требуется валидация». Контроль сумм строго по столбцу (для каждой из value_current / prior / prior2): те же формулы, что в DOC-221281 (1700−1600=0; 1100; 1200; 1300; 1400; 1500; 2100; 2200; 2300; 2400; 2400 = 1370тек − 1370пред). Сообщения: «Баланс за период не равен нулю», «Группирующая строка {row_code} за период не равна сумме детальных строк».
|
||
|
||
**Шаг 3.1. КФО ГСК (`Consolidation_template`).** Фиксированный набор строк ББ (1110…1700) + строка «Гудвил» без кода в разделе I/II и ОФР; колонки по каждой организации: «значение на дату», «в том числе взаимные обязательства», «очищенные показатели», «доля в показателе по группе»; далее «Итого», «Консолидированная отчётность от клиента», «Расхождения», «Примечания». Все ячейки, кроме имён и кодов, редактируемы. Незаполняемые строки = 0.
|
||
|
||
**Шаг 3.2. Пары счетов ББ (правило: совпало → маппим; расхождение ≤5% → берём min; >5% → подсветка, ничего не маппится).** Источник сумм: `closing_debit` (A) / `closing_credit` (B) на уровне субконто «Контрагенты», несколько строк суммируются.
|
||
|
||
| Счёт A | row_code A → B | Счёт B | Особенности |
|
||
|---|---|---|---|
|
||
| 58.01 | 1170 → 1310 | 80/83 | Если у B нет ОСВ 80/83: элиминация по 58.01 A; `1310(B) − 58.01(A)`, если > 0 → строка «Гудвил» (колонка «уточнить») |
|
||
| 58.03 | 1170 → 1410 | 67.03 | |
|
||
| 58.03 | 1240 → 1510 | 66.03 | |
|
||
| 76 (все) | 1230 → 1510 | 66.04, 67.04 | |
|
||
| 60, 62, 76 (кроме 76.7.5, 76.7.9) | 1230 → 1520 | 60, 62, 76 (кроме 76.7.1) | |
|
||
| 60, 62, 76 (кроме 76.7.5, 76.7.9) | 1230 → 1410 | 67 | |
|
||
| 60, 62, 76 (кроме 76.7.5, 76.7.9) | 1230 → 1510 | 66 | |
|
||
| 03 | 1150 → 1450/1550 | 76.7.1, 76.1.5, 76.7.9 | B: `76.7.1 − 76.7.5 − 76.7.9`; если у A нет ОСВ 03 — результат в строку «ППА», колонка Итого |
|
||
| ~~58~~ | ~~1170 → 1520~~ | ~~76~~ | зачёркнуто (отменено) |
|
||
|
||
**Шаг 3.2. Пары ОФР (обороты).**
|
||
- 2110: A = КТ 90.01 с НДС (приоритет) либо ДТ 62.01/62.21/62.31; B = КТ 60.01/60.21/60.31 + 76 (кроме 76.07.*, 76.03.*, плюс 76.07.2). min не применяется — берётся сторона A. `без НДС = оборот с НДС / (1 + СрВзСтавкаНДС/100)`.
|
||
- 2120: `элиминация = 2120 − ВГО по 2110` (зеркально выручке, без НДС).
|
||
- 2310: ДТ 76.03 (A) vs КТ 76.03 (B); берётся сторона A.
|
||
- 2320: ДТ 76.03/76.05/76.08/76.09 (A) vs КТ 66.02/.04/.06/.22/.24/.26, 67.02/.04/.06/.22/.24/.26 (B); `min`.
|
||
- 2330: КТ чётных субсчетов 66/67 + 76.07.5/76.08/76.28/76.38 (A) vs ДТ 76.03/.05/.08/.09 (B); `min`.
|
||
|
||
**Шаг 3.2. Шахматка/`Intercompany_reconciliation`.** Три таблицы: 58.03 vs 67.03+66.03; 60+62+76 vs 60+62+76 (с исключениями); все счета. Поля `reconciliation_id`, `package_id`, `row_code`, `org_pair_hash = min(org_id)|max(org_id)|account`, `org_a_id/account/amount`, `org_b_*`, расхождение, %, обязательный комментарий при правке.
|
||
|
||
**Шаг 3.3. Гудвил.** Как в DOC-259025, но УК = К80 + К83 ДО, при отсутствии — 1310. Итог в строку «Гудвил» КФО.
|
||
|
||
**Шаг 3.4. Форма 276-ОД** — заголовок без содержания.
|
||
|
||
**Шаги 4–5. Пороги расхождений (сумма `Intercompany_reconciliation` по диапазону row_code).**
|
||
- ББ (1100–1700): если `1300 < 0.1 * 1600` → допуск ≤1% от 1600 (ВБ), иначе ≤10% от 1300 (ЧА). Нарушение → лог «Совокупный объём расхождений превышает норму …», строка красным.
|
||
- ОФР (2110–2910): рентабельность `2200/2110 < 10%` или отрицательна → ≤1% от 2110; иначе ≤10% от 2200.
|
||
|
||
**Таблицы БД.** `Fin_report_rows`, `fin_report_header`, `Consolidation_template`, `Company_data`, `Osv_report_rows`, `Intercompany_reconciliation`, `Consolidation_package`, `Organizations` — все старые.
|
||
|
||
**Открытые вопросы.** «уточнить колонку» для гудвила; форма 276-ОД не описана; порог confidence не задан; в правилах пар знак «≤/>» 5% потерян при конвертации («Если расхождение 5%»); «СрВзСтавка НДС» — источник не определён; для 2320/2330 «субсчета определяет работник ПА самостоятельно»; строка «ППА» в КФО не определена; счёт 76.1.5 — вероятно опечатка (76.7.5).
|
||
|
||
**Устарело.** Все имена таблиц. В v5.13: КФО — `kfo_result` + `kfo_result_line` (`vgo_amount = eliminated_auto + eliminated_manual`, `deviation_amount`, `comment`, `source_kind`) + `kfo_result_line_company` (`share_percent`); пары ВГО и шахматка не хранятся; корректировки — `correction`; гудвил — `goodwill`; сравнение с клиентом — `client_kfo_line`. Правила элиминации в v5.13 вынесены в справочник правил (см. «Справочники (01–03): правила элиминации»). Актуальная формализация сопоставления — DOC-223044 «Автоматическое сопоставление ВГО» (только closing_debit/closing_credit, 1:1, Приложение 3 как источник пар).
|
||
|
||
---
|
||
|
||
## 12. 7. Функциональные требования (DOC-037739)
|
||
|
||
**Назначение.** Пустая родительская страница раздела; только заголовок. Дочерние: FNR01 (загрузка и создание записи; подстраница «Парсинг ОСВ»), FNR02 (ИС Сканирование), FNR03 (работа с записью). Таблиц, алгоритмов, TODO нет. Устаревшего нет.
|
||
|
||
---
|
||
|
||
## 13. 2. Модель данных (сущности) (DOC-019834)
|
||
|
||
**Назначение.** DBML-модель v4 «Часть 1: файлы и справочники» + табличное описание атрибутов. Вложения: `Состав ГК_ГСК_ГСЗ_из выписок_на 1 кв. 2026.xlsx`, `data-model-part1_4.dbml`.
|
||
|
||
**Принципы (сохраняются в v5.13).** Суррогатные uuid PK; натуральные ключи (ИНН, код счёта, CRM ID, код ГСК) — UNIQUE. ЮЛ и ГК — SCD4 (живая таблица + `*_history`), членство в ГСК/ГСЗ — SCD2 (`is_current`, `valid_from/valid_to`). Филиал = `regional_office` (ГО + РФ). XLSX → табличный сервис, PDF/PNG/JPG → сервис изображений; результаты одним потоком NATS, корреляция по `recognition_job.id`.
|
||
|
||
**Enum'ы v4.** `entity_type` (ЮЛ/ИП), `related_group_kind` (gsk/gsz), `account_kind` (A/P/AP), `document_type` (Бух. отчётность/ОСВ/ОФР/Прочий), `file_type` (XLSX/PDF/PNG/JPG), `recognition_pipeline` (tabular/image), `period_quarter` (Q1–Q4), `file_status` (Загружен/Обработка/Требуется проверка/Ошибка), `recognition_status` (queued/processing/done/error), `counterparty_type` (ГК/ГСК/Внешний), `statement_type` (balance/income), `fsl_row_kind` (section/row/sub/total/balance).
|
||
|
||
**Таблицы v4.** `regional_office`, `company_group`(+history), `legal_entity`(+history, `close_date` NULL=активна), `related_group` (UNIQUE(id, kind) для составного FK), `related_group_member` (partial UNIQUE: одна текущая версия на пару; одна ГСК на ЮЛ — помечено «ВРЕМЕННО»), `chart_of_account` (`code`, `parent_id`, `kind`), `role` (коды в DBML: KA_RF, KA_GO, KA_GO_DM, CURATOR_GO, ADMIN; в таблице: ADMIN, KA_RF, KA_GO, KA_HEAD, CLIENT_MANAGER, CURATOR_GO, EXPERT — противоречие), `app_user`, `stored_file` (с `period_year/quarter`, `document_type`, `status`, `current_recognition_job_id`), `recognition_job`, `osv_entry` (без `legal_entity_id`, `counterparty_id`, `group_schema_id`, `data_type` — их добавляют FNR01/Парсинг ОСВ), `financial_statement_line` (`recognition_job_id`, `statement_type`, `line_code`, `row_kind`, `ordinal`), `financial_statement_value` (`line_id`, `period_label`, `amount`, `is_recognized`).
|
||
|
||
**Открытые вопросы.** Два разных списка ролей. `uploaded_by/updated_by` — varchar, не FK. Нет `legal_entity_alias`, `consolidation*`, `correction`, `goodwill`, хотя остальные документы на них ссылаются.
|
||
|
||
**Устарело (всё, что перечислено в общей таблице в начале).** Дополнительно в v5.13: `s3_object`, `document`, `file_status`/`document_status` разделены, `document_type` → BALANCE/INCOME/OSV/DISCLOSURE/OTHER, `file_type` + XLS/XLSB, `account_row_type`, `business_segment`, `recognition_status` + published/dlq, `recognition_job.group_schema jsonb`, `osv_entry.document_id/owner_legal_entity_id/parent_entry_id/group_type/is_modified/is_excisable`, `financial_statement_meta/column`, `*_confidence/*_modified` на строках, `kfo_result*`, `client_kfo_line`, `audit_event`, `ex_snapshot*`, `role_permission`. Этот документ следует считать историческим; источник истины — `claude/data-model-v5.13.dbml`.
|