dev/api-contract-corrections.md

@@ -239,20 +239,23 @@ rule_id? (uuid, для ASSIGN)}`.
   статьи; поля `debit_*` заполняются у записей стороны 1, `credit_*` — у стороны 2; `legal_entity_id` — компания стороны,
   `counterparty_id` — другая компания агрегата. `deviation_*` записываются на момент сохранения — по ним считается
   `composition_changed`.
-- **Кто что делает** (`[allocation-split]`, 29.10): AURORA-1751 — разнесение строк (чистая функция), ручные решения
-  (`POST …/allocations`, `vgo_assignment`, аудит, DBML v5.24); AURORA-1540 — таблица, корректировка, экспорт поверх функции
-  1751 (источник агрегатов в WIP #208 — `CorrectionAggregateSource`, его реализация вызывает функцию 1751).
-- `vgo_assignment` — **только ручные решения**, автоматическое разнесение не хранится (DECISION-5): иначе ручное решение не
-  отличить от автоматического и при пересчёте после замены ОСВ оно затрётся. Поля (миграция AURORA-1751 + сторона):
-  `consolidation_version_id, statement_type, osv_entry_id, side (D | K), rule_id (NULL), action (ASSIGN | UNASSIGNED),
-  is_exclude (bool), created_by/at, updated_by/at`; `ASSIGN` — с `rule_id`, `UNASSIGNED` — без; уникальность
-  `(consolidation_version_id, statement_type, osv_entry_id, side)`. Поля `side` в DOC-272613 и в миграции нет — добавлено
-  контрактом, иначе у строки с дебетовым и кредитовым сальдо решения по двум позициям неразличимы. Нужны DBML v5.24, ORM-модель
-  в `src/models` и `audit_action` для решений по строкам.
+- **Кто что делает** (`[allocation-split]`, 29.10, уточнено 30.10): AURORA-1751 — разнесение строк (чистая функция), ручные
+  решения (`POST …/allocations`, `vgo_assignment`, аудит, DBML v5.24); AURORA-1540 — таблица, корректировка, экспорт поверх
+  функции 1751 (источник агрегатов в WIP #208 — `CorrectionAggregateSource`, его реализация вызывает функцию 1751).
+- **Граница — по интерфейсу функции, не по таблице.** AURORA-1540 не читает `vgo_assignment` и не знает её схему; он вызывает
+  функцию разнесения AURORA-1751 и получает готовые `rules[]`, `aggregates[]` и нераспределённые строки, где `side` у каждой
+  позиции (`CorrectionEntryOut`, `UnallocatedEntryOut`) уже разрешён — функция сама решает, как внутри сопоставить строку
+  свода с ручными решениями. Как 1751 хранит эти решения — её дело, в контракт с 1540 не входит.
+- `vgo_assignment` (AURORA-1751, внутреннее хранилище) — **только ручные решения**, автоматическое разнесение не хранится
+  (DECISION-5): иначе ручное решение не отличить от автоматического и при пересчёте после замены ОСВ оно затрётся. Одна
+  визуальная позиция обычно требует отдельной записи; строка с дебетовым и кредитовым сальдо одновременно даёт две позиции и,
+  как правило, две записи — у нераспределённой строки обычно одна. Решает 1751 сама (например, полем `side` и уникальностью
+  по нему); контракт этого не прописывает. Нужны DBML v5.24, ORM-модель в `src/models` и `audit_action` для решений по
+  строкам — всё на стороне 1751.
 - Разнесение — чистая функция в `api/src/domain/` (как `elimination_packing`): строки свода × правила × ручные решения →
-  агрегаты и нераспределённые строки (с `line_code` и `candidate_rule_ids`). Нынешняя упаковка считает каждое правило
-  отдельно (TODO в `intercompany_matrix.build_pairs`) — для таблицы корректировок строка должна попадать не более чем в одно
-  правило.
+  агрегаты и нераспределённые строки (с `line_code`, `candidate_rule_ids` и уже разрешённым `side` на каждой позиции).
+  Нынешняя упаковка считает каждое правило отдельно (TODO в `intercompany_matrix.build_pairs`) — для таблицы корректировок
+  строка должна попадать не более чем в одно правило.
 - Правила ББ 1 и 2 (DOC-274230) имеют свой расчёт и не наследуют min; что идёт в `eliminated_amount` по ним — по DOC-274230.
 - ОФР: тот же ответ с `statement_type = income` **(ждёт ответа в AURORA-1396)**; до него сервер может отдавать пустые
   `aggregates` и `unallocated` для `income`.