Andrey Epifancev e4e2b3ee83 docs: стартовый контекст

2026-10-02 23:02:44 +04:00

42 KiB

Raw Blame History

Конспект ТЗ АРМ КА (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) и долей ГО в уставном капитале ДО. Таблица по каждой ГО, строка — одна ДО. Включение строки в КФО — чек-бокс «Включить в расчёт КФО».

Алгоритм.

members = consolidation_member(version_id).
Для каждой ГО — актуальные строки ОСВ по счёту 58.01 на отчётную дату.
ДО = osv_entry.counterparty_id.
FV = SUM(closing_debit) GROUP BY ГО, ДО (несколько строк 58.01 по одной ДО суммируются).
UK = строка 1310 ББ дочерней организации на ту же отчётную дату (в FNR03 альтернатива: К80 + К83 ДО, при отсутствии — 1310).
share (доля владения, 0..100) — ручной ввод; пока нет — расчётные поля не считаются.
participation = UK * share / 100.
goodwill = FV - participation (может быть < 0).
include_in_kfo — ручной чек-бокс.
Итого по ГО; 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) сразу после распознавания и после каждой ручной правки. Результат определяет статус документа.

Правила выполнения. Проверки не меняют значения; выполняются отдельно по каждой колонке-дате формы; расхождение по любой дате = непройденная проверка. Сравнение в единице измерения формы.

Событие	Результат
Распознавание завершено	все проверки по всем колонкам; статус «Загружен» если ОК, иначе «Требуется проверка»
Пользователь сохранил правки	повторный прогон, блок «Логические ошибки» обновляется
Пользователь отменил правки	данные не меняются, проверки не выполняются
«Подтвердить данные» без правок	контрольный прогон; ОК → «Загружен», иначе остаётся «Требуется проверка»

Формулы ББ.

1700 - 1600 = 0
1100 = 1110 + 1150 + 1160 + 1170 + 1180 + 1190
1200 = 1210 + 1215 + 1220 + 1230 + 1240 + 1250 + 1260
1300 = 1310 + 1320 + 1340 + 1350 + 1360 + 1370
1400 = 1410 + 1420 + 1430 + 1450
1500 = 1510 + 1520 + 1540 + 1550

Формулы ОФР.

2100 = 2110 - 2120
2200 = 2100 - 2210 - 2220
2300 = 2200 + 2310 + 2320 - 2330 + 2340 - 2350
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-результата; маппинг в старые таблицы.

Процесс.

Модуль переименовывает PDF по маске UUID + имя и кладёт в папку «Входящие».
СС опрашивает папку каждые 10 сек; создаёт пакет в проекте FINANCE_STATEMENT; предобработка → классификация (первые страницы документов) → сборка пакета по документам → подбор шаблона → распознавание; уверенность поля = среднее побитовой маски, округление до сотых (01111101 → 0.67).
Скрипт формирует JSON; в «Исходящие» создаётся подпапка UUID, в ней UUID.json — по одному JSON на документ; исходник удаляется из «Входящие».
Модуль забирает 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.

42 KiB Raw Blame History Unescape Escape