Отчёт о приёмке. Конструктор отчётов по энергобиллингу РРЭ

Дата отчёта: 12.08.2026. Проект: sol-msqcc8pt-2ja. Ветка: u/5, коммит на момент прогона d88e2a4. Составил: менеджер проекта по фактическим результатам шагов 2–5.

Все цифры в отчёте — из реальных прогонов в рабочей копии (evidence/), а не из ожиданий задания. Раздел 7 «Открытые бизнес-вопросы» ответа от исполнителя не содержит намеренно — это решение заказчика.

1. Вердикт по критериям приёмки заказчика

Коротко: расчётное ядро и выгрузки приняты фактом (тесты, сверка, браузер). Два узла не закрыты и оба зависят не от кода: нет документа ТЗ v3.2, по которому просили сверяться, и не подтверждён собственный адрес развёртывания (проверяется после сборки образа платформой).

2. Матрица «пункт задания → статус»

Источник пунктов — согласованное ТЗ проекта (.project-os/project/tz.md, согласовано d.muzharov@devkz.ru 12.08.2026, отпечаток 268ea05d) и формулировка задачи заказчика.

2.1 Состав работ

Про пункт 3 — важно для заказчика. Файл с названием ТЗ_РОСХИМ_v3_2_ПРАВКИ_ПО_АРХИТЕКТУРНОМУ_РЕВЬЮ.docx до исполнителей не дошёл: в рабочей копии проекта и в репозитории конструктора его нет. Дополнительно: единственный доступный на платформе документ «ТЗ Росхим v3.2 — архитектурное ревью» относится к другому продукту — «Мультиагентный ситуационный центр управления простоями вагонов», к энергобиллингу РРЭ он отношения не имеет. Похоже на перепутанный файл. Что нужно: прислать именно ТЗ конструктора отчётов РРЭ версии 3.2 — построчная сверка займёт один шаг.

2.2 Функциональные требования продукта (проверены запуском)

3. Автотесты — фактический прогон

Прогон выполнен на текущем коде ветки (коммит d88e2a4, уже с правками шага 4):

$ python3 -m pytest -q
........................................                                 [100%]
40 passed in 0.95s

Прогон шага 4 (коммит 3dff6b9) — 40 passed in 1.00s, файл evidence/pytest-run.txt. Ожидание заказчика — 40 passed. Совпало, расхождений нет. Состав: test_punc.py + test_app.py, из них 18 тестов работают по HTTP на реально поднятом сервере.

4. Сверка ПУНЦ — фактические цифры

$ python3 reconcile_punc.py
Сверено показателей: 156   расхождений: 0
ИТОГ: СОШЛОСЬ ПОЛНОСТЬЮ

Полный протокол построчно — evidence/reconcile-punc-run.txt. Ожидание заказчика — 156/156 без расхождений. Совпало, расхождений нет.

• эталон: reference/etalon-punc-avgust-2024.xlsx, лист «август 2024», договор «РУСЭНЕРГОСБЫТ» (Смоленск);
• допуски: цены 1e-6 руб/МВт·ч, стоимость 1e-4 руб;
• сверяются: объём, все компоненты цены (СВНЦ на ОРЭ, ЕКТ передача, сбытовая надбавка, иные услуги, УИРП, скидка), ПУНЦ итог и пять составляющих стоимости — по каждой строке всех четырёх секций.

Ограничение области сверки: сверен один договор за один месяц — других эталонов заказчик не давал. На строках с прочерком в эталоне сверка проходит по допущению «прочерк = 0» — это открытый вопрос № 1 (п. 7).

5. Проверка в браузере — что делали руками

Chromium 151.0.7922.34 (headless shell, playwright-core 1.62.1), окно 1500×1000, реальные клики и выбор в списках. Проверялось на живом стенде https://sol-mspg313y-6zr.apps.sreda-ai.ru/ (скриншоты live-) и на рабочей копии кода http://127.0.0.1:8642/ (скриншоты local-). Результаты совпали по всем сценариям, кроме вкладки агента (дефект UI-1).

Ошибок JavaScript и незавершённых запросов за весь прогон — ноль. Скриншоты: web/ui-shots/ (открываются по ссылке проекта) и evidence/ui/; сводная страница — web/ui-check.html; машинные логи — evidence/ui/-ui-log.json.

Содержимое выгрузок проверено глазами, а не по факту скачивания: CSV — 4 строки данных, значения совпали с экраном до знака (Электроэнергия;17665007.95598;55355192.82). XLSX ПУНЦ — строка «3ЦК, ВН, более 10 МВт, ОРЭ»: 17 663 257,95598 × 2,61121 = 46 122 475,807235 руб., то же значение в колонке «ИТОГО стоимость» и в UI; разбивка 41 424 932,354 + 4 612 583,183 + 84 960,271 + 0 сходится с итогом.

Дефекты интерфейса (найдены, не исправлены — требуют решения заказчика)

Дополнительно, по API: битый JSON в теле запроса и нечисловой limit возвращают 500 вместо 400 (evidence/edge-cases.txt). На данные и безопасность не влияет, но по-хорошему это 400.

6. Перечень внесённых правок

Код продукта с нуля не переписывался — правки точечные, зафиксированные правила витрины (D_Type='АПП', R_CalcName='Текущий расчет', исключение строк «Средневзвешенный%») не трогались.

7. Открытые бизнес-вопросы — нужно решение заказчика

Ответов исполнителя здесь нет намеренно: это вопросы учётной методики, а не разработки. Пока ответа нет, работает текущее поведение — оно указано отдельной строкой, чтобы вы видели, что именно считается сейчас.

Вопрос 1. «Прочерк» в эталоне — это ноль или «показатель неприменим»?

• Где влияет на цифры. Компоненты цены у мощности АТС: передача, сбытовая надбавка, иные услуги, УИРП — в эталоне заказчика прочерк, в выгрузке 00101 этих компонентов нет. Также «ЕКТ передача» и «Скидка» у секции «Электроэнергия (потери)».
• Варианты трактовки. (а) прочерк = 0 — компонент входит в расчёт нулём; (б) прочерк = «нет данных» — строка не должна участвовать в расчёте, а отсутствие компонента должно попадать в предупреждения; (в) прочерк = «показатель к этой позиции неприменим» — компонент вообще не выводится в отчёте.
• Как считается сейчас. По варианту (а): прочерк приравнен к нулю. Именно на этом допущении сверка даёт 156/156.
• Что заблокировано до ответа. Трактовка отчёта на данных, где компонент действительно отсутствует по ошибке загрузки: сейчас такая дыра молча превратится в ноль и не будет видна. Проверка ПУНЦ на полном объёме БД до ответа не имеет смысла.

Вопрос 2. КАПП/КСЧФ замещают АПП или дополняют его?

• Где влияет на цифры. Витрина берёт только D_Type='АПП'. По договору «РУСЭНЕРГОСБЫТ» есть КАПП, который содержит полную переписанную строку, а не дельту: по одной позиции 5 928 → 7 000 кВт·ч. Затрагивает объём и всю стоимость по этой позиции.
• Варианты трактовки. (а) КАПП — актуальная версия документа: надо брать КАПП вместо АПП, тогда текущая витрина отдаёт устаревший факт; (б) КАПП — отдельное корректирующее начисление: надо суммировать АПП + КАПП, тогда объём задваивается, если КАПП переписывает строку целиком; (в) правило зависит от типа документа и сценария расчёта — нужен ваш регламент.
• Как считается сейчас. Только D_Type='АПП', КАПП и КСЧФ в расчёт не попадают. На отчёт ПУНЦ это не влияет: эталон сам построен на АПП.
• Что заблокировано до ответа. Любой отчёт, который претендует на «фактические начисления с учётом корректировок». Пока в конструкторе есть только «как в АПП».

Вопрос 3. Два одинаковых КАПП (документы № 24 и № 25) — версии одного документа или два начисления?

• Где влияет на цифры. Содержимое документов идентично. Как только корректировки начнут учитываться (см. вопрос 2), от ответа зависит, попадёт корректировка в расчёт один раз или два.
• Варианты трактовки. (а) версии одного документа — брать последнюю, дубль отбрасывать; (б) два самостоятельных начисления — суммировать оба; (в) технический дубль загрузки — исключать на уровне ETL и сигналить об ошибке выгрузки.
• Как считается сейчас. Никак: оба документа отфильтрованы вместе со всеми КАПП.
• Что заблокировано до ответа. Правило дедупликации документов в ETL и витрине. Без него включение корректировок даёт риск двойного счёта.

Вопрос 4. Одноимённые позиции с разными ценами — по какому признаку их сопоставлять?

• Где влияет на цифры. В секции «Электрическая энергия» позиция «3ЦК, ВН, от 670 до 10 МВт» встречается дважды: ПУНЦ 4,317282 при объёме 25 550 и ПУНЦ 2,622554 при нулевом объёме. Обе строки есть в эталоне и обе сходятся, но в разделе «Сравнение периодов» такие строки сейчас сопоставляются по порядку следования и помечаются «(позиция N)».
• Варианты трактовки. (а) есть дополнительный признак различения (точка поставки, ставка, договорной раздел, уровень напряжения) — назовите поле, будем сопоставлять по нему; (б) строки надо схлопывать в одну со средневзвешенной ценой; (в) сопоставление по порядку допустимо, тогда нужен ваш регламент на случай, когда число одноимённых строк в периодах разное.
• Как считается сейчас. Сопоставление по порядку с пометкой «(позиция N)».
• Что заблокировано до ответа. Достоверность раздела «Сравнение периодов» на реальных данных: при разном порядке или разном количестве строк дельты поедут по неверной паре. Приёмка раздела «Сравнение» — после ответа и после получения выгрузки за второй месяц.

8. Что нужно от заказчика, чтобы закрыть остальное

1. Ответы на 4 вопроса из п. 7 — от них зависит методика, а не код.
2. Файл ТЗ v3.2 именно по конструктору отчётов РРЭ — переданный документ до проекта не дошёл, а найденный на платформе одноимённый документ относится к другому продукту (см. п. 2.1). Без него построчную сверку сделать нечем.
3. Выгрузка за второй месяц (например, сентябрь 2024) — иначе раздел «Сравнение» принимать не на чем.
4. Решение по UI-1 — какая версия интерфейса аналитика эталонная: та, что на стенде sol-mspg313y-6zr, или та, что в репозитории. Развёртывание кода из main откатит вкладку «Аналитик».
5. Ключ модели для ИИ-режима агента, если он должен работать на стенде (llm: false сейчас).

9. Ограничение области

Это МВП на семи выгрузках за один месяц (август 2024), один договор сверен с эталоном. Перед расчётами, за которые отвечают деньгами, нужна сверка на полном объёме продуктивной БД и проверка цифр специалистом по энергозакупке. Независимого код-ревью не проводилось.

10. Финальная приёмка шага 7 — прогон на релизной сборке

Отчёт опубликован страницей: ПРИЁМКА-ОТЧЁТ.md → web/report.html рендерится скриптом render_report.py (без внешних зависимостей, пересборка одной командой). Страницу и конструктор отдаёт один и тот же сервис: / — конструктор, /report.html (и /report) — этот отчёт, /ui-check.html — протокол проверки UI, /ui-shots/*.png — скриншоты.

Про kind: static. В deploy.yaml оставлен kind: python, порт 8080, persistent: true: переключение манифеста на static погасило бы сам сервис, а его работа — критерий приёмки заказчика. Отчёт при этом статический и открывается по публичному адресу тем же приложением, отдельного развёртывания не требует. Раздача статики ограничена каталогом web/ и типами html/css/js/png/svg/ico, выход за каталог (..) даёт 404 — проверено запросом.

Прогон выполнен реальными кликами в Chromium 151.0.7922.34 (deploy/final_check.js, протокол — evidence/final/final-check.txt, скриншоты web/ui-shots/final-*.png):

Повторные прогоны на этой же сборке: 40 passed in 0.99s, сверка ПУНЦ — Сверено показателей: 156 расхождений: 0, «СОШЛОСЬ ПОЛНОСТЬЮ». Ошибок JS на страницах не зафиксировано.

Что осталось вне нашего контроля: сборку образа и публикацию адреса sol-msqcc8pt-2ja.apps.sreda-ai.ru платформа выполняет после завершения прогона — до этого адрес законно не отвечает.