API до сводной ОСВ: пробелы по макету и комментариям фронта (периметр при создании, чек-лист в карточке, файлы в версии) #42

New Issue

aep · 2026-10-07T15:37:47+03:00

aep commented

2026-10-07 15:37:47 +03:00

Цель

Закрыть пробелы API пути пользователя до сводной ОСВ, найденные аудитом «экраны макета ↔ API» и комментариями фронтенда (07.10.2026). Код — arm-core; документы — отдельный PR в arm-ka-docs.

Что сделать (arm-core)

Создание консолидации с выбранным периметром (П-17). Модалка [42] после ГК+ГСК показывает все неархивные ЮЛ ГК, отмечены члены ГСК, отметки меняются, минимум 2. POST /consolidations — необязательное legal_entity_ids: нет поля — периметр из ГСК (как сейчас); есть — все ЮЛ из этой ГК (422 ENTITY_NOT_IN_GROUP), не меньше двух (PERIMETER_TOO_SMALL по выбранным, а не по ГСК). Одна транзакция, одно событие аудита.
Подписанные ячейки чек-листа в карточке версии (П-15). VersionCard отдаёт rules[] (как ChecklistOut.rules), чтобы members[].checklist[] можно было пометить ББ / ОФР / ОСВ <счёт> без второго запроса.
Участник периметра в карточке (П-9). MemberOut: тип ЮЛ (entity_type), счета загруженных ОСВ ЮЛ (не только правила комплекта) — состав полей уточнить в дизайне.
Файлы ЮЛ в контексте версии (П-16). GET /legal-entities/{id}/files — фильтр consolidation_version_id (смысл фильтра — в дизайне).

Решения владельца (07.10.2026)

П-1: «Показать ЮЛ без ИНН» / «Осталось: N» = все несопоставленные строки свода (unmapped, unmapped_total) — текущее поведение API верно, меняется только описание.
П-2: ГСК в версии не хранится; периметр живёт только в consolidation_member, в справочник переезжает по факту верификации (Срез 7). Колонка «ГСК» на [34] до верификации не заполняется.
П-3: допущение OQ-43 пересмотреть: «К отчетности» доступна и в статусах «в работе».

Документы (arm-ka-docs, отдельный PR)

Контракт для фронта: FileOut/JobBrief/DocumentBrief, GET /files/{id}, DELETE /files/{id} (409), коды rejected[] загрузки, GET /documents/{id}, /entries, справочники для [03]/[36]/[42]/[60] (П-5); новые поля пп. 1–4.
OQ-43 — новое решение (П-3); П-1 — формулировка баннера; 10-user-journey.md шаг 2.1 и mockup/INDEX.md [42] — блок «ЮЛ консолидации»; «CSV в Срезе 4 нет» в 10-user-journey.md:80 и dev/api-contract-slice-4.md:158.

Вне объёма

Шахматка и далее (Срезы 5–7), «Утверждён в РФ» / «Верифицирован в ГО» (Срез 7), шапка формы ОКЕИ/ОПФ (П-4, контракт), монозаёмщики [60] (П-6), period_check (OQ-120).

## Цель Закрыть пробелы API пути пользователя до сводной ОСВ, найденные аудитом «экраны макета ↔ API» и комментариями фронтенда (07.10.2026). Код — arm-core; документы — отдельный PR в arm-ka-docs. ## Что сделать (arm-core) 1. **Создание консолидации с выбранным периметром (П-17).** Модалка [42] после ГК+ГСК показывает все неархивные ЮЛ ГК, отмечены члены ГСК, отметки меняются, минимум 2. `POST /consolidations` — необязательное `legal_entity_ids`: нет поля — периметр из ГСК (как сейчас); есть — все ЮЛ из этой ГК (422 `ENTITY_NOT_IN_GROUP`), не меньше двух (`PERIMETER_TOO_SMALL` по выбранным, а не по ГСК). Одна транзакция, одно событие аудита. 2. **Подписанные ячейки чек-листа в карточке версии (П-15).** `VersionCard` отдаёт `rules[]` (как `ChecklistOut.rules`), чтобы `members[].checklist[]` можно было пометить ББ / ОФР / ОСВ <счёт> без второго запроса. 3. **Участник периметра в карточке (П-9).** `MemberOut`: тип ЮЛ (`entity_type`), счета загруженных ОСВ ЮЛ (не только правила комплекта) — состав полей уточнить в дизайне. 4. **Файлы ЮЛ в контексте версии (П-16).** `GET /legal-entities/{id}/files` — фильтр `consolidation_version_id` (смысл фильтра — в дизайне). ## Решения владельца (07.10.2026) - **П-1:** «Показать ЮЛ без ИНН» / «Осталось: N» = все несопоставленные строки свода (`unmapped`, `unmapped_total`) — текущее поведение API верно, меняется только описание. - **П-2:** ГСК в версии не хранится; периметр живёт только в `consolidation_member`, в справочник переезжает по факту верификации (Срез 7). Колонка «ГСК» на [34] до верификации не заполняется. - **П-3:** допущение OQ-43 пересмотреть: «К отчетности» доступна и в статусах «в работе». ## Документы (arm-ka-docs, отдельный PR) - Контракт для фронта: `FileOut`/`JobBrief`/`DocumentBrief`, `GET /files/{id}`, `DELETE /files/{id}` (409), коды `rejected[]` загрузки, `GET /documents/{id}`, `/entries`, справочники для [03]/[36]/[42]/[60] (П-5); новые поля пп. 1–4. - OQ-43 — новое решение (П-3); П-1 — формулировка баннера; `10-user-journey.md` шаг 2.1 и `mockup/INDEX.md` [42] — блок «ЮЛ консолидации»; «CSV в Срезе 4 нет» в `10-user-journey.md:80` и `dev/api-contract-slice-4.md:158`. ## Вне объёма Шахматка и далее (Срезы 5–7), «Утверждён в РФ» / «Верифицирован в ГО» (Срез 7), шапка формы ОКЕИ/ОПФ (П-4, контракт), монозаёмщики [60] (П-6), `period_check` (OQ-120).

aep referenced this issue from RSHB/arm-ka-docs

2026-10-07 16:52:20 +03:00

Документы к arm-core#42: контракт файлов и справочников, OQ-43, модалка [42] #50

aep referenced this issue from RSHB/arm-ka-docs

2026-10-07 17:01:18 +03:00

Документы к arm-core#42: контракт файлов и справочников, OQ-43, модалка [42] #51

aep referenced this issue from a commit

2026-10-07 17:18:10 +03:00

docs(openspec): change front-api-gaps — периметр при создании, ячейки чек-листа, участник периметра (#42)

aep referenced this issue from a commit

2026-10-07 17:18:10 +03:00

docs(plan): план front-api-gaps (5 задач); design D-2 — CSV читает ChecklistOut (#42)