Правила ОСВ: реквизит «Контрагенты.ИНН» строкой под контрагентом, OQ-162 (tabular-parser #32)

§1.1 — элемент «<группировка>.ИНН» в списке субконто варианта 2 — реквизит,
не группировка; §1.3 — строка реквизита отдаёт ИНН родительскому контрагенту
и уходит из rows (условия склейки, needs_check, пустая ячейка — R-1), целое
число из ячейки xls — без «.0». OQ-162 — решение владельца 13.10.2026.

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

context/05-domain-rules.md

@@ -72,6 +72,13 @@ r11 Договоры                                                        ←
          | Дебет | Кредит | Дебет | Кредит | Дебет | Кредит
 ```
 
+**Реквизит субконто в списке группировок (OQ-162, решение владельца 13.10.2026).** Элемент вида `<группировка>.ИНН`
+(«Детализация по субсчетам, субконто: Контрагенты, Контрагенты.ИНН»; суффикс после последней точки — по словарю
+`service_columns.inn`, префикс — имя одной из предыдущих группировок `COUNTERPARTY`) — не уровень аналитики, а реквизит
+этой группировки. В таблице 1С выводит его отдельной строкой **под** контрагентом (уровень глубже, те же суммы, ИНН часто
+числом). В `group_schema` такой элемент не попадает, у группировки-владельца `has_inn = true`; строки этого уровня
+склеиваются с родителем по §1.3.
+
 Нормализация значений шапки в типы:
 
 | Текст в шапке | `group_type` |
@@ -104,12 +111,21 @@ r11 Договоры                                                        ←
 ### 1.3 Строки
 
 Для каждой строки табличной части: `row_number` (исходный номер), `level` (outline level Excel, в xls — `rowinfo_map`; без группировок — каскад §1.0 п. 5),
-`row_value` (текст первой колонки), шесть сумм, ИНН (**только из колонки ИНН**; в ячейке оставляются цифры, результат
+`row_value` (текст первой колонки; целое число из ячейки — без дробной части: xls хранит числа как float, и
+`2370012036.0` — артефакт чтения, а не значение файла), шесть сумм, ИНН (**только из колонки ИНН**; в ячейке оставляются цифры, результат
 только при 10 или 12 цифрах — «ИНН 352819549855» → `352819549855`, иначе NULL; число из 9/11 цифр — ИНН региона 01–09
 с потерянным ведущим нулём — при извлечении из выбранной колонки дополняется нулём слева, R-24; ИНН контрагента — в порядке
 приоритета: колонка ИНН (в том числе склеенная «ИНН/КПП»), затем строка без сумм **прямо над** названием на том же уровне
 оформления (в `rows` не попадает, предупреждение «ИНН … над строкой … отнесён к ней»), затем конец текста названия
 («Полиграф, 3528315710», «ООО Альфа (ИНН 7701234567)» — 10 или 12 цифр после запятой, скобки, «/», пробела или метки «ИНН»).
+Отдельно — строка реквизита `<группировка>.ИНН` **под** контрагентом (вариант 2 шапки, §1.1, OQ-162): ИНН из её ячейки
+извлекается как из колонки ИНН (R-24) и переходит к родительской строке `COUNTERPARTY`, сама строка в `rows` не попадает,
+её дети (договоры) переходят к контрагенту на уровень выше; предупреждение «ИНН … (строка N) отнесён к контрагенту в
+строке M». Склейка — только если у родителя ровно одна такая строка, её шесть сумм равны суммам родителя, ИНН
+извлечён и не противоречит уже найденному ИНН родителя; иначе строка остаётся с `group_type = OTHER` (в свод не
+попадает), предупреждение с причиной, документ — `needs_check`. Пустая ячейка ИНН (физлицо без ИНН — 1С выводит строку
+реквизита и без значения) — «ИНН не указан»: строка склеивается, ИНН родителя остаётся NULL, `needs_check` не ставится
+(рулинг R-1 #32: иначе весь документ уходил бы на проверку из-за трёх физлиц). **Реализовано** (tabular-parser #32).
 Из текста ИНН отрезается всегда: `counterparty_name` без ИНН и разделителя, `row_value` — исходный текст; только для строк
 `COUNTERPARTY`, договоры и прочее не трогаются; правила — `osv_headers.yaml` (`counterparty_inn_suffix`, `inn_only_row`,
 `inn_kpp_cell`); **реализовано**, OQ-100, OQ-130 (tabular-parser #9, PR #15; синтетика `s17`–`s19`),

context/07-open-questions.md

@@ -167,6 +167,7 @@
 | OQ-159 | Note DBML `recognition_job.reply_deadline` «таймаут ожидания (OCR — 5 мин)» расходится с решением владельца 09.10.2026: срок ответа OCR — 20 мин (`DEFAULT_REPLY_TIMEOUT` в arm-core, `SCAN_TIMEOUT_SECONDS=1200` в scan-gateway). Поправить note при следующей версии DBML | решение владельца 09.10.2026 (не выпускать версию DBML ради note); arm-core #87, arm-scan-gateway #26, arm-ka-docs #84 | DBML `recognition_job`, `05-domain-rules.md` §9.4 | **закрыт 09.10.2026:** note исправлен в DBML v5.18 (docs #90) |
 | OQ-160 | Целевая модель версий консолидации (владелец, 09.10.2026): несколько рабочих версий одного периода с **разным периметром** делят первичку (рабочий стол консоли, `stored_file.consolidation_id`); после `VERIFIED` новая версия (`previous_version_id`) может менять документы при **том же** периметре. Ядро сейчас создаёт только версию 1 (`POST /consolidations`), «новая версия» и параллельные версии не реализованы. Нужны правила: создание второй рабочей версии (обязательно другой периметр?), создание версии после `VERIFIED` (копия периметра, подхват привязок), что видит панель [39] у верифицированной версии до Среза 7 (ЕХ) | brainstorming docs #90, `openspec/changes/console-files/design.md` R-6, R-7 | срез «версии консолидации» (после Среза 4), Срез 7 | открыт: модель файлов совместима; реализация — отдельный срез |
 | OQ-161 | Документ, период которого не совпадает с периодом консолидации, молча не привязывается к версии: ручное подтверждение проходит (200), а `fits` (`period_year` = год версии, D-5 Среза 4) его отбрасывает, `period_check` остаётся `UNKNOWN` (OQ-120) — свод пуст без объяснения (владелец 12.10.2026: ОСВ за 1 кв. 2025 в консолидации 2026 Q1). Период ОСВ берётся из шапки и через API не правится. Нужно ли (1) предупреждение «документ не подходит ни одной версии» при загрузке или подтверждении, (2) правка периода документа аналитиком (рядом с первичкой, как `original_*`), (3) постоянный режим «период из консолидации» для файлов, загруженных в неё | разбор владельца 12.10.2026; RSHB/arm-core#103 | `fits`, свод, чек-лист (§2, §9.3), карточка документа | **временное допущение (решение владельца 12.10.2026):** настройка `CONSOLIDATION_PERIOD_FROM_VERSION` (по умолчанию `false`; в контуре — `OPENBAO__APP__CONSOLIDATION_PERIOD_FROM_VERSION`) — ОСВ, загруженная в консолидацию (`stored_file.consolidation_id`) и не подходящая ей по периоду шапки, считается нарастающей за год и квартал консолидации для привязки, свода, чек-листа и колонки «ОСВ»; документ не меняется; ББ/ОФР и файлы с рабочего стола — по шапке; склейки кварталов нет (один слот на счёт ЮЛ). Только для тестов; открыт выбор постоянного решения (1)–(3), после него режим снять |
+| OQ-162 | ОСВ 1С, шапка варианта 2 «Детализация по субсчетам, субконто: Контрагенты, Контрагенты.ИНН» (ООО «Зерновая компания „Новопетровская“», ОСВ 60 за 9 мес. 2025, замечание банка 13.10.2026): ИНН выводится **отдельной строкой под** контрагентом (уровень глубже, те же суммы, ИНН числом). Парсер принимал «Контрагенты.ИНН» за второй уровень контрагентов: в «Контрагент / аналитика» — `2370012036.0`, наименования нет, ИНН у строк `null` → нет признака ГК/ГСК/Внешний, суммы контрагента в своде дважды | замечание банка 13.10.2026; RSHB/arm-tabular-parser#32 | tabular-parser §1.1, §1.3; свод и резолв контрагента в ядре | **решено владельцем 13.10.2026:** `<группировка>.ИНН` — реквизит, не уровень; строка ИНН склеивается с родительским контрагентом (ИНН — родителю, строка из `rows` убирается, дети — к контрагенту), только если она единственная у родителя и суммы равны; иначе строка `OTHER` и `needs_check`; пустая ячейка ИНН (физлицо) — склейка без ИНН (рулинг R-1); целое число из ячейки xls — без «.0». `05-domain-rules.md` §1.1, §1.3; **реализовано** RSHB/arm-tabular-parser#32 (713 из 716 контрагентов файла получили ИНН, 3 физлица без ИНН) |
 
 Служебные идентификаторы в DBML/аналитике: `ANL-nnn` — замечания аналитика к макету; `ARCH-nnn` — архитектурные решения;
 `DECISION-n` — решения по модели; `FIX-nn` — исправления дефектов v4.