From ecbe5297d869834112f78eff82a04d0994cd715f Mon Sep 17 00:00:00 2001 From: Andrey Epifancev Date: Fri, 30 Oct 2026 12:09:32 +0400 Subject: [PATCH] =?UTF-8?q?=D0=9A=D0=BE=D0=BD=D1=82=D1=80=D0=B0=D0=BA?= =?UTF-8?q?=D1=82=20=D0=BA=D0=BE=D1=80=D1=80=D0=B5=D0=BA=D1=82=D0=B8=D1=80?= =?UTF-8?q?=D0=BE=D0=B2=D0=BE=D0=BA:=20=D0=B3=D1=80=D0=B0=D0=BD=D0=B8?= =?UTF-8?q?=D1=86=D0=B0=201540/1751=20=E2=80=94=20=D0=BF=D0=BE=20=D1=84?= =?UTF-8?q?=D1=83=D0=BD=D0=BA=D1=86=D0=B8=D0=B8,=20=D0=BD=D0=B5=20=D0=BF?= =?UTF-8?q?=D0=BE=20=D1=82=D0=B0=D0=B1=D0=BB=D0=B8=D1=86=D0=B5=20(#188)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit По замечанию Ани (Потапова): §5 описывал схему vgo_assignment так, будто AURORA-1540 должен её читать и понимать поле side. Это неверно — 1540 работает только через CorrectionAggregateSource, то есть через функцию разнесения 1751, и получает от неё уже готовые позиции с разрешённым side. Как 1751 хранит решения внутри vgo_assignment (одна запись на позицию или две — для строки с дебетовым и кредитовым сальдо одновременно) — её дело, не часть контракта с 1540. Co-Authored-By: Claude Sonnet 5 --- dev/api-contract-corrections.md | 29 ++++++++++++++++------------- 1 file changed, 16 insertions(+), 13 deletions(-) diff --git a/dev/api-contract-corrections.md b/dev/api-contract-corrections.md index f28f62e..59d8e5b 100644 --- a/dev/api-contract-corrections.md +++ b/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`. -- 2.47.2