diff --git a/README.md b/README.md index 846878b..e25604d 100644 --- a/README.md +++ b/README.md @@ -1186,14 +1186,23 @@ docker compose -f ../docs/dev/docker-compose.yml -p arm-ka --profile services st Образ собирается из `../tabular-parser` (main соседнего репозитория workspace). +**Перед e2e остановите другие экземпляры ядра, подписанные на `files.tabular_parsed`** (контейнер `arm-core` из профиля +`services`, локальный `make run`/`run_server.py` с `NATS_ENABLED=true`): тест подписывается на реальный subject в боевой +queue group `arm-core`, подписчики группы получают сообщения по очереди (round-robin), и ack/результат парсера уйдут +чужому экземпляру (он отбросит их как `unknown_job`, у него другая БД) — тест упадёт по таймауту 60 с. Поднимайте только +`tabular-parser` (`--no-deps`), как в команде выше. + ### Основа таблицы корректировок (AURORA-1540, в работе) -Текущая задача не реализует ручное назначение, перенос или исключение строк ОСВ. +Текущая задача не реализует ручное назначение, перенос или исключение строк ОСВ через API (запись и перенос в +`vgo_assignment` — AURORA-1751). Чистая функция `domain/corrections.py` реализует контроль готового агрегата: при отклонении не более 5 % -справочная сумма элиминации равна меньшей стороне. Соседняя задача записывает готовые назначения в -`vgo_assignment`, а API корректировок читает их и группирует строки по правилу и паре компаний. Этот API -не выбирает правила, не разносит строки ОСВ и не меняет назначения. +справочная сумма элиминации равна меньшей стороне. Разнесение строк ОСВ по правилам и хранение ручных решений +(таблица `vgo_assignment`) — ответственность AURORA-1751 (`services/vgo.py`). API корректировок получает уже +вычисленные агрегаты и пары через интерфейс `CorrectionAggregateSource` (реализация `VgoCorrectionSource` вызывает +`VgoService.assignment_candidates`) и не читает схему `vgo_assignment` напрямую. Этот API не выбирает правила, не +разносит строки ОСВ и не пишет назначения. Подключены маршруты под `/api/v1/consolidations/versions/{version_id}`: diff --git a/openspec/changes/corrections-api-stage-one/design.md b/openspec/changes/corrections-api-stage-one/design.md index ed49b26..4c0c5c5 100644 --- a/openspec/changes/corrections-api-stage-one/design.md +++ b/openspec/changes/corrections-api-stage-one/design.md @@ -15,8 +15,9 @@ **Non-Goals:** -- Реализовывать собственное сопоставление строк ОСВ, выбирать правило или хранить вычисленные пары. -- Изменять DBML, добавлять ORM-модель или миграцию. +- Реализовывать собственное сопоставление строк ОСВ, выбирать правило или хранить вычисленные пары — это + AURORA-1751; DBML v5.24, ORM-модель `VgoAssignment` и миграция `vgo_assignment` в этой ветке сделаны в рамках + 1751, а не этим change (см. Migration Plan). - Импортировать XLSX, рассчитывать КФО, поддерживать ОФР или UI. ## Decisions @@ -44,3 +45,5 @@ ## Migration Plan Миграция для таблицы корректировок, вычисленных пар или их состава не добавляется. Существующая модель `correction` используется без изменения. + +В ветке есть миграция `0011_dbml_v5_24` — она создаёт только `vgo_assignment` (AURORA-1751), таблиц `correction`/`correction_line` не касается. DBML v5.24 в `arm-ka-docs` на момент этого change ещё не существует (`docs/model/data-model-v5.24.dbml`), `make dbml-check` не проходит; вопрос поднят отдельно. diff --git a/openspec/changes/corrections-api-stage-one/tasks.md b/openspec/changes/corrections-api-stage-one/tasks.md index 5cd58ec..7f5e7ec 100644 --- a/openspec/changes/corrections-api-stage-one/tasks.md +++ b/openspec/changes/corrections-api-stage-one/tasks.md @@ -33,6 +33,7 @@ - `mypy` схемы, источника и экспорта корректировок — успешно. - Целевые тесты источника, экспорта, VGO и OpenAPI — 90 успешно. - Расширенный набор с API-тестами остановлен на зависшей инициализации интеграционных фикстур; завершившиеся целевые тесты ошибок не показали. +- `make dbml-check` **не выполнялся**: `docs/model/data-model-v5.24.dbml` в `arm-ka-docs` ещё не существует (вопрос поднят отдельно, вне этого PR). ## Workflow follow-up