diff --git a/context/05-domain-rules.md b/context/05-domain-rules.md index 0e1c8a9..9a35ebb 100644 --- a/context/05-domain-rules.md +++ b/context/05-domain-rules.md @@ -1021,7 +1021,8 @@ OQ-145); тем же правилом сервисы разрешают ничь `min` — меньшая сторона в допуске, иначе 0; `manual` — 0; `min_or_full` (правило 2 после правки seed в AURORA-1546) — меньшая сторона при обеих > 0, `amount_1` при пустой стороне 2, порога нет: `exceeds_threshold = false`, статус `AUTO` при обеих сторонах, `ONE_SIDED` при пустой стороне 2 (`eliminated_amount = amount_1`). Функция — - `domain/corrections.automatic_elimination`, общая для таблицы корректировок и КФО. Для ОФР режимы `full` и `min` и + `domain/corrections.automatic_elimination`, общая для таблицы корректировок и КФО (ББ; у ОФР таблица автосумму не + считает, см. блок «КФО», п. 4, I-2). Для ОФР режимы `full` и `min` и отсутствие автосуммы у правил 2 и 5 — блок «КФО», п. 4. - **Порог отклонения агрегата** (`exceeds_threshold`, не путать с контролем выше): `deviation_percent = |ΣA − ΣB| / min(ΣA, ΣB) × 100` сторон агрегата (§5, п. 1/2a); реализовано **строго больше 5 %** (R-35, `domain/corrections.py`, @@ -1114,13 +1115,18 @@ OQ — менять по ответу. гудвилл, автосуммы и корректировки. Seed правил ББ версии 1 (`arm-core/api/seed/core/elimination_rules_v1.yaml`, правка — в AURORA-1546, на месте, без - новой версии правил: верифицированных версий нет); правила ОФР 1–5 версии 1 — отдельный seed - `elimination_rules_income_v1.yaml` (§4, идемпотентный: повторный seed ничего не дублирует и правила ББ не меняет): правило 2 — `elimination_mode: min_or_full`, + новой версии правил: верифицированных версий нет): правило 2 — `elimination_mode: min_or_full`, `article_2_line: "1310/1350/1370"`. **Правило 1 остаётся `manual`**: по DOC-274230 обе его суммы — у компании 2 (Кт 76.7.1 − Дт 76.7.9 с каскадом 1150 → 1450 → 1550), а сторона агрегата устроена «компания 1 — сторона 1, компания 2 — сторона 2»; автосумма правила 1 — после переработки seed (OQ-193), до того — корректировкой. + Правила ОФР 1–5 версии 1 — отдельный seed `elimination_rules_income_v1.yaml` (§4, идемпотентный: повторный seed + ничего не дублирует и правила ББ не меняет). - Автосумма — **одна функция домена** для таблицы корректировок и КФО (блок «Корректировка», `eliminated_amount`). + Автосумма — **одна функция домена** для таблицы корректировок и КФО (блок «Корректировка», `eliminated_amount`) — + **только для ББ**. Для ОФР (I-2, отложено): в таблице корректировок `eliminated_amount`/`status` не вычисляются + (0 / `MANUAL`), порог 5 % (`exceeds_threshold`) к ОФР не применяется; автосуммы ОФР (правило 1 — выручка без НДС, + правило 3 — вся сторона 1, правило 4 — `min` со знаком) считает только источник КФО (`KfoIncomeSource`) и показывает + только КФО. Единая функция для таблицы и КФО по ОФР — после доработки. 5. **Корректировка заменяет автосумму.** Применённая корректировка агрегата отменяет его автосумму целиком и к ней не прибавляется (DOC-274636, допущение 4; DOC-272613: корректировки не меняют суммы сторон). Исключения: компания 1 — статьи `debit[]` (основная, затем дочерние), компания 2 — `credit[]`, суммы как введены. Если заполнены обе стороны diff --git a/context/07-open-questions.md b/context/07-open-questions.md index 8caea2a..598ff96 100644 --- a/context/07-open-questions.md +++ b/context/07-open-questions.md @@ -204,3 +204,4 @@ | OQ-196 | Ключ «того же периода» для одного актуального среза и блокировки верификации: ГК × дата (решения Excel Р-35/Р-36) или ГСК × дата (ЕХ ТЗ 6.2, 6.4)? | DOC-274686, вопрос 2; AURORA-1397 | §15 п. 2; AURORA-2002 | открыт, вопрос заказчику; допущение: ГК × дата для «один актуальный» и `superseded_by_snapshot_id`, нумерация — по ГСК (индекс модели) | | OQ-197 | Срез при верификации не записался: повторять запись с признаком «не передана в ЕХ», делать верификацию и запись одной операцией или не повторять? | DOC-274687, вопрос 6; Excel 13.10.2026 («механизм повторной передачи не определён») | §15 п. 9 | открыт, вопрос заказчику; допущение: верификация остаётся, признак вычисляется (VERIFIED без среза), такая версия блокирует финал следующей | | OQ-198 | Нужен ли PDF «Консолидированная отчётность» в ЕХ (макет [83-01]) и что в нём? | DOC-274687, вопрос 2; макет [83-01]; ЕХ ТЗ 6.7.3 | §15 п. 10 | открыт, вопрос заказчику (продолжение OQ-39); допущение: не формируется и не хранится, xlsx — из payload на лету | +| OQ-199 | Подтверждённая форма ББ/ОФР без колонки на конец отчётного квартала (или с несколькими такими колонками): нули в КФО молча или предупреждение (предложенный код `FORM_COLUMN_MISSING`)? | Финальное ревью arm-core #251 (I-3), `services/kfo.py` | §8 «КФО» | открыт; допущение: нули без предупреждения | diff --git a/dev/api-contract-corrections.md b/dev/api-contract-corrections.md index 0b94283..709e02f 100644 --- a/dev/api-contract-corrections.md +++ b/dev/api-contract-corrections.md @@ -93,7 +93,9 @@ AURORA-1540 и AURORA-1751 (29.10): разнесение строк и реше `EMPTY_CORRECTION`. - `line_code` — код строки формы ББ (ОФР) этой компании; не из формы — 422 `INVALID_LINE_CODE` с `detail.line_code`. Сумма — строка, не больше 16 цифр до запятой и двух после (`numeric(18,2)`); у ББ ≥ 0 (это уменьшение статьи), у ОФР - допустимы и отрицательные суммы (DOC-277424 §7.5). Иное — 422 массивом pydantic. + допустимы и отрицательные суммы (DOC-277424 §7.5). Иное — 422 массивом pydantic. У ОФР сумма — **величина исключения + в конвенции оборота**, а знак расходных строк (2120, 2210, 2220, 2330, 2350) сервер применяет сам + (`domain/kfo.py`, `apply_income_exclusions`): клиент сумму заранее не инвертирует. - `comment` обязателен всегда, пустой после обрезки — 422 `COMMENT_REQUIRED` (DOC-272613, ответ п. 6); не длиннее 1000 символов (как комментарий смены статуса), длиннее — 422 массивом pydantic. - Сохранение сразу применяет корректировку — `status = APPLIED`; поля `status` в теле нет (ответ п. 9). `DRAFT` есть в модели, @@ -215,7 +217,7 @@ deviation_amount money deviation_percent percent | null к меньшей стороне; null — меньшая сторона ≤ 0 exceeds_threshold bool deviation_percent ≥ 5, или одна сторона пуста при ненулевой другой; у min_or_full — всегда false status "AUTO" | "DISCREPANCY" | "ONE_SIDED" | "MANUAL" как EliminationTotalItemOut -eliminated_amount money автосумма агрегата по режиму правила (§8 «КФО» п. 4) — её исключает КФО, если нет корректировки +eliminated_amount money автосумма агрегата по режиму правила (§8 «КФО» п. 4) — её исключает КФО, если нет корректировки; только ББ, у `income` всегда 0 (I-2) composition_changed bool состав или суммы изменились после применённой корректировки (ответ 5; ответ п. 10 — подсвечивать) correction CorrectionOut | null действующая корректировка (APPLIED; DRAFT — зарезервирован) ``` @@ -298,7 +300,10 @@ rule_id? (uuid, для ASSIGN)}`. `eliminated_amount = min`, `status = AUTO`; сторона 2 пуста → `eliminated_amount = amount_1`, `status = ONE_SIDED`; сторона 1 пуста → 0, `ONE_SIDED`; `exceeds_threshold = false` всегда (порога 5 % у правила нет). **Правило 1** остаётся `manual` (`status = MANUAL`, 0) до переработки seed (OQ-193). Автосумма — **та же функция, по которой считает КФО**: - что аналитик видит в `eliminated_amount`, то и исключает КФО, если корректировки нет (корректировка её заменяет). + что аналитик видит в `eliminated_amount`, то и исключает КФО, если корректировки нет (корректировка её заменяет) — + **для ББ**. Для ОФР (I-2, отложено) таблица автосумму не считает: `eliminated_amount = 0`, `status = MANUAL`, + `exceeds_threshold` (порог 5 %) не применяется; автосуммы ОФР (правило 1 — выручка без НДС, правило 3 — вся + сторона 1, правило 4 — `min` со знаком) вычисляет и показывает только КФО (`KfoIncomeSource`, `services/kfo.py`). - ОФР: тот же ответ с `statement_type = income`; правила 1–5 версии 1 заведены seed, агрегаты — по оборотам, позиции D/K независимы (§3.5, `05-domain-rules.md` §4 и §5 п. 2b, DOC-277424). ## 6. Пример