КФО: §8 под DOC-274230/259025/272613, открытые вопросы OQ-180…193 (#206)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Andrey Epifancev 2026-11-06 20:25:15 +04:00
parent 228af4e4d9
commit 039c97b0eb
2 changed files with 199 additions and 14 deletions

View File

@ -707,6 +707,8 @@ closing_* = closing_* строки Qn
deviation_amount = |ΣA − ΣB|; deviation_percent = deviation_amount / min(ΣA, ΣB) * 100 deviation_amount = |ΣA − ΣB|; deviation_percent = deviation_amount / min(ΣA, ΣB) * 100
mode = min: расхождение ≤ 5 % → элиминация_r = min(ΣA, ΣB); > 5 % → подсветка, элиминация_r = 0, ждёт корректировки mode = min: расхождение ≤ 5 % → элиминация_r = min(ΣA, ΣB); > 5 % → подсветка, элиминация_r = 0, ждёт корректировки
mode = manual: элиминация_r = 0 — только корректировка / гудвилл (§8) mode = manual: элиминация_r = 0 — только корректировка / гудвилл (§8)
mode = min_or_full (правило 2, DOC-274230; seed правится в AURORA-1546): обе стороны > 0 → min(ΣA, ΣB) без порога;
ΣB = 0 → ΣA; ΣA = 0 → 0; компании 2 — каскадом по строкам article_2_line (§8 «КФО», п. 4)
``` ```
**Знак** (решение владельца 23.10.2026): суммы сторон — **со знаком**, как в шахматке §6 (одно правило и одна пара дают **Знак** (решение владельца 23.10.2026): суммы сторон — **со знаком**, как в шахматке §6 (одно правило и одна пара дают
одинаковые ΣA и ΣB на обоих экранах). Отрицательное сальдо строки (§1: возможно) — встречная позиция, например аванс или одинаковые ΣA и ΣB на обоих экранах). Отрицательное сальдо строки (§1: возможно) — встречная позиция, например аванс или
@ -941,7 +943,14 @@ OQ-145); тем же правилом сервисы разрешают ничь
- **Контроль распределения** (`CorrectionBalanceOut`): `debit_total`/`credit_total` — суммы сохранённых статей; - **Контроль распределения** (`CorrectionBalanceOut`): `debit_total`/`credit_total` — суммы сохранённых статей;
`difference`/`difference_percent` между ними, `remainder_1`/`remainder_2` — сумма стороны агрегата минус сохранённая `difference`/`difference_percent` между ними, `remainder_1`/`remainder_2` — сумма стороны агрегата минус сохранённая
статья. Это только отображаемый контроль — корректировку можно сохранить, даже если стороны не сошлись; в КФО по статья. Это только отображаемый контроль — корректировку можно сохранить, даже если стороны не сошлись; в КФО по
выбранным статьям уходит меньшая сумма (ответ п. 8). выбранным статьям уходит меньшая сумма (ответ п. 8): при заполненных обеих сторонах каждая исключает меньший из
итогов, снимая его со своих статей по порядку (блок «КФО», п. 5). Применённая корректировка **заменяет** автосумму
агрегата, а не прибавляется к ней.
- **Автосумма агрегата** (`eliminated_amount`) — по режиму правила, **одной функцией домена с КФО** (блок «КФО», п. 4):
`min` — меньшая сторона в допуске, иначе 0; `manual` — 0; `min_or_full` (правило 2 после правки seed в AURORA-1546)
— меньшая сторона при обеих > 0, `amount_1` при пустой стороне 2, порога нет: `exceeds_threshold = false`, статус
`AUTO` при обеих сторонах, `ONE_SIDED` при пустой стороне 2 (`eliminated_amount = amount_1`). Сейчас
`services/correction_source.py` знает только `manual` и «остальное как `min`» — правится вместе с seed.
- **Порог отклонения агрегата** (`exceeds_threshold`, не путать с контролем выше): `deviation_percent = |ΣA − ΣB| / - **Порог отклонения агрегата** (`exceeds_threshold`, не путать с контролем выше): `deviation_percent = |ΣA − ΣB| /
min(ΣA, ΣB) × 100` сторон агрегата (§5, п. 1/2a); реализовано **строго больше 5 %** (R-35, `domain/corrections.py`, min(ΣA, ΣB) × 100` сторон агрегата (§5, п. 1/2a); реализовано **строго больше 5 %** (R-35, `domain/corrections.py`,
`arm-core#215`/Task 8) — ровно 5,00 % в допуске. ТЗ/DOC-272613 читались как «от 5 % включительно»; аналитик на это не `arm-core#215`/Task 8) — ровно 5,00 % в допуске. ТЗ/DOC-272613 читались как «от 5 % включительно»; аналитик на это не
@ -973,21 +982,183 @@ OQ-145); тем же правилом сервисы разрешают ничь
тоже); в КФО — `Σ G > 0` строк, где `use_goodwill` = действующая ∧ отмечена ∧ доля и комментарий заполнены ∧ `G > 0`, и тоже); в КФО — `Σ G > 0` строк, где `use_goodwill` = действующая ∧ отмечена ∧ доля и комментарий заполнены ∧ `G > 0`, и
только при `consolidation_version.goodwill_enabled` (переключатель на вкладке, OQ-27). Доли в итогах не складываются; только при `consolidation_version.goodwill_enabled` (переключатель на вкладке, OQ-27). Доли в итогах не складываются;
сумма заполненных долей разных ГО в одной ДО > 100 % — предупреждение, не ошибка. сумма заполненных долей разных ГО в одной ДО > 100 % — предупреждение, не ошибка.
- **КФО** (AURORA-1546, ещё не реализовано): для пары с `use_goodwill` — ГО `1170 − ФВ`, ДО `1310 − P`, ГО строка - **КФО** — блок «КФО» ниже, п. 8: ветка гудвилла идёт по паре этой таблицы независимо от агрегатов корректировок;
`GOODWILL` `+ G` (служебный код, ASSUMPTION OQ-37), обычный ББ-2 по этой паре не применяется; при `G ≤ 0` — обычный у пары с `use_goodwill` — ГО `1170` на ФВ, ДО `1310` на P, строка `GOODWILL` на G, агрегат правила 2 той же пары не
ББ-2, разница в 1370 не переносится. Изменение ввода, переключателя или источников делает результат КФО устаревшим. применяется; при `G ≤ 0` или выключенном `goodwill_enabled` — обычный агрегат правила 2. Изменение ввода,
переключателя или источников делает результат КФО устаревшим.
**КФО** (ТЗ 6.4, Прил. 10): по каждому коду строки ББ/ОФР: **КФО** (ТЗ 6.4, 6.8, Прил. 10; AURORA-1546 — расчёт, AURORA-1547 — экран, AURORA-1417 — пересчёт; ещё не реализовано;
`sum_amount = Σ по компаниям` (значения отчётной колонки ББ / ОФР за период, в тыс. руб.) → контракт — `dev/api-contract-kfo.md`). Источники, в порядке приоритета: DOC-274230 «Правила пар счетов» (Лысенко,
`eliminated_auto` (Σ сумм элиминации троек, §5 п. 1; пересчёт в тыс. руб.) → `eliminated_manual = Σ correction APPLIED` → `goodwill_adjust` → 27.10.2026), DOC-259025 «Гудвилл» (03.11), DOC-272613 «Корректировка данных агрегатом» (04.11); черновик команды
`consolidated_amount`; `vgo_amount = eliminated_auto + eliminated_manual`; разрез `kfo_result_line_company` (`amount`, DOC-274636 «Расчёт КФО» и DOC-274647 «Экран: КФО» — там, где страниц Лысенко нет (решение владельца 28.10.2026: страницы
`share_percent` = доля компании в консолидированном показателе). Эталон колонок — `Консолидация_Группа РБ.xlsx`, лист аналитика важнее черновика). Развилки, которые решает заказчик, закрыты вариантом черновика как стартовым и помечены
`01.10.2024`: «значение на дату | в т. ч. взаимные обязательства | очищенные показатели | доля в показателе по группе». OQ — менять по ответу.
**Пороги** (ТЗ 6.8, FNR03 шаги 4–5), `kfo_result.threshold_*`: **Единицы.** Результат КФО хранится и отдаётся в **тыс. руб.** с двумя знаками. Суммы ОСВ и агрегатов — в рублях;
- ББ: если `1300 < 0.1 × 1600` → Σ расхождений ≤ 1 % × 1600 (ВБ), иначе ≤ 10 % × 1300 (ЧА). в тысячи переводятся один раз — на ячейке «в т. ч. взаимные» (компания × строка, п. 6).
- ОФР: если `2200 / 2110 < 10 %` или отрицательна → ≤ 1 % × 2110 (выручка), иначе ≤ 10 % × 2200.
Превышение → `threshold_justification` обязателен (принятие риска), подсветка. 1. **Строки.** Бланк ББ и ОФР — полный вариант (`full`) той редакции, которую ядро выбирает по **отчётной дате версии**
(§11.9: ≤ 31.12.2024 — `66n`, позже — `fsbu4`; перечни — `contracts/statement-code-orders.yaml`, наименования —
словарь имён ядра). Плюс служебная строка `GOODWILL` (п. 8). Выводятся все строки бланка, в том числе нулевые.
Строки форм компаний вне бланка и строки без кода в КФО не входят (решение 17.10.2026; предупреждение
`LINE_OUTSIDE_BLANK`). Перечень дополнительных строк FNR03 («ППА», «Износ ОС», «Дополнительная информация») — OQ-180.
2. **«По данным клиента» (`client_amount`).** По каждой компании периметра (`consolidation_member`) — подтверждённый
(`CONFIRMED`) документ ББ / ОФР, привязанный к версии (`consolidation_document`). Колонка: ББ — на конец отчётного
квартала, ОФР — за период с начала года по конец квартала; по дате колонки, не по `is_current` (как УК гудвилла).
Строки со статусом `ok`; повторы кода суммируются. Единицы формы — словарём единиц `arm_statements` → тыс. руб.:
«тыс. руб.» — как есть, «руб.» — / 1000, «млн руб.» — × 1000, до двух знаков `ROUND_HALF_UP`.
- **Знак строк расходов.** Формы хранят расходы по-разному (§7, §11.9: скобки, минус или «без знака»). Строки
расходов бланка — **2120, 2210, 2220, 2330, 2350** — приводятся к одной конвенции: `client_amount = −|значение|`.
Остальные строки — как в форме (1370, 2300, 2400 и прочие бывают любого знака по существу).
- Нет формы → значения компании 0, `FORM_MISSING`; две и более подтверждённые формы одного типа → 0,
`FORM_AMBIGUOUS`; единицы не распознаны → 0, `FORM_UNITS_UNKNOWN`. Значение из ОСВ вместо формы — OQ-182.
- КФО считается и при неполном комплекте — по тому, что подтверждено и привязано (DOC-274636, допущение 17).
3. **Агрегаты.** Взаимные суммы КФО берёт из **агрегатов таблицы корректировок** (§5 п. 2a, `VgoService`): тройка
(правило, компания 1, компания 2) с суммами сторон `amount_1`, `amount_2` (рубли) после ручных решений
`vgo_assignment`. Отдельного обхода ОСВ в КФО нет: что аналитик видит в таблице корректировок, то и вход КФО.
Нераспределённые строки ни в один агрегат не входят и в КФО не исключаются (`UNALLOCATED_ROWS` — число таких строк
без отметки «не учитывать в КФО»).
4. **Исключения агрегата.** Каждый агрегат даёт список исключений `(компания, код строки, сумма в рублях ≥ 0)`. Есть
применённая корректировка (`APPLIED`) — п. 5, иначе **автосумма** по режиму правила (`elimination_rule.elimination_mode`):
| Режим | Автосумма | Куда |
|---|---|---|
| `min` (ББ 3–8) | `min(amount_1, amount_2)`, если обе стороны > 0 и отклонение в допуске (порог — блок «Корректировка», OQ-178); иначе 0 | `article_1_line` компании 1, `article_2_line` компании 2 |
| `min_or_full` (ББ 2) | обе стороны > 0 → `min(amount_1, amount_2)`; сторона 2 = 0 → `amount_1`; сторона 1 = 0 → 0; порога нет (DOC-274230, правило 2) | `article_1_line` компании 1; компании 2 — каскадом по `article_2_line` |
| `manual` (ББ 1) | 0 — только корректировка | — |
| режимы ОФР | по правилам ОФР (DOC-274230, AURORA-1999, §5); до неё агрегатов ОФР нет — `INCOME_RULES_MISSING` | по правилу |
**Каскад** (составная статья «a/b/c»): сумма снимается со строки `a` компании в пределах её доступного остатка
(«по данным клиента» строки в рублях минус уже снятое с неё другими агрегатами, не ниже 0), остаток — со строки `b`,
затем `c`; не уместившееся — целиком на последнюю строку (DOC-274230: «если остаётся положительный остаток, он
исключается из строки 1370»). Агрегаты обходятся в порядке `rule_no`, затем ИНН компании 1, затем ИНН компании 2.
Seed правил ББ версии 1 (`arm-core/api/seed/core/elimination_rules_v1.yaml`, правка — в AURORA-1546, на месте, без
новой версии правил: верифицированных версий нет): правило 2 — `elimination_mode: min_or_full`,
`article_2_line: "1310/1350/1370"`. **Правило 1 остаётся `manual`**: по DOC-274230 обе его суммы — у компании 2
(Кт 76.7.1 − Дт 76.7.9 с каскадом 1150 → 1450 → 1550), а сторона агрегата устроена «компания 1 — сторона 1,
компания 2 — сторона 2»; автосумма правила 1 — после переработки seed (OQ-193), до того — корректировкой.
Автосумма — **одна функция домена** для таблицы корректировок и КФО (блок «Корректировка», `eliminated_amount`).
5. **Корректировка заменяет автосумму.** Применённая корректировка агрегата отменяет его автосумму целиком и к ней не
прибавляется (DOC-274636, допущение 4; DOC-272613: корректировки не меняют суммы сторон). Исключения: компания 1 —
статьи `debit[]` (основная, затем дочерние), компания 2 — `credit[]`, суммы как введены. Если заполнены обе стороны
и их итоги разные, каждая сторона исключает **меньший** итог (ответ Лысенко п. 8): снимается со статей стороны по
порядку — основная, затем дочерние в порядке ввода — до исчерпания. Пустая сторона ничего не исключает, другая — как
введена (одностороннее правило 1, правила ОФР 1–3).
6. **«В т. ч. взаимные» по компании (`vgo_amount`).** Σ исключений компании по строке в рублях → тыс. руб., **до целых
тысяч, половина — от нуля** (`ROUND_HALF_UP` по модулю), со **знаком строки**: у строк расходов (п. 2, они ≤ 0)
`vgo_amount` отрицательный. На всех строках одно равенство `cleaned_amount = client_amount − vgo_amount`; исключение
приближает значение к нулю (при превышении — проходит через ноль). Округление ячейки, а не каждой тройки и не «без
округления» — OQ-184.
7. **Строка КФО.** По компании: `client_amount`, `vgo_amount`, `cleaned_amount`, `share_percent = cleaned / bank_amount
× 100` (хранится 4 знака, отдаётся 2; `bank_amount = 0` → `null`; бывает отрицательной и больше 100 %). По строке:
`sum_amount = Σ client`, `vgo_amount = Σ vgo по компаниям = eliminated_auto + eliminated_manual` (auto — от агрегатов
без корректировки и гудвилл-пар, manual — от агрегатов с корректировкой; по одному агрегату они **не складываются**),
`goodwill_adjust` (у `GOODWILL` и итогов, куда он входит), **`bank_amount = sum_amount − vgo_amount + goodwill_adjust`**
(`kfo_result_line.consolidated_amount`).
**Итоговые строки** (1100, 1200, 1300, 1400, 1500, 1600, 1700; 2100, 2200, 2300, 2400, 2500): «по данным клиента» —
итог из формы компании; «в т. ч. взаимные» — Σ `vgo_amount` слагаемых по формуле бланка с их знаками (1100 ←
1110…1190; 1600 ← 1100 + 1200; 1700 ← 1300 + 1400 + 1500; 2100 ← 2110 + 2120; 2200 ← 2100 + 2210 + 2220; дальше по
бланку); `goodwill_adjust` — Σ слагаемых (то есть G у 1100 и 1600); очищенные — разность. Итог КФО — подписанный
клиентом итог минус взаимные, а не сумма своих строк (OQ-183). Доли компаний у 1100/1600 в сумме меньше 100 % на долю
гудвилла — у него нет разреза по компаниям. `deviation_amount` у итоговых строк — `null`.
8. **Гудвилл** (DOC-259025, блок «Гудвилл» выше). По паре ГО → ДО таблицы гудвилла с `use_goodwill` при
`goodwill_enabled` версии: исключения ГО `1170` на ФВ (все строки 58.01 и потомков пары, как в таблице гудвилла),
ДО `1310` на P (без каскада); G — в строку `GOODWILL`; агрегат правила 2 той же пары (компания 1 = ГО, компания 2 =
ДО), если он есть, **не применяется** — ни автосумма, ни корректировка. Строка 58.01 пары перенесена аналитиком в
другое правило или отмечена «не учитывать» — она всё равно в ФВ, предупреждение `GOODWILL_ROW_REASSIGNED` (ВГО по ней
может исключиться дважды, решает аналитик). Гудвилл включён, а применимых пар нет — `GOODWILL_NOT_APPLIED`.
Строка `GOODWILL` — раздел I, сразу после 1170, без разреза по компаниям; `goodwill_adjust = bank_amount = Σ G`
применимых пар, до целых тысяч; входит в 1100 и 1600; `kfo_result.goodwill_total` — то же значение. Место строки —
по DOC-259025 (отдельная строка раздела I); макет `[31-04]` показывает «В т.ч. Гудвилл» под 1170 — OQ-185.
9. **Расхождения по статьям.** По агрегатам режима `min` (ББ и ОФР): `|amount_1 − amount_2|` — на статью стороны с
большей суммой (компания 1 — `article_1_line`, компания 2 — `article_2_line`), независимо от корректировок (OQ-186).
Агрегаты `manual`, `min_or_full` и гудвилл-пары в расхождения не входят. По строке — Σ в рублях → тыс. руб. до целых
(`deviation_amount`). `total_deviation_bb` / `total_deviation_ofr` — Σ по строкам бланка своего отчёта, без итогов;
`has_deviations` — хотя бы одна строка ≠ 0.
10. **Контрольные пороги** (ТЗ 6.8, Методика пп. 5.1.2.4, 5.4; величины — КФО банка, тыс. руб.):
- ББ: ЧА = строка 1300 (как FNR03, OQ-187), ВБ = 1600. `ЧА ≥ 10 % ВБ` → база ЧА, предел 10 % ЧА; иначе (в том
числе ЧА ≤ 0) → база ВБ, предел 1 % ВБ.
- ОФР: `2200 ≥ 0` и `2200 / 2110 ≥ 10 %` → база 2200, предел 10 % 2200; иначе → база 2110, предел 1 % 2110.
`2110 = 0` → база 2110, предел 0 (OQ-188).
- Превышение — `total_deviation > предел`; равно — норма. Процент от базы — для сводки, база = 0 → `null`.
- Превышение хотя бы по одному отчёту → нужно обоснование принятия риска (`threshold_justification`). Обязательность
перед отправкой на верификацию (OQ-189, вариант черновика 2) проверяет переход статуса — AURORA-2002 / 1414.
11. **Реквизиты формы** (ТЗ 6.4, DOC-274636 правило 9): ГК, ГСК, отчётная дата, номер и статус версии, сценарий,
подход (`approach` — пакет документов), гудвилл учтён да/нет и сумма, расхождения ББ/ОФР и превышения, обоснование,
корректировки — число агрегатов с применённой корректировкой и Σ их исключений по отчёту
(`kfo_result.corrections_count_bb/_ofr`, `corrections_amount_bb/_ofr`, тыс. руб.), причины отклонений от Методики
(`consolidation_version.methodology_deviations` — ввод на вкладке «КФО»), решение УОБ (номер и дата — только
чтение). «Подход по Методике» и «согласовано клиентом» — не делаем до ответа заказчика (OQ-190, OQ-191).
12. **Пересчёт и заморозка.** Результат хранится у версии (`kfo_result`, одна запись). Пока версия не заморожена,
чтение отдаёт результат по текущим данным: если входы изменились после `computed_at`, сервер пересчитывает и
сохраняет до ответа (как обнаруживать изменения — AURORA-1417). Кнопки «Рассчитать» нет (OQ-192). Комментарии строк
и обоснование переносятся при пересчёте по (тип отчёта, код строки). При «Верифицирован» `is_frozen = true` (ставит
AURORA-2002) — дальше результат только читается. **Предупреждения** `{code, message, legal_entity_id?,
statement_type?, count?}` не блокируют расчёт; они и сводка корректировок — часть результата и **хранятся в
`kfo_result`** (`warnings`), чтобы замороженная версия отдавала то, что видели при верификации. Коды:
`FORM_MISSING`, `FORM_AMBIGUOUS`, `FORM_UNITS_UNKNOWN`, `LINE_OUTSIDE_BLANK`, `UNALLOCATED_ROWS`,
`INCOME_RULES_MISSING`, `GOODWILL_NOT_APPLIED`, `GOODWILL_ROW_REASSIGNED`. Правка ручных полей — аудит `KFO_EDIT`.
**Пример** (тыс. руб., если не сказано иное; те же числа — в `examples` контракта). Три компании: А «Альфа», Б «Бета»,
В «Гамма»; отчётная дата 01.10.2025 (ФСБУ 4). Агрегаты, рубли:
| Агрегат | `amount_1` | `amount_2` | Что исключается |
|---|---|---|---|
| пр. 6, А → Б | 102 000 000,00 | 100 000 400,50 | отклонение 1,99 % — автосумма 100 000 400,50: А 1230, Б 1520 |
| пр. 6, Б → А | 10 000 000,00 | 50 000 000,00 | 400 % — автосумма 0; корректировка Дт Б 1230 10 000 000, Кт А 1520 10 000 000 |
| пр. 6, А → В | 30 000 000,00 | 29 100 000,00 | 3,09 % (автосумма была бы 29 100 000), но корректировка: Дт А 1230 20 000 000 + А 1170 5 000 000, Кт В 1520 22 500 000 — итоги 25 000 000 и 22 500 000, каждая сторона исключает 22 500 000: А 1230 20 000 000, А 1170 2 500 000, В 1520 22 500 000 |
| пр. 2, А → Б | 50 000 000,00 | 40 000 000,00 | гудвилл-пара (ФВ 50 000 000, УК 40 000 000, d = 80 %, P = 32 000 000, G = 18 000 000): А 1170 50 000 000, Б 1310 32 000 000, `GOODWILL` 18 000; агрегат не применяется |
| пр. 2, А → В | 15 000 000,00 | 0,00 | `min_or_full`, стороны 2 нет → 15 000 000: А 1170; у В каскад 1310 (есть 10 000 000) → 10 000 000, 1350 (3 000 000) → 3 000 000, остаток 2 000 000 → 1370 |
| ОФР, А → Б | 10 000 000,00 | 10 000 000,00 | по правилам ОФР 1–2 (S без НДС): А 2110, Б 2120 |
ББ (по компании: по данным клиента / в т. ч. взаимные / очищенные):
| Строка | А | Б | В | КФО банка | Расхождения |
|---|---|---|---|---|---|
| 1170 | 70 000 / 67 500 / 2 500 | 0 / 0 / 0 | 0 / 0 / 0 | 2 500 | 0 |
| `GOODWILL` | — | — | — | 18 000 | 0 |
| 1100 | 70 000 / 67 500 / 2 500 | 0 / 0 / 0 | 0 / 0 / 0 | 20 500 (2 500 + гудвилл 18 000) | — |
| 1230 | 520 000 / 120 000 / 400 000 (70,42 %) | 130 000 / 10 000 / 120 000 (21,13 %) | 48 000 / 0 / 48 000 (8,45 %) | 568 000 | 2 900 |
| 1600 | 590 000 / 187 500 / 402 500 | 130 000 / 10 000 / 120 000 | 48 000 / 0 / 48 000 | 588 500 | — |
| 1310 | 100 000 / 0 / 100 000 | 40 000 / 32 000 / 8 000 | 10 000 / 10 000 / 0 | 108 000 | 0 |
| 1350 | 0 / 0 / 0 | 0 / 0 / 0 | 3 000 / 3 000 / 0 | 0 | 0 |
| 1370 | 280 000 / 0 / 280 000 | −20 000 / 0 / −20 000 | 5 000 / 2 000 / 3 000 | 263 000 | 0 |
| 1300 | 380 000 / 0 / 380 000 | 20 000 / 32 000 / −12 000 | 18 000 / 15 000 / 3 000 | 371 000 | — |
| 1520 | 160 000 / 10 000 / 150 000 | 110 000 / 100 000 / 10 000 | 30 000 / 22 500 / 7 500 | 167 500 | 40 000 |
| 1700 | 590 000 / 10 000 / 580 000 | 130 000 / 132 000 / −2 000 | 48 000 / 37 500 / 10 500 | 588 500 | — |
- 1230 А: 100 000 400,50 + 20 000 000 = 120 000 400,50 руб. → 120 000 тыс. (округление ячейки); Б 1520 —
100 000 400,50 → 100 000. Корректировка Б → А заменила автосумму (0), а не прибавилась к ней; корректировка А → В —
тоже, хотя автосумма была бы 29 100 000.
- Расхождения: 1 999 599,50 (А → Б) + 900 000 (А → В) = 2 899 599,50 руб. → 2 900 на 1230 А (сторона 1 больше);
40 000 000 → 40 000 на 1520 А (сторона 2 Б → А больше). Пары правила 2 в расхождения не входят. Всего ББ 42 900.
- Порог ББ: ЧА 371 000 ≥ 10 % ВБ (58 850) → база ЧА, предел 37 100; 42 900 > 37 100 — **превышение** (11,56 % от ЧА),
нужно обоснование.
- Сходимость: 1600 = 1700 = 588 500 (у ГО −ФВ, у ДО −P, гудвилл +G).
- **Гудвилл выключен** (та же версия, `goodwill_enabled = false`): агрегат пр. 2 А → Б — `min_or_full` → 40 000 000;
А 1170 −40 000 (всего 57 500), Б 1310 −40 000 (каскад уместился в 1310); `GOODWILL` 0; 1600 = 1700 = 580 500;
ЧА 363 000, предел 36 300, превышение 11,82 %.
ОФР (у Б 2120 в форме «без знака» +60 000 → приведено к −60 000; у В формы ОФР нет — `FORM_MISSING`, нули):
| Строка | А | Б | В | КФО банка |
|---|---|---|---|---|
| 2110 | 200 000 / 10 000 / 190 000 | 80 000 / 0 / 80 000 | 0 / 0 / 0 | 270 000 |
| 2120 | −120 000 / 0 / −120 000 | −60 000 / −10 000 / −50 000 | 0 / 0 / 0 | −170 000 |
| 2100 | 80 000 / 10 000 / 70 000 | 20 000 / −10 000 / 30 000 | 0 / 0 / 0 | 100 000 |
| 2200 | 50 000 / 10 000 / 40 000 | 15 000 / −10 000 / 25 000 | 0 / 0 / 0 | 65 000 |
Σ `vgo_amount` строки 2100 = 10 000 − 10 000 = 0 — валовая прибыль группы не меняется. Порог ОФР: 65 000 / 270 000 =
24 % ≥ 10 % → база 2200, предел 6 500; расхождений ОФР нет (агрегаты ОФР 1–2 — не `min`).
**Прогон на «Русском бисквите»** (критерий AURORA-1546): версия на 01.10.2024 — бланк 66н (есть 1120, 1231, 2930;
нет 1105, 1215, 2420), против листа `01.10.2024` эталона `Консолидация_Группа РБ.xlsx` (колонки «значение на дату |
в т. ч. взаимные обязательства | очищенные показатели | доля в показателе по группе»). Ожидаемые расхождения с эталоном:
алгоритм по ТЗ (min, порог 5 %), а эталон исключает каждую сторону полностью (OQ-155); ручные правки аналитика —
показываются, не прячутся.
**Сравнение с КФО клиента** (`scenario = CONFIRM`): `client_kfo_line` построчно: `client_amount`, `client_vgo_amount` **Сравнение с КФО клиента** (`scenario = CONFIRM`): `client_kfo_line` построчно: `client_amount`, `client_vgo_amount`
(ручной ввод), `bank_amount`, `bank_vgo_amount` (из `kfo_result_line`), `deviation_percent` к наименьшему, причина. (ручной ввод), `bank_amount`, `bank_vgo_amount` (из `kfo_result_line`), `deviation_percent` к наименьшему, причина.

View File

@ -183,3 +183,17 @@
| OQ-175 | Процент расхождения шахматки при отрицательной меньшей стороне: `variance_pct = variance / min(amount_a, amount_b) * 100` при отрицательном сальдо (возможно по §1) уходит в минус — пара (100, −5) даёт −2100 %, порог > 5 % не срабатывает, пара не подсвечивается. Считать от `\|min\|`, от меньшей по модулю стороны или подсвечивать пары с разными знаками всегда? | ревью arm-core #165 (AURORA-1651), 22.10.2026 | §6, шахматка, xlsx | открыт; до решения — как в коде (min со знаком); у пар ВГО §5 суммы сторон тоже со знаком (решение владельца 23.10.2026), но при `min ≤ 0` процент не считается и тройка подсвечивается | | OQ-175 | Процент расхождения шахматки при отрицательной меньшей стороне: `variance_pct = variance / min(amount_a, amount_b) * 100` при отрицательном сальдо (возможно по §1) уходит в минус — пара (100, −5) даёт −2100 %, порог > 5 % не срабатывает, пара не подсвечивается. Считать от `\|min\|`, от меньшей по модулю стороны или подсвечивать пары с разными знаками всегда? | ревью arm-core #165 (AURORA-1651), 22.10.2026 | §6, шахматка, xlsx | открыт; до решения — как в коде (min со знаком); у пар ВГО §5 суммы сторон тоже со знаком (решение владельца 23.10.2026), но при `min ≤ 0` процент не считается и тройка подсвечивается |
| OQ-176 | Счёт `000` «Вспомогательный» (технический счёт 1С для ввода остатков, `kind = AP`, `is_off_balance = false`) входит в шахматку «все счета». Исключать его вместе с забалансовыми? | ревью arm-core #165 (AURORA-1651), 22.10.2026 | §6, режим «все счета» | открыт; до решения — входит (решение владельца 22.10.2026: не трогать) | | OQ-176 | Счёт `000` «Вспомогательный» (технический счёт 1С для ввода остатков, `kind = AP`, `is_off_balance = false`) входит в шахматку «все счета». Исключать его вместе с забалансовыми? | ревью arm-core #165 (AURORA-1651), 22.10.2026 | §6, режим «все счета» | открыт; до решения — входит (решение владельца 22.10.2026: не трогать) |
| OQ-178 | Порог превышения отклонения агрегата в таблице корректировок — ровно 5 % в допуске (строго `>`) или на проверку («от 5 % включительно», как читается DOC-272613/ТЗ)? Аналитик (Лысенко) на прямой вопрос не отвечал | `dev/api-contract-corrections.md` §2; R-34/R-35 (`arm-core`, `openspec/changes/corrections-table-ui/design.md`) | §5 п. 2a, §8 «Корректировка», экран «Таблица корректировок» | открыт; реализовано строго `>` 5 % (R-35, `domain/corrections.py`) — фронт и сервер синхронны между собой, но не точно со спорным текстом ТЗ; правка при подтверждении — один оператор в `editorModel.ts`/`CorrectionTable.tsx` и в `domain/corrections.py` | | OQ-178 | Порог превышения отклонения агрегата в таблице корректировок — ровно 5 % в допуске (строго `>`) или на проверку («от 5 % включительно», как читается DOC-272613/ТЗ)? Аналитик (Лысенко) на прямой вопрос не отвечал | `dev/api-contract-corrections.md` §2; R-34/R-35 (`arm-core`, `openspec/changes/corrections-table-ui/design.md`) | §5 п. 2a, §8 «Корректировка», экран «Таблица корректировок» | открыт; реализовано строго `>` 5 % (R-35, `domain/corrections.py`) — фронт и сервер синхронны между собой, но не точно со спорным текстом ТЗ; правка при подтверждении — один оператор в `editorModel.ts`/`CorrectionTable.tsx` и в `domain/corrections.py` |
| OQ-180 | Строки КФО вне бланка ФСБУ: нужны ли строки FNR03 «ППА», «Право пользования активами», «Износ основных средств», «Расхождение баланса по Активу и Пассиву», «Форма 0710002 с.2», «Дополнительная информация»? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 1; FNR03 (DOC-221276) | §8 «КФО» п. 1 | открыт, вопрос заказчику; допущение принято (docs #206): только бланк редакции на отчётную дату + строка `GOODWILL` |
| OQ-181 | Состав колонок формы КФО: колонки макета `[31-04]` плюс расчётные «Расхождения» или ещё «КФО клиента» и ручные «Расхождения/Примечания», как в FNR03 и Прил. 10? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 2; макет `[31-04]`; ТЗ Прил. 10 | §8 «КФО» п. 7; `dev/api-contract-kfo.md` | открыт, вопрос заказчику; допущение принято (docs #206): колонки макета + «Расхождения» (расчётные); «Примечания» = «Комментарий»; КФО клиента — только на «Подтверждении КФО клиента» |
| OQ-182 | Значение компании без подтверждённой формы ББ/ОФР: 0 с предупреждением, строки из ОСВ по счетам статьи (нужна таблица «строка ↔ счета») или КФО не считается? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 3; ТЗ Прил. 10 («Баланс (форма 01)» / «ОСВ»); `kfo_result_line.source_kind` | §8 «КФО» п. 2 | открыт, вопрос заказчику; допущение принято (docs #206): 0 и `FORM_MISSING`; `source_kind` всегда `balance` |
| OQ-183 | Итоговая строка КФО (1100…1700, 2100…2500): по формуле бланка из очищенных строк или как итог формы клиента минус взаимные слагаемых? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 7 | §8 «КФО» п. 7 | открыт, вопрос заказчику; допущение принято (docs #206): итог формы клиента минус Σ взаимных слагаемых (совпадает с подписанным клиентом) |
| OQ-184 | Округление рублей до тысяч: ячейка «в т. ч. взаимные» (компания × строка) после сложения, каждая тройка до сложения, без округления (тысячи с копейками) или банковское? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 8 | §8 «КФО» п. 6 | открыт, вопрос заказчику; допущение принято (docs #206): ячейка после сложения в рублях, до целых тысяч, половина от нуля |
| OQ-185 | Место гудвилла в КФО: отдельная строка раздела I (DOC-259025, FNR03 «Заполнение поля Гудвил»), «В т.ч. Гудвилл» под 1170 (макет `[31-04]`) или строка 1105 бланка ФСБУ 4 (см. OQ-37)? | DOC-259025; DOC-274636, вопрос 9; макет `[31-04]`; ФСБУ 4/2023 | §8 «КФО» п. 8 | открыт, вопрос заказчику; допущение принято (docs #206): служебная строка `GOODWILL` раздела I после 1170, входит в 1100 и 1600, без разреза по компаниям; решают методологи |
| OQ-186 | «Совокупный объём расхождений» для порога: разницы сторон всех пар как найдены, только пары без корректировки или остатки после корректировок? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 10; FNR03 шаг 4 | §8 «КФО» п. 9 | открыт, вопрос заказчику; допущение принято (docs #206): разницы сторон всех агрегатов `min` как найдены, независимо от корректировок |
| OQ-187 | ЧА для порога ББ: строка 1300 КФО банка (FNR03) или расчёт по приказу Минфина № 84н (≈ 1300 + 1530)? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 11; ТЗ 6.8; Методика 5.1.2.4 | §8 «КФО» п. 10 | открыт, вопрос заказчику; допущение принято (docs #206): строка 1300 |
| OQ-188 | Порог при нулевой базе (2110 = 0 или 1600 = 0): предел 0 (любое расхождение — превышение) или порог не применяется? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», допущение 12 | §8 «КФО» п. 10 | открыт, вопрос заказчику; допущение принято (docs #206): предел 0 |
| OQ-189 | Что делает превышение порога: только подсветка, обязательное обоснование до отправки на верификацию, только до финала или блокировка верификации? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 13; DOC-037736 («НЕ ТОЧНО»); Excel В-01 | §8 «КФО» п. 10; AURORA-2002/1414 | открыт, вопрос заказчику; допущение принято (docs #206): обоснование обязательно до отправки на «Верификацию РФ/ГО» и до финала; проверяет переход статуса |
| OQ-190 | «Подход» в реквизитах КФО: пакет документов (`approach` BASIC/EXTENDED, ТЗ 5.1) или подход по Методике (сноска 15: «по Методике / индивидуальный / принята аудированная отчётность»)? Для второго нужно новое поле версии | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 14 | §8 «КФО» п. 11 | открыт, вопрос заказчику; допущение принято (docs #206): показывается только `approach`; поле «подход по Методике» не заводим до ответа |
| OQ-191 | Где фиксируется согласование КФО клиентом (Методика 5.8, 6.1): поле версии «да / нет / не направлялось» с датой или не вести в АРМ? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 15 | §8 «КФО» п. 11 | открыт, вопрос заказчику; допущение принято (docs #206): не ведём до ответа (вариант черновика — поле версии) |
| OQ-192 | Пересчёт КФО: автоматически после каждого изменения (Excel Р-11, Р-23), по кнопке «Рассчитать КФО» с пометкой «устарела» (FNR03) или только при открытии? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 16; AURORA-1417 | §8 «КФО» п. 12 | открыт, вопрос заказчику; допущение принято (docs #206): автоматически: чтение пересчитывает устаревший результат, кнопки нет |
| OQ-193 | Правило ББ 1 (76.7.1 / 76.7.9) автоматически по DOC-274230: обе суммы — у компании 2 (Кт 76.7.1 − Дт 76.7.9, каскад 1150 → 1450 → 1550), а сторона агрегата §5 устроена «компания 1 — сторона 1». Как переложить правило в seed (стороны, режим)? | DOC-274230 правило 1; `arm-core/api/seed/core/elimination_rules_v1.yaml` | §5 п. 1, §8 «КФО» п. 4 | открыт, задача команды (follow-up AURORA-1546); до решения правило 1 — `manual`, только корректировкой |