RUTAP: 50 celdas con precision destruida por Excel (float 2.51616442111e+55) en ID ADAS e ID MDVR - dato irrecuperable, solo Eugenia puede reponerlo

Sub-tickets

Activity

• wi-cli-venus created · 2026-08-20
• wi-cli-venus commented · 2026-08-20
  CAUSA RAIZ UNICA COMPARTIDA con el ticket hermano (74 precision perdida / 75 ################): 42 dominios con ######## y 48 con precision perdida son practicamente los mismos vehiculos (AE100Dx, AE631Mx, AE816Px) - un solo lote de instalacion cargado con la columna ID ADAS sin formato TEXTO, roto de dos maneras distintas segun el ancho de la celda al guardar. Si Eugenia corrige el FORMATO de la columna, los dos mueren juntos; si solo reescribe los valores, la proxima exportacion los rompe de nuevo. Parecen dos tickets, es una sola causa. IMPACTO HOY = CERO en MovilBA: ninguna de las 92 celdas esta en un tramite VIGENTE, todas son de tramites cerrados, y nosotros tomamos el vigente. Lo que se pierde es el identificador historico.
• wi-cli-venus commented · 2026-08-20
  Evidencia de que la causa es el PROCESO DE EXPORTACION y no una carga manual: se corrio el scanner de contaminacion contra DOS libros independientes, el del 18/08 (2026-08-18-parque-rutap-elazar.xlsx) y el del 20/08 (2026-08-20-0211-Parque_RUTAP.xlsx). Conteos IDENTICOS clase por clase: 15499 celdas contaminadas, 11907 familia AL LIBRO y 3592 HIGIENE, con 50 de precision perdida y 42 de ################ en los dos. Si los defectos los hubiera introducido una persona editando celdas, dos exportaciones distintas no darian el mismo numero en cada clase. CONSECUENCIA: reescribir los valores no alcanza, la proxima exportacion los reproduce igual. El unico arreglo que se sostiene es poner la columna ID ADAS en formato TEXTO en el sistema de ORIGEN y despues recargar los valores. 74 y 75 son dos sintomas de una sola causa: corregido el formato, mueren juntos. Medido por coder02-mba-l-cc 2026-08-20, reproducible con: python3 tools/rutap-snapshot-import.py <libro>
• wi-cli-venus assigned · 6w ago
  db03-mba-l-ca / db
• wi-cli-venus note · 6w ago
  Contexto medido 2026-08-31 (db02-mba-l-cc, MOVILBA-154): tres duplicados del libro que Eugenia borro el 08-26 (AF821DV, AF875JQ, AF899TF) diferian de su gemelo SOLO por un cero a la izquierda en ID ADAS (013040 vs 13040). Misma familia texto-vs-numero que este item. Confirma que la variante de formato no es cosmetica: genero filas duplicadas en el libro que hubo que borrar a mano.
• wi-cli-venus progress · 5w ago
  Eugenia actualizó el tracker 2026-09-10 14:41: Edu está corrigiendo en Parque los ID ADAS guardados como ################ o notación científica. Fuente: /data-lezama/movilba/import-reports/2026-09-10-1441-todo-rutap-importacion-prestaciones.xlsx, hoja Para Eugenia, pregunta 2. Mantener abierto hasta verificar un nuevo snapshot RUTAP.
• wi-cli-venus assigned · 4w ago
  db03-mba-l-cc
• wi-cli-venus assigned · 4w ago
  db02-mba-l-cc
• wi-cli-venus note · 4w ago
  RE-MEDIDO CONTRA EL LIBRO IMPORTADO VIGENTE - db02-mba-l-cc, 2026-09-12, DEV, SOLO LECTURA. Este item conto 50 celdas (49 ID ADAS + 1 ID MDVR) sobre el libro del 2026-08-20. Hoy, sobre el snapshot 12 (2026-09-07-2350-parque-rutap.xlsx), la poblacion de esta clase -precision destruida por notacion cientifica- es 4 celdas, todas en ID ADAS, CERO en ID MDVR y CERO en ID CANBUS. LAS CUATRO, nombradas con dominio y fila del Excel, que es lo que Eugenia necesita para reponerlas: AE100DC, fila 1087, valor '2.51616442111E+22', periodo cerrado 2026-04-21 AF233AJ, fila 1009, valor '251216442111E00050810025', periodo cerrado 2025-12-12 AF233AJ, fila 1090, valor '251216442111E00050810025', periodo cerrado 2026-04-21 AG336IX, fila 1115, valor '2.51216442111E+22', periodo cerrado 2026-04-21 Las dos de AF233AJ llevan el MISMO string destruido en dos periodos distintos, o sea el valor daniado se arrastro al cerrar y reabrir. Y las dos grafias que aparecen -'2.51616442111E+22' y '251216442111E00050810025'- muestran que no todas se rompieron igual: la segunda ya no es notacion cientifica valida, es el resultado de pegar el exponente adentro del numero. LAS CUATRO ESTAN EN PERIODOS CERRADOS. Lo digo porque cambia la URGENCIA, no la correccion: sigue siendo dato del libro que no se puede recuperar de la celda. Y ESTO ES ESTABLE, NO ESTA EMPEORANDO NI MEJORANDO: medido en los cuatro snapshots importados en DEV -9 (09-03), 10 (09-04), 11 (09-05) y 12 (09-07)- da exactamente 4 en los cuatro. O sea desde el 09-03 el libro sale igual. La causa raiz que el item sospechaba (la columna no esta formateada como texto en el origen) es consistente con eso: el valor no se re-rompe, viene ya roto y se arrastra export tras export. LO QUE HAY QUE MANDARLE A EUGENIA, y es corto: cuatro celdas, tres dominios, dos filas del mismo. Mas la peticion de formato de columna como texto, que es lo unico que impide que vuelva a pasar con un ID nuevo. NO EJERCITADO: mido el libro IMPORTADO, no el archivo 2026-09-10-1150 que esta en disco sin importar. Si ese trae celdas nuevas, no las veo. Y no busque esta clase de dano en otras columnas ademas de los tres ID. Nada ejecutado.
• wi-cli-venus assigned · 3w ago
  db04-mba-l-ca
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 04:03 -03 — SELECT-only current-state check: DEV movilba_dev snapshot 18 and PROD movilba snapshot 5 both identify 2026-09-19-0648-parque-rutap-corrected.xlsx with 5528 source rows. The ADAS/MDVR precision-loss cells were not reread from the current source workbook. Status unchanged; no DB write.
• db04-mba-l-ca blocked · 3w ago
  db04-mba-l-ca 2026-09-24 04:22 -03 — Current-book reread: /data-lezama/movilba/libro/README.md names the top-level 2026-09-23-1128-parque-rutap.xlsx as current; sha256 a8be302e5cf5ff1ea71edcd689814f7552dafd8ec765311614b655bdd3de3559. openpyxl read-only Base rows (Nro_dominio nonempty), ID ADAS col27 and ID MDVR col29: 49 numeric ID ADAS cells and 1 numeric ID MDVR cell have 56-digit scientific-form float representations; all 50 periods closed. Same cell-key/value multiset in pinned 2026-09-19-0648 corrected workbook (sha256 6fd1b9dfa5207508bbd5726e1765c9dc5bb37a6930f54170468b05706c5bc42d). Also four text-formatted damaged IDs from the 2026-09-12 note remain: AE100DC one, AF233AJ two, AG336IX one; these are a separate representation and not included in the 50. Eugenia/Edu must restore the original identifiers in Parque and correct source ID-column text handling/export; the lost digits cannot be inferred from these cells. Recheck a newly approved source workbook before unblocking. No database or workbook write.
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 04:30 -03 — Added a concise stakeholder question to the working tracker /data-lezama/movilba/import-reports/todo-rutap-importacion-prestaciones.xlsx, Para Eugenia!A10:E10, #86. B10 asks for the correct original identifiers for the 49 ID ADAS and 1 ID MDVR cells stored as rounded numeric scientific notation in the current book; C10 locates Base columns and notes all 50 periods closed; E10=PENDIENTE. This is a question only, not an answer or verified repair. Item remains blocked on Eugenia/Edu and a new approved source check. No database write.
• coder03-mba-l-cc note · 3w ago
  coder03-mba-l-cc 2026-09-24 - Triage of Para Eugenia #86 against snapshot 10 of todo-rutap-tracker.sqlite: #86 IS this item, not a new one. It was written by db04-mba-l-ca at Para Eugenia!A10:E10 (progress event 07:37Z), so the attribution relayed to me - that Elazar entered it while the book was open - is wrong; no item is filed for it and none should be. Snapshot 10 row [86] reads Estado=PENDIENTE, question asks for the original identifiers of 49 ID ADAS + 1 ID MDVR cells stored as rounded scientific notation, Donde mirar names Base of the 23/09 book and states all 50 periods are closed. No duplicate: snapshots 8 and 9 have no row 86 and no row 10, so the sheet carries exactly one instance. Adjacent items that are NOT this one and must not be merged into it - the distinction is the representation, and merging them loses it: MOVILBA-75 and MOVILBA-244 are the 42 ######## ID ADAS cells (column-width overflow, digits still present in the file); MOVILBA-177 is PROD writing '0' where the book is blank, 1979 cells across ID CANBUS/ADAS/MDVR plus 17 real identifiers overwritten by '0'. Only the 50 measured here have the digits destroyed in the source cell. This item stays blocked on Eugenia/Edu; nothing to do on the app side.
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 05:17 -03 — New current SSOT read-only check: /data-lezama/movilba/libro/2026-09-24-0434-parque-rutap.xlsx (SHA-256 94c3499d742c7a0201d94434fba5cca2e4d6e7d44534057e136f4546a215fa19; README names top-level as current). Base header row 2, 5538 rows with Nro_dominio. Same 56-digit-float criterion as 09-23: ID ADAS 0, ID MDVR 0. All 50 former bad cell identities matched by (dominio,linea,interno,fecha_alta,fecha_baja,field); values now numeric 12-digit ints: ADAS 45=251616442111 (AA856,AA1981,AA2753,AA2771,AA2737,AA2739,AA2741,AA2747,AA2738,AA2746,AA2752,AA2742,AA2764,AA2765,AA2782,AA2780,AA2248,AA2761,AA2776,AA2779,AA2751,AA1586,AA2748,AA2740,AA2736,AA2777,AA2766,AA2774,AA2756,AA2772,AA2749,AA2754,AA2758,AA2781,AA2750,AA2383,AA2745,AA2008,AA2760,AA2650,AA2773,AA2762,AA2169,AA1476,AA2022); ADAS 3=251516442111 (AA2787,AA2785,AA2784); ADAS 1=251516442011 (AA2786); MDVR 1=251616442111 (AC3379). This verifies current SSOT values, not a permanent source-text format correction. Four distinct string-damaged IDs persist: AE100DC Base!AA2778='2.51616442111E+22'; AF233AJ Base!AA815 and AA2733='251216442111E00050810025'; AG336IX Base!AA2734='2.51216442111E+22'. These are separate from the 50.\nSnapshot diff, SELECT-only, identical in DEV and PROD: DEV movilba_dev snapshot 18 and PROD movilba snapshot 5 each import 2026-09-19-0648-parque-rutap-corrected.xlsx, 5528 rows/2413 distinct dominios/1599 open rows. New book has 5538 rows/2414 dominios/1599 open rows. Appeared: AI563JO. Disappeared: none. 10 vigente-period differences (Fecha_Baja blank defines open): AC736PL, AD761FY, AE893OO 2026-03-17→2026-09-23; AF894KE 2026-06-05→no open period; AH846RG 2026-08-18→2026-09-18; AH846SE, AH846SJ, AI153BS, AI239SC 2026-08-31→2026-09-18; AI458AR 2026-08-10→2026-09-21. No DB/import writes; tracker Para Eugenia #86 left untouched and PENDIENTE.
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 — Read-only census of current SSOT 2026-09-24-0434-parque-rutap.xlsx (SHA-256 94c3499d742c7a0201d94434fba5cca2e4d6e7d44534057e136f4546a215fa19), 5538 vehicle rows. ID ADAS: 2573 nonzero IDs/1203 distinct; frequency distribution of distinct values by row-occurrence count = 1:578, 2:270, 3:174, 4:82, 5:61, 6:21, 7:11, 8:2, 10:1, 11:1, 15:1, 45:1; 625 distinct values repeat, 196 values occur across >1 dominio. ID MDVR: 4410 nonzero IDs/3042 distinct; distribution = 1:2296, 2:361, 3:216, 4:121, 5:34, 6:10, 7:2, 8:2; 746 values repeat, 284 occur across >1 dominio. Blank/zero excluded from frequency: ADAS zero=2965, blank=0; MDVR zero=1128, blank=0. Target 251616442111 occurs in ADAS 45 rows/44 dominios and MDVR 1 row/domain AD506NO; every occurrence is among former 50 affected cells, zero vehicles outside those 50 carry it in either field. Repetition is common in both columns, but target ADAS frequency 45 is an outlier and its provenance/restoration is not established; keep item blocked pending Eugenia/source confirmation. Import NOT performed: coder request says DEV-first; project SSOT protocol requires PROD validation before DEV refresh, and standing DB rule is SELECT-only absent Elazar authorization. No XLSX or DB writes.
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 05:25 -03 — Interpretation of current-book census: ID ADAS value 251616442111 occurs 45 times across 44 dominios, while the next most frequent value occurs 15 times; this target appears in no vehicle outside the former 50 affected cells (also one MDVR occurrence, likewise within those cells). Although repeated IDs are common generally, this extreme concentration exactly on damaged cells is evidence against treating the 45 values as verified restoration. The workbook alone does not establish their provenance or the correct original IDs. Keep blocked pending Eugenia/source confirmation; no tracker edit or import.
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 05:29 -03 — Elazar clarified the governing goal: replace Eugenia’s workbook by faithfully importing its data. An unusual value that is genuinely in the source is not a reason to repair or reject her data. First verify the source value and that any discrepancy is not our read/transform/import error; then import unchanged and leave a courteous tracker note stating what we found/did and asking if the handling is okay. The current 2026-09-24 book contains 251616442111 in 45 ID ADAS cells across 44 dominios; it occurs nowhere else in ID ADAS, and is also in one ID MDVR cell. This distribution flags an unusual source pattern, not authority to alter the values. Import remains unperformed pending authorized scope/sequence; keep open until import fidelity is checked.
• coder03assistant-mba-l-ca progress · 3w ago
  coder03assistant-mba-l-ca | 2026-09-24 05:36 ART. Updated live tracker Para Eugenia #86 at B10:C10 under hub workbook lock, using exact question supplied by db04-mba-l-ca from current 2026-09-24-0434 SSOT (SHA-256 94c3499d742c7a0201d94434fba5cca2e4d6e7d44534057e136f4546a215fa19). Question states 50 affected cells again contain numeric IDs but 45 ID ADAS cells share 251616442111, zero occurrences outside the 50, next-highest book frequency 15; asks Eugenia to confirm/correct the 50 IDs from original source. Updated C10 book reference from 23/09 to 24/09. D10 remains blank, E10 PENDIENTE; no claim that source IDs are restored. Verified workbook opens and row exact; tracker SHA-256 de6ad5e3331da983f5d653bb75d4e84e35a3f33234845a627ca26c5cc499f5e3. SQLite snapshot 12, 3672 cells; diff 11 to 12 only changes Para Eugenia #86 Pregunta and Dónde mirar, all other sheets unchanged. Status remains blocked pending source confirmation and import-fidelity work by db04.
• coder03assistant-mba-l-ca progress · 3w ago
  coder03assistant-mba-l-ca | 2026-09-24 05:40 ART. Corrected my superseded 05:36 tracker report after db04-mba-l-ca relayed Elazar’s rule: audit source versus import, then import source values faithfully; do not ask Eugenia to repair the workbook. Under workbook lock, changed live Para Eugenia #86 B10 to a short withdrawal pending source/import-fidelity verification and E10 to RETIRADA 24/09 - pendiente de verificar la importación. C10 still identifies the 24/09 source; D10/F10 blank; #87 intact. Verified live XLSX SHA-256 a7728d1c67c04aad601c10acf2b8fb9f741e68ec223a2e4cfd73f75215733f6c and imported SQLite snapshot 13 (3672 cells); diff 12→13 only B10/E10. No claim yet that the 45 repeated ADAS values were faithfully imported, and no answer from Eugenia. db04 owns that verification; afterward the tracker can briefly report the measured source value and ask if faithful handling is acceptable.
• coder03assistant-mba-l-ca progress · 3w ago
  coder03assistant-mba-l-ca | 2026-09-24 05:39:47 ART. Timestamp correction: my immediately prior correction event was written at 05:39 ART; its rounded 05:40 body stamp was ahead of the server write clock. The substance and tracker snapshot 13 measurement in that event stand.
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 05:55 -03 — MOVILBA-74 does not block the approved import and no source repair is requested. The current SSOT has the 50 previously affected cells populated; 45 ID ADAS cells carry 251616442111, appearing nowhere else in ID ADAS. Elazar's direction is to import that value unchanged. However, MOVILBA-155 PROD preflight exited 1 at the source-header gate (missing expected col_39/col_52; unexpected blank Digitos header), so the 09/24 snapshot has not been imported and fidelity cannot yet be measured. Live Para Eugenia #86 is correctly withdrawn pending fidelity verification; no claim that import occurred. Keep this item open pending successful import and post-import comparison, then report to Eugenia.
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca | 2026-09-24 06:25 ART — The current-book value 251616442111 was faithfully imported in PROD, not altered; PROD snapshot 6 now contains the 5538-row SSOT. However, the required same-digest DEV refresh is held: its reconciliation dry run would physically delete 17 app_dev vehicles absent from the book and 54 app-origin history rows, conflicting with the documented DEV test-data/history preservation rule. DEV remains on snapshot 18. Source distribution remains as measured: 45 ID ADAS cells (44 domains) plus one ID MDVR occurrence; no claim of dual-base import or completed workbook fidelity until DEV refresh is safely resolved. Para Eugenia #86 remains withdrawn/open pending faithful import verification.
• db04-mba-l-ca unblocked · 1w ago
  cleared: db04-mba-l-ca 2026-09-24 04:22 -03 — Current-book reread: /data-lezama/movilba/libro/README.md names the top-level 2026-09-23-1128-parque-rutap.xlsx as current; sha256 a8be302e5cf5ff1ea71edcd689814f7552dafd8ec765311614b655bdd3de3559. openpyxl read-only Base rows (Nro_dominio nonempty), ID ADAS col27 and ID MDVR col29: 49 numeric ID ADAS cells and 1 numeric ID MDVR cell have 56-digit scientific-form float representations; all 50 periods closed. Same cell-key/value multiset in pinned 2026-09-19-0648 corrected workbook (sha256 6fd1b9dfa5207508bbd5726e1765c9dc5bb37a6930f54170468b05706c5bc42d). Also four text-formatted damaged IDs from the 2026-09-12 note remain: AE100DC one, AF233AJ two, AG336IX one; these are a separate representation and not included in the 50. Eugenia/Edu must restore the original identifiers in Parque and correct source ID-column text handling/export; the lost digits cannot be inferred from these cells. Recheck a newly approved source workbook before unblocking. No database or workbook write.
• db04-mba-l-ca completed · 1w ago
  2026-10-05 read-only fidelity check. Pinned workbook /data-lezama/movilba/libro/2026-09-30-1305-parque-rutap.xlsx sha256 21e98b9a13314591cd89b39a5428265f6519f6929474ed6e48bd51d628140b74; PROD snapshot 8 and DEV snapshot 20 both register md5 8512833be84d1568743d61b601179c6b, 5548 rows. Predicate on raw cells: id_adas IN ('251616442111','251516442111','251516442011') OR id_mdvr='251616442111'. 50 affected closed rows: ADAS 45/3/1 and MDVR 1. Row-by-row SELECT of fila_excel,nro_dominio,linea,nro_interno,fecha_alta,fecha_baja,id_adas,id_mdvr ordered by fila_excel is byte-equal PROD vs DEV (50/50, sha256 2314053a88065122c6d4fda057b17f416c9b670ff5cc937b8b6e183a94f3d076). Workbook Base!AA/AC values keyed by fila_excel match PROD raw rows 50/50, hence DEV too. Normalized raw_id_adas/raw_id_mdvr vs staging: 0 mismatches, 0 missing history rows in either base. The app faithfully imported the current book values; this does NOT certify that 45 repeated IDs are historically correct. Eugenia question #86 remains in tracker; no DB/workbook value changed.