movilba
MOVILBA-244
Libro: ID_ADAS con '########' (desborde de Excel) en 42 filas - pregunta al tracker de Eugenia
Done normal
rmresearcher-mba-l-cc
Found during the MOVILBA-204 render pass: the book's ID_ADAS cell carries a run of '#' characters (Excel column-overflow display captured as text) on 42 of 5370 rows of snapshot 10 (raw_id_adas ~ '^#+$'); 0 in raw_id_mdvr, 0 in raw_id_canbus. Imported verbatim, so the ficha shows 'ID ADAS: De ################ A 2025...'. This is a value the book lost, not a contradiction: it is a question for Eugenia (which ID ADAS goes on those rows, listed by dominio + fecha_alta), added to the tracker xlsx per the tracker SOP (diff against the dated copy first, never write in her answer column). No app change; no user-facing copy about incomplete data.
Activity
-
db02: the 42 cells are data_type 's' (literal text), exactly 16 '#' each - stored content, not an Excel width artifact (overflow is a screen effect, never persisted, and would vary in length). Second, related population: 50 cells (49 ID ADAS + 1 ID MDVR) are numeric in the book holding 2.51616442111e+55 - a 56-digit id cannot survive a double, precision died inside the workbook. Both go to Eugenia; neither is repairable on our side.
-
coder03-mba-l-cc / coder
-
db03-mba-l-cc
-
db04-mba-l-ca
-
researcher-mba-l-cc / solo
-
coder03 11:11 ART: reassigned db04 -> researcher (db04 carries 30 items). Verify the 42 overflow cells against the pinned libro digest, then write the Eugenia question for the tracker; coder03 writes the XLSX.
-
researcher-mba-l-cc 2026-10-08T11:17:14-03:00. Re-verified against the current pinned libro digest (/data-lezama/movilba/libro/2026-10-06-1140-parque-rutap.xlsx, md5 eb2e2683..., sheet Base, 6909 rows, header row 2 - matches db03's snapshot 11 reference from the MOVILBA-401 thread today). Read directly with openpyxl, no DB query. ORIGINAL CLAIM (42 ID_ADAS rows matching ^#+$, snapshot 10, 2026-09-05) DOES NOT REPRODUCE: 0/6909 rows in the current book have a '#'-run in ID ADAS, ID MDVR, or ID CANBUS. The overflow symptom is gone - either RUTAP corrected it in a later publish, or those exact rows aged out/were superseded between snapshot 10 and 11. This specific 42-row population is stale; no Eugenia question needed for it. RELATED DEFECT STILL LIVE, SMALLER: the sibling bigint-precision-loss population (same root cause - an ID too long for Excel's double-precision float, named in the same 2026-09-05 note at "50 cells (49 ADAS+1 MDVR), 2.51616442111e+55") now measures 7 rows (6 ID ADAS + 1 ID MDVR, one domain AE100DI hits both columns), values in the ~1e22 / 23-24-digit range - NOT confused with legitimate IMEI-shaped 15-digit values, which I excluded (threshold: scientific notation or >=17 raw digits only): | dominio | fecha_alta | columna | valor roto | |---|---|---|---| | AG336IX | 2025-12-12 | ID ADAS | 2.51216442111E+22 | | AE100DC | 2025-12-12 | ID ADAS | 2.51616442111E+22 | | AH791QZ | 2025-12-26 | ID ADAS | 24481644211100050810064 | | AE631MA | 2026-02-23 | ID ADAS | 25161644211100000810069 | | AE100DI | 2026-04-17 | ID ADAS | 25161644211100000810050 | | AE133ND | 2026-03-09 | ID ADAS | 25161644211100000810072 | | AE100DI | 2026-04-01 | ID MDVR | 25161644211100000810050 | These are not repairable on our side (same ruling as the 2026-09-05 note) - this IS the surviving Eugenia question, by dominio + fecha_alta + column, same shape as the original ticket asked for. No app change; no user-facing copy about incomplete data. Deliverable for the tracker cell: coder03 writes these 7 rows into the XLSX per the tracker SOP (diff against the dated copy first, never write in her answer column). The original 42-row question is withdrawn as non-reproducing, not forwarded.
-
AE016ZA 142 resolved, 42-overflow claim non-reproducing, 7-row precision-loss list handed to coder03 for tracker. See bwi note.
-
coder03 11:43 ART: tracker written - Pendientes row MOVILBA-244 for Eugenia, 7 cells (6 ID ADAS + 1 ID MDVR) with Excel precision loss, import as stated. Archive archived/2026-10-08-1142-pre-244-*.xlsx, after-copy 2026-10-08-1142-todo-rutap-importacion-prestaciones.xlsx. Pendientes 17 -> 18. Written, not yet asked: needs upload.
-
2026-10-13 pinned workbook SHA256 81874621...bd20 direct Base XML check: the seven previously listed cells now all have t=s (shared-string type). Five contain full 23-digit text; length alone does not prove precision loss. Two still contain literal scientific notation: AG336IX 2025-12-12 ID ADAS 2.51216442111E+22 and AE100DC same date 2.51616442111E+22. Stakeholder pending CSV question narrowed to those two exact IDs; ask Eugenia for complete IDs as text. db04/audit independent check requested. No DB write.
-
2026-10-16 stakeholder-answer reconciliation by coder03assistant-mba-l-ca. Evidence: /data-lezama/movilba/import-reports/2026-10-16-1207-todo-rutap-importacion-prestaciones(Pendientes).csv; SHA256 e3691062fe74a596f704854e7ab23322435745ade04b70504fd85b94d44b0d50; F18 exact text: 'AG336IX = 25121644211100000000000 (NO puedo copiar y pegar no me permite. '. The response names only AG336IX; the question keys it to ID ADAS dated 12/12/2025. AE100DC (same date) remains unanswered. The 23-digit string is stakeholder-provided text in this export, not independently authenticated/corrected source content or recovered precision. It numerically expands the scientific literal 2.51216442111E+22; that equivalence cannot establish lost digits. Do not synthesize AE100DC or infer an exact ID from a floating-point value. Preserve the 2026-10-14 narrowed two-cell follow-up; no workbook read, import, source/DB/code correction. Original 42-hash-cell diagnosis remains closed/non-reproducing, so MOVILBA-244 stays done; the surviving partial-answer follow-up is not declared resolved.
task
5w ago by wi-cli-venus
1w ago
2026-10-08 14:17