10-user-journey.md и mockup/INDEX.md сверены с 33 снимками; досняты Playwright модалка «Изменить статус», формы ГК/ЮЛ/ГСК/ГСЗ, меню ЮЛ и ГСК, раскрытый срез ЕХ, режимы редактирования вкладок отчёта, экран 03. Раздел «Что осталось уточнить» закрыт (экрана проверки ОСВ в макете нет). Расхождения макета с DBML/правилами — OQ-31…OQ-44; OQ-45…OQ-47 — по контракту и seed Среза 0; OQ-29 дополнен ролями макета. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
19 KiB
19 KiB
07. Открытые вопросы (реестр)
Правило: агент не закрывает вопросы сам. Если решение нужно для текущего среза — делает явное допущение, помечает его
в коде # ASSUMPTION(OQ-nn) и в OpenSpec-change, и переносит вопрос в статус «допущение принято». Пользователь закрывает
вопросы с аналитиками/методологами и обновляет этот файл.
| ID | Вопрос | Откуда | Влияет на | Статус / допущение |
|---|---|---|---|---|
| OQ-01 | Хранить ли все строки ОСВ или только контрагентские; нужен ли parent_entry_id (замечание 2 ревью v5.13) |
DBML, «Парсинг ОСВ» п. 11 | срез 2 (парсер, osv_entry) |
допущение: хранить все строки + level + parent_entry_id; строку «Итого» не хранить, использовать для сверки |
| OQ-02 | ОСВ «за 2/3/4 квартал» — квартальная или нарастающая? Как определять автоматически | FNR01 маппинг периода | срез 2, §2 правил | допущение: по тексту — квартальная; при наличии Q1 того же года сверять opening |
| OQ-03 | Приведение квартальных ОСВ к нарастающим: ключ соединения (контрагент vs договор), пропуск промежуточного квартала | DOC-259006 | срез 4 | допущение: ключ (счёт, контрагент); пропуск квартала → блокирующая ошибка чек-листа |
| OQ-04 | ОСВ по субсчёту (58.03 вместо 58) закрывает ли обязательный документ «ОСВ 58» | фикстуры | чек-лист | допущение: нет; показывать как «частично» |
| OQ-05 | Нужен ли статус document.RECOGNIZED или все идут через NEEDS_CHECK → CONFIRMED |
DBML | срез 2–3 | допущение: RECOGNIZED ставится, но подтверждение всё равно обязательно |
| OQ-06 | Замена одного документа внутри многодокументного файла | DBML | срез 3 | решено: замена файлом целиком |
| OQ-07 | Матчинг ВГО: одна строка = одна позиция (DOC-223044) или агрегировать по (компания, контрагент, счёт) (FNR03)? | DOC-223044 vs FNR03 | срез 5 | допущение: агрегировать по (компания, контрагент, счёт, сторона) с детализацией по osv_entry.id |
| OQ-08 | Знак порога 5 % в правиле пары (≤ или <), и к чему считать % — к меньшей сумме (Методика сноска 14) | FNR03 (знак потерян) | срез 5 | допущение: ≤ 5 % к меньшей |
| OQ-09 | Правила элиминации ОФР (2110/2120/2310/2320/2330): точный состав субсчетов, источник средневзвешенной ставки НДС, выбор субсчетов «работником ПА самостоятельно» | FNR03 | срез 6 | не реализовывать авто-элиминацию ОФР до решения; только ручные correction |
| OQ-10 | Гудвилл: входит ли стр. 1350 (добавочный капитал) в базу участия; УК из ББ (1310) или из ОСВ 80/83 | DBML, DOC-259025, FNR03 | срез 6 | допущение: 1310 из ББ; 1350 — настраиваемый флаг, по умолчанию выключен |
| OQ-11 | Строка «ППА» в КФО (правило № 1, когда у А нет ОСВ 03) — что это и куда | FNR03 | срез 6 | не реализовывать |
| OQ-12 | Формулы ОФР: знаки 2410/2420/2430 по ФСБУ 4/2023 vs 66н; состав 1100 (1120–1140) | DOC-221281 | срез 3 | допущение: формулы §7, строки без значения = 0 |
| OQ-13 | confidence от ИС Сканирование — доли 0..1 или проценты 0..100; имя поля организации (full_name vs form_name) |
FNR02 vs aep_*.json |
срез 3 (scan-gateway) | допущение: нормализовать в 0–100 по фактическим файлам |
| OQ-14 | reporting_date в JSON ИС Сканирование — «ждём обновлённый JSON» |
FNR01 | срез 3 | допущение: парсить из заголовка «на 30 сентября 2025 г.» |
| OQ-15 | Таймаут OCR 5 мин / 0 повторов (ТЗ 3) vs outbox с повторами (DBML) | DOC-037736 | срез 3 | решено DBML: max_attempts OCR = 1, парсер = 3 |
| OQ-16 | Матрица прав (ТЗ сноска 29 «будет разработана»); роли макета (Аналитик ДКБ, Наблюдатель) ≠ ТЗ (ANL-034) | ТЗ 8.1, макет | срез 1 | допущение: seed по §10 правил |
| OQ-17 | user_role M:N или одна роль на пользователя |
DBML | срез 1 | допущение: M:N |
| OQ-18 | Статусы REJECTED / ARCHIVED из макета (ANL-035); VERIFICATION_GO (РКА ГО) — есть ли в маршруте |
DBML, DOC-037734 | срез 7 | допущение: REJECTED не вводить (возврат = переход + комментарий); ARCHIVED — флаг фильтра; VERIFICATION_GO — есть |
| OQ-19 | consolidation_lock (взять в работу / перехват, ANL-036) — подтвердить с заказчиком |
макет | срез 7 | реализовать как в DBML |
| OQ-20 | company_group.crm_id обязателен (модалка) или nullable (UC-02, DBML) |
DOC-221280 | срез 1 | решено DBML: nullable + code |
| OQ-21 | «Дата перевода» ЮЛ в другую ГК — помечена «??» | DOC-221280 | срез 1 | допущение: effective_date ≥ сегодня (ANL-046) |
| OQ-22 | Ретеншн results/ в S3 (ARCH-010) |
DBML | срез 2 | допущение: как uploads/ |
| OQ-23 | Расшифровки (DISCLOSURE): разбирать или только хранить (ANL-040) |
DBML | — | только хранить |
| OQ-24 | Форма 276-ОД — состав и шаблон | FNR03 3.4 | — | вне scope |
| OQ-25 | Состав ГСК для тестовой группы «Русский бисквит»: входит ли ОАО «ЧКФ», ООО «ОФГ», «Лидер» | фикстуры | тесты консолидации | спросить аналитиков; до ответа — периметр из двух компаний |
| OQ-26 | Единицы: ББ/ОФР в тыс. руб., ОСВ в руб. — правило округления при элиминации (до тыс., банковское?) | — | срез 6 | допущение: считать в рублях, округлять до тыс. руб. на выходе в kfo_result_line (ROUND_HALF_UP) |
| OQ-27 | Поля ТЗ 5.1 (сценарий, подход, гудвилл) не в модалке создания консолидации | макет [42] vs ТЗ 5.1 | срез 4, 6 | решено (владелец макета, 03.10): approach = BASIC всегда в первой очереди, EXTENDED позже — определять по набору загруженных документов; goodwill_enabled — переключатель на вкладке «Гудвилл»; scenario = CONFIRM включается через меню «…» консолидации в списке |
| OQ-28 | 41) |
макет [41] | срез 3 | закрыт: реализовать по макету; для ОСВ (xlsx) левая панель — уточнить |
| OQ-29 | Макет: нет экранов пользователей / ролей / матрицы прав (ТЗ 8.1, role_permission); в журнале макета роли «Аналитик ДКБ», «Кредитный аналитик», «Утверждающий РФ», «Верификатор ГО», «Система распознавания / Сервис» (ANL-034, снимок 43-02) |
макет vs ТЗ 8.1 | срез 1 | допущение: минимальный экран администратора по §10 правил; роли — коды ТЗ 8.1, названия макета не используются |
| OQ-30 | Макет: шахматка и КФО показаны в тыс. руб. с 2 знаками, ОСВ — в рублях; где и как округлять (связано с OQ-26) | макет [30] [31-01] | срез 5–6 | допущение: хранить и считать в рублях, переключатель единиц — только отображение |
| OQ-31 | КПП ЮЛ: в макете колонка и поле форм (50, 61, 51-02, 79), в DBML v5.13 у legal_entity поля нет. Нужен ли КПП (и в импорте, и для ИП, у которых его нет)? |
макет [50] [51-02] | срез 1, DBML v5.14 | допущение: не вводить до решения; показывать «—» |
| OQ-32 | ЮЛ в макете состоит одновременно в ГСК и ГСЗ («Входит в ГСК» и «Входит в ГСЗ» заполнены, [79]); ТЗ 6.1 / ANL-030 — только в одной. Что верно? | макет [79] [51-02] | срез 1 (partial unique related_group_member.legal_entity_id) |
допущение: по ТЗ — одна группа; форма допускает выбор только одного поля |
| OQ-33 | «ID ГСК/ГСЗ в CRM» в формах (51-03, 51-04, 77-02; пример «3-9CGSK01» в формате ЕЦП CRM): у related_group в DBML только внутренний code (GSK-001). Есть ли у ГСК/ГСЗ идентификатор в CRM? |
макет [77-02] | срез 1, DBML | допущение: поле формы = related_group.code, генерируется системой; crm_id не вводить |
| OQ-34 | «Удалить» ГСК в меню строки (77-01): физическое удаление или закрытие с историей? В DBML у related_group нет флага/истории удаления |
макет [77-01] | срез 1 | допущение: удаление только пустой группы (без текущих участников), факт — в audit_event(MEMBERSHIP_CHANGE) |
| OQ-35 | База процента отклонения: в таблице корректировки % считается к сумме стороны ЮЛ-1 (−79,77 % для 1 000 ↔ 202,32, 31-02-02), в «Подтверждении КФО клиента» — к версии банка (ст. 2, 31-06); DBML и Методика (сноска 14) — к меньшей сумме. Что считать правильным для correction.deviation_percent и client_kfo_line.deviation_percent? |
макет [31-02] [31-06] vs DBML, Методика | срезы 5–6 | допущение: к меньшей (Методика); макет считать неточным |
| OQ-36 | Экран проверки показывает строки формы без кода («в том числе: Основные средства, пригодные к использованию…», 41); DBML хранит только строки с кодом (financial_statement_line), контракт требует line_code. Хранить ли расшифровочные строки без кода (и как их показывать)? |
макет [41] vs DBML, контракт | срез 3, контракт v1.x | допущение: строки без кода не хранить и не показывать в первой очереди |
| OQ-37 | Строка «Гудвилл 1105» (ФСБУ 4/2023) в распознанной форме (41) vs строка kfo_result_line.line_code = 'GOODWILL' в разделе I КФО: использовать код 1105 или служебный GOODWILL? Влияет на шаблон строк на фронте и на формулы §7 (1100 = … + 1105?) |
макет [41], ФСБУ 4/2023 | срез 3, 6 | допущение: хранить код 1105 как пришёл; строка КФО «GOODWILL» — отдельная, уточнить у методологов |
| OQ-38 | ЕХ в макете показывает и неверифицированные консолидации («Консолидация 2025 К4», без даты верификации, 62 [83-01]); ЕХ ТЗ 6.2 — срез пишется только после «Верифицирован». Показывать ли в ЛК ЕХ незавершённые консолидации (как «в работе») или только ex_snapshot? |
макет [62] [83-01] vs ЕХ ТЗ 6.2 | срез 7 | допущение: только срезы ex_snapshot; незавершённые — в разделе «Отчётность» |
| OQ-39 | Состав «сформированной отчётности» в ЕХ (83-01): КФО .xlsx, Шахматка .xlsx и «Консолидированная отчетность .pdf» с датой «Сформирован» и подписями Утвердил/Верифицировал. Нужен ли PDF-экспорт КФО и какие ещё артефакты (сводная ОСВ, корректировки, гудвилл — ЕХ ТЗ 5.2) показывать? |
макет [83-01] vs ЕХ ТЗ 5.2 | срез 7 | допущение: xlsx из payload на лету для всех item_type; PDF — не делать до решения |
| OQ-40 | «Квартальная дата» в журнале для консолидации 2024 К1 показана как 01.01.2024 (43-02); по правилам банка 1 квартал 2024 = отчётная дата 01.04.2024 (consolidation.reporting_date). Что выводить? |
макет [43-02] | срез 4, 7 | допущение: reporting_date по правилам (01.04.2024); макет неточен |
| OQ-41 | Экран «ЮЛ вне ГК» (61, заголовок «Юридические лица») показывает все ЮЛ с заполненной колонкой ГК, а не только монозаёмщиков. Это сводный реестр ЮЛ или фильтр company_group_id IS NULL? |
макет [61] | срез 1 | допущение: сводный реестр всех ЮЛ с фильтром «вне ГК», по умолчанию выключенным |
| OQ-42 | «Проверка распознавания» для ОСВ (xlsx) в макете отсутствует (строки doc-row--readonly, 39). Нужен ли отдельный экран проверки ОСВ (дерево строк, подсветка контрагентов) или проверка ОСВ только через сводную ОСВ (30)? |
макет [39] | срез 2 (UI) | допущение: минимальный экран таблицы ОСВ по §1 правил без левой панели исходника |
| OQ-43 | Кнопка «К отчетности» неактивна у консолидаций в статусах «Инициация» и «Верификация РФ», активна у «Консолидация РФ» и «Верифицирован» (34). Каково правило доступности отчёта по статусу / роли? |
макет [34] | срез 4, 7 (policy) | допущение: отчёт доступен с CONSOLIDATION_RF и далее для всех ролей с CONSOLIDATION_VIEW; «Инициация» — только карточка |
| OQ-44 | «Добавить версию» создаёт версию сразу без модалки (43-01), копируя периметр; нужно ли подтверждение и выбор сценария/подхода новой версии? |
макет [43-01] | срез 7 | допущение: без модалки, периметр и сценарий копируются из предыдущей версии |
| OQ-45 | Контракт recognition-result.schema.json допускает data_type = NU (строки налогового учёта в ОСВ «БУ, НУ»), а enum DBML osv_data_type — только BU, CURRENCY, QUANTITY, SUM. Добавлять NU в DBML (v5.14) или не хранить строки НУ? |
контракт v1.0 vs DBML | срез 2 (маппинг osv_entry) |
допущение: контракт оставляет NU; решение по хранению — до начала Среза 2; код Среза 0 не затрагивает |
| OQ-46 | Обязательны ли все ОСВ расширенного подхода (02, 03, 08, 44, 26, 91, 51, 52, 59, 80, 83, 86, 97, 001, 008, 009, 011) при approach = EXTENDED, или часть — «при наличии»? |
ТЗ 5.1; required_document_rule.is_mandatory |
срез 0 (seed), срез 3 (чек-лист) | допущение: все is_mandatory = true для EXTENDED |
| OQ-47 | Источник полного плана счетов 1С для seed chart_of_account: в фикстурах файла нет, «план счетов из бандла макета» не передан |
06-test-data.md §6, fixtures/README.md |
срез 0 (seed) | допущение: План счетов 94н (01–99, 001–011) + типовые субсчета 1С БП 3.0, упомянутые в §4/§6; остальное добавляет администратор (ARCH-004) |
Служебные идентификаторы в DBML/аналитике: ANL-nnn — замечания аналитика к макету; ARCH-nnn — архитектурные решения;
DECISION-n — решения по модели; FIX-nn — исправления дефектов v4.