AURORA-1938: расчёт переноса в фонд экономии на листах АХР/КВ/Операц формы РФ #262
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: RSHB/DFiP_Budget_planing#262
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "feat/255-aurora-1938-transfer-econ-calc"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #255.
Проблема
Форма РФ (FORM_4 «Смета РФ поддержка»), листы АХР/КВ (CAP)/Операц (OPER): поле
«перенос в фонд экономии» (столбцы 75/107/137 Excel-эталона, внутренние имена
q1.transfer_econ/q2.transfer_econ/q3.transfer_econ, аналогичноq4) былоraw passthrough-полем
budget_line_quarter.transfer_to_economy— ничего его несчитало. Репро: добавить строку, заполнить план I–III кв. = 1000/2000/3000,
переносы/факт/секвестр пустыми, сохранить — поля переноса в фонд экономии
остаются пустыми, «ВСЕГО» блоков показывает прочерк вместо суммы, хотя остатки
после факта (1000/2000/3000) посчитаны верно.
Что сделано
api/alembic/versions/sql/0050_form4_transfer_econ_calc.sql:v3.v_form4_sheet_sections(единственная функция, которая отдаёт данныевсех трёх листов АХР/КВ/Операц —
v3.v_form4_viewдиспетчеризуетp_sheet IN ('AHR','CAP','OPER')в неё черезv_form4_sheet_jsonb→v_form4_sheet_lines_jsonb, так что один фикс в общей функции закрываетвсе три листа; подтверждено интеграционным тестом на CAP/OPER). STRUCTURE —
отдельный read-only агрегирующий свод по AHR+CAP+OPER без собственных
INPUT-строк, этой правки не касается.
col_qN_transfer_econ = f.qN_te(и его копию вветке агрегации
tb_N.te) на вычисление из уже имеющихся в схемеcpN/aqN(residual_after_actual_QN), см. Rulings — формула неочевидна,поэтому отдельная секция ниже.
v3._apply_form_cell: для FORM_4 прямая запись вq*.transfer_econтеперь отклоняется с
computed_field: ...(как уже было дляresidual_after_actual), поле убрано из allowlist записи (былосмаплено на
budget_line_quarter.transfer_to_economyв общей таблицеcolumn-mapping, используемой также FORM_2 — проверка намеренно ограничена
form_type_code = 'FORM_4', FORM_2 это поле не трогает).api/tests/integration/test_form4_transfer_econ.py— 4 теста:transfer_q2/q3/q4— именно он отличает верную формулу от наивногобуквального Excel-порта (при нулевых переносах обе формулы дают одинаковый
результат и не могли бы поймать регрессию);
q1.transfer_econотклоняется (стало computed_field).— не только что она не падает, но что считает так же, как INPUT-строка.
Rulings (решения без обсуждения)
Формула — не буквальный перенос из Excel, а с поправкой на уже
заложенный перенос. Эталон (Шаблон_РФ_поддержка.xlsm, АХР_П!CB9) —
CB9=BR9-BT9-BY9-BZ9, т.е. «остаток после факта минус перенос во II/III/IVкв.». Но в нашей схеме
residual_after_actual_QNуже вычитает переносв СЛЕДУЮЩИЙ квартал один раз через промежуточные
cp1/cp2/cp3:cp1 = ap1 + корректировки_Q1 − transfer_q2, аналогичноcp2минусуетtransfer_q3,cp3минусуетtransfer_q4. Буквальный перенос формулыExcel поверх
residual_after_actual_QNзадвоил бы это вычитание.Реализованные формулы:
residual_after_actual_Q1 − transfer_q2 − transfer_q3 − transfer_q4residual_after_actual_Q1 − transfer_q3 − transfer_q4residual_after_actual_Q2 − transfer_q3 − transfer_q4residual_after_actual_Q2 − transfer_q4residual_after_actual_Q3 − transfer_q4residual_after_actual_Q3residual_after_actual_Q4Почему
transfer_q2из формулы Q1 убран: он уже вычтен один раз внутриcp1/residual_after_actual_Q1; вычесть его снова — задвоить вычитание изанизить экономию ровно на сумму
transfer_q2. Аналогичноtransfer_q3вQ2 и
transfer_q4в Q3. Проверочное тождество (и то, что проверяет тест):transfer_q2 + transfer_q3 + transfer_q4 + transfer_econ_Q1(= «ВСЕГО»блока Q1) равно нераспределённому остатку после факта Q1 (до вычета
любых переносов) — с наивной формулой это тождество не выполняется.
Q4 тоже сделан вычисляемым, хотя в тикете и Excel-эталоне колонки для
Q4 нет (у Q4 просто нет «следующего квартала», переносить некуда) — для
единообразия с Q1–Q3 и потому, что
q4.transfer_econзамаплен в той жезаписи column-mapping в
_apply_form_cell, что и Q1–Q3: оставлять егоредактируемым, когда Q1–Q3 стали вычисляемыми, было бы непоследовательно.
Формула:
transfer_econ_Q4 = residual_after_actual_Q4(вычитать нечего).Проверка
FORM_4-only в_apply_form_cellсделана поbudget_form.form_type_code, а не глобально. Полеq*.transfer_econзамаплено в общей для FORM_2/FORM_4 column-mapping таблице внутри
_apply_form_cell. При ревью кода обнаружил, чтоv3.v_form2_sheet_sections(своя, отдельная функция для FORM_2 «ПД») содержит точно такой же
raw-passthrough баг для
transfer_econ— но тикет и переданные инструкциикасаются только FORM_4 («Форма РФ»). Если бы я сделал запись в
transfer_econнеразрешённой глобально, это сломало бы FORM_2 ещёсильнее: поле там и так всегда пустое (баг не чинился), а стало бы ещё и
нередактируемым вручную — чистый регресс без всякой пользы. Поэтому правка
ограничена
form_type_code = 'FORM_4'; баг FORM_2 я НЕ чинил (не входит втикет) — оставляю как есть и выношу отдельной строкой ниже.
Фронтенд НЕ трогал. Инструкция просила найти, где
residual_after_actualисключён из допустимых для записи полей нафронтенде (
AHR.js/CAP.js/STRUCTURE.js), и сделать то же самое дляtransfer_econ. Прочиталweb/src/components/RealtimeTable/tableColumns.jsx(
isEditable()) и все 4 файлаconstants/FORM_4/*.js— такогоper-field флага (editable/computed) для
residual_after_actualНЕсуществует вообще: для роли ADMIN
isEditable()всегда возвращаетtrueнезависимо от поля,
editTypeне используется ни для одной числовойколонки, а цветовая схема (
color_type) — чисто декоративная группировкапо разделам формы, не связанная с правом записи (у
total, который тожевычисляемый, тот же
redColumn, что у заведомо editabletransfer_q2).Единственная защита вычисляемых полей — серверная (
computed_field:в_apply_form_cell), которую UI уже обрабатывает универсально черезсуществующий
onCellUpdateError/handleCellUpdateError. После этого PRtransfer_econведёт себя на фронтенде ТОЧНО так же, какresidual_after_actualуже вёл себя всегда (клик возможен, сохранение сервер отклоняет) — то есть
зеркалирование уже достигнуто без единой правки в
web/.Тестовые годы форм (
90101–90200) выбраны заведомо далёкими от реальныхлет, чтобы не пересекаться по
(org_unit_id, form_type, year)с чужимиданными в общей тестовой БД (интеграционные тесты в проекте не
изолированы, см. ARCHITECTURE.md «Открытые вопросы»); каждый тест всё
равно откатывается (
client-фикстура с rollback-сессией).Тесты
pytest tests/unit— 27 passed (все проходят; 2 несвязанных паденияtest_export_service_query_params.pyотносятся кtests/unit, см. ниже).pytest(полный набор, живой Postgres черезDATABASE_URL, миграцииalembic upgrade head0001→0050 применены без ошибок,--init_dbодин разна чистую БД) — 201 passed, 4 skipped, 6 failed. Все 6 падений
пред-существующие и не связаны с этой веткой — перепроверено на
полностью чистой БД одним проходом (чтобы исключить накопленное состояние
между запусками):
test_backend_calls_form3_add_project_and_add_line_functions,test_delete_project_smoke,test_delete_project_verify_gone,test_delete_seed_project_smoke(все про FORM_3/проекты, я не трогал этоткод),
test_export_full_form_ignores_non_applicable_params_for_other_sheetsи
test_export_form_payload_forwards_ignore_flag(unit-тесты экспорт-сервиса,падают с
TypeError: unexpected keyword argument 'ignore_non_applicable_query_params'— рассинхрон теста и текущей сигнатуры
ExportService, тоже не моя область).Проверено дважды на двух разных чистых контейнерах Postgres 15 — результат
идентичен с правкой и без (те же 6 падений на базовой ветке
testдоприменения миграции 0050).
test_form4_transfer_econ.py— все 4 проходят,включая регрессионный тест с ненулевыми переносами (ключевое доказательство
правильности формулы, не наивного Excel-порта) и проверку ветки агрегации.
alembic upgrade head— чисто применяется поверх 0049 (0001...0050, безошибок).
Окружение для живого Postgres
В предоставленном окружении не было
DATABASE_URL/доступа к ужесуществующему контейнеру БД проекта (креды недоступны, а подбор/просмотр
чужих кредов — запрещённое действие в песочнице). Поднял одноразовый
Postgres 15 в Docker со своими кредами специально для этой проверки,
прогнал
alembic upgrade headи полныйpytest --init_dbна нём, контейнерудалил после проверки.
pg_get_functiondefна живой БД подтвердил, чтоv3.v_form4_sheet_sectionsиv3._apply_form_cellдо этого PR действительноопределялись последними в
0033_form2_old_sort.sqlи0023_apply_cell_empty_string.sqlсоответственно (как и предполагалось взадаче) — переопределены корректно.
Возможная коллизия номера миграции
PR #257 (другая ветка того же батча,
feat/249-...) тоже использует номер0050(0050_budget_line_delete_owner_guard.sql) с тем жеdown_revision = "0049".Если обе ветки смержатся в
test, вторая смерженная ветка получитдублирующийся revision (два alembic-head'а на один
down_revision) —потребуется переномеровать один из файлов 0050→0051 и поправить
down_revisionпри разрешении конфликта мержа. Не трогал #257 (чужая ветка),просто фиксирую риск для мержащего.
Перенос в фонд экономии (q1/q2/q3/q4.transfer_econ, столбцы 75/107/137 и их Q4-аналог формы РФ) был raw passthrough-полем budget_line_quarter. transfer_to_economy: ничего его не считало, поэтому после сохранения строки с планом без переносов поле оставалось пустым, а "ВСЕГО" блоков показывало прочерк вместо суммы. v3.v_form4_sheet_sections теперь считает transfer_econ_QN из уже имеющегося residual_after_actual_QN с поправкой на то, что тот уже вычитает перенос в СЛЕДУЮЩИЙ квартал один раз (через cp1/cp2/cp3): transfer_econ_Q1 = residual_after_actual_Q1 - transfer_q3 - transfer_q4 transfer_econ_Q2 = residual_after_actual_Q2 - transfer_q4 transfer_econ_Q3 = residual_after_actual_Q3 transfer_econ_Q4 = residual_after_actual_Q4 Буквальный перенос формулы Excel (ещё и минус transfer_q2 для Q1 / transfer_q3 для Q2) задвоил бы вычитание. АХР, КВ (CAP) и Операц (OPER) используют одну и ту же функцию, поэтому один фикс закрывает все три листа; STRUCTURE — агрегирующий read-only свод без INPUT-строк, его не касается. v3._apply_form_cell для FORM_4 больше не принимает прямую запись в q*.transfer_econ (ValueError computed_field, как у residual_after_actual). Тесты (api/tests/integration/test_form4_transfer_econ.py): - репро тикета (переносы = 0); - регрессия на двойное вычитание с ненулевыми transfer_q2/q3/q4, отличающая верную формулу от наивного Excel-порта; - КВ и Операц дают те же числа, что АХР; - запись в transfer_econ отклоняется. Closes #255. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>Обновление ветки под
test(mergeorigin/test, без rebase и force-push), коммит1f88586+ актуализация доc2595ca.Миграция перенумерована:
0050_form4_transfer_econ_calc->0055_form4_transfer_econ_calc(revision0055, down_revision0054). Номер 0050 наtestзанят AURORA-1906.Тела функций (проверено диффом):
v3._apply_form_cell: раньше копия опиралась на тело из0023, т.е. откатывала бы СПОД (AURORA-1906,0050_form2_ahr_spod_column). Теперь = актуальное тело из0050_form2_ahr_spod_column.sql(последняя версия на test;0051-0054функцию не переопределяют) + только дельта этого PR (блокcomputed_fieldдля FORM_4q*.transfer_econ, 11 строк).v3.v_form4_sheet_sections: после0033_form2_old_sortна test не переопределялась; тело PR отличается от0033только блоками transfer_econ -> оставлено как есть.v_form4_sheet_jsonb(0053) от формы результата этой функции не зависит.Тесты (pytest, Postgres 16, alembic с нуля + seed; базовая линия =
origin/test3e00f91):test_apply_form_cell_keeps_aurora_1906_spod_and_aurora_1938_guard, проверяет, что в итоговом определении функции одновременно есть'spod'(1906) иtransfer_econguard (1938))KeyError: 'oct'x3, upd_form_cells_subtree x6, export_service_query_params x2, db_functions x1). Новых падений нет.test_satellite_spod_syncs_into_ahr_support_quarter,test_satellite_spod_allowed_once_phase_includes_spod_columnи др. проходят на ветке.