Прод-баг #2126: water_supply_reserves содержал мусор — резерв = № п/п формы
(1.1, 1.3, 2.18…), а рубрики анкеты («Количество поданных…»), «Итого:» и шапки
попадали в поле system_name. Итог §3 показывал «водоснабжение 1,1 / водоотведение
3,0 тыс. м³/сут» (номера строк, не резервы).
Корень: extract_water_rows брал «первую текстовую ячейку» как имя и «первое число
строки» как резерв. РЕАЛЬНАЯ сетка (снята с прода 2026-07-03 через docker exec тем
же путём, что лоадер) устроена иначе, причём две страницы имеют РАЗНЫЙ layout:
- водоснабжение: 6 колонок, каждый ЦСВ = 4 строки показателей; резерв — строка,
где col2 = «Резерв мощности централизованной системы…», значение в col4;
- водоотведение: 5 колонок, имя системы — отдельная строка-заголовок
(«Централизованная система…»/«Транспортировка сточных вод…»), резерв в col3.
Переписал парсинг column-aligned по подписям шапки и метке показателя: детект
layout по строке-шапке, резерв ТОЛЬКО из строки «Резерв мощности…» (+ защита
ед.изм. «тыс…м3/сут»), заявки/отказы — из своих рубрик. Шапки, «Итого:», легенда
отфильтрованы. Нули («Отсутствие резерва мощности», 0,0) сохраняются честно
(0.0 + note), как в eias_heat_loader после того же класса бага. Дедуп байт-в-байт
одинаковых имён суффиксом « (N)» (защита UNIQUE), warning при 0 записей.
Прод-verify нового парсера на живом docx: water → 33 ЦСВ (ЗФС,ГСВ −168,5; Изоплит
0,0; Шабровский 1,03; ПТВ 73,34), sewerage → 6 систем (Южный бассейн −296,85;
Северный 2,02). Ни один резерв больше не равен № п/п.
Тесты: фикстуры из РЕАЛЬНОЙ сетки обоих layout (шапка + ЦСВ + рубрики + «Итого:» +
легенда + ноль-резерв); ассерты — резервы из правильной колонки, мусор отфильтрован,
нули сохранены; end-to-end через load_water_reserves_from_docx. 41 passed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
bot-backend
5d34bb7833