El historial del vehiculo no refleja el libro: expte_baja y el tipo de tramite (Alta/Modif) nunca se importaron
El historial del vehiculo no refleja el libro de RUTAP: el importador nunca escribio el expediente de baja ni el tipo de tramite. NO es un ticket de DDL faltante - las columnas ya estan y estan vacias. Medido en DEV (3963 filas de vehiculo_historial; prod tiene 4045, no confundir). 'expte_baja varchar(110)', 'tramite varchar(20)', 'fecha_baja date' y 'motivo_id int FK opciones' existen las cuatro y estan 100% vacias. CAUSA PROBADA por db03: docs/migrations/2026-08-13-historial-por-tramite-backfill-rutap.sql no selecciona expte_baja ni tramite del libro, ni en el SELECT de _tramites ni en la lista de columnas del INSERT. Omision del importador, no parseo roto. El cierre del tramite quedo codificado solo en borrado_en. CASO QUE LO DESTAPO: AC751OM (vehiculo 3608), comparado fila por fila contra el libro por pedido de Elazar mientras la stakeholder miraba la ficha en dev01. Coinciden exacto fecha_alta, linea, observaciones y expte_alta (incluido 'EX-2025-29934856- -GCABA-DGGSM' con dos espacios, len 32 de los dos lados). No coinciden expte_baja (vacio aunque el libro lo trae en las dos filas cerradas) ni el tipo de tramite (la pantalla lee tres eventos identicos porque no hay de donde sacar Alta/Modif). Sus dos filas cerradas ya se repararon a mano en dev. ALCANCE: (1) backfill de expte_baja; (2) tramite como catalogo - se crea 'tramite_id integer FK opciones(id)' con (grupo_nombre='vehiculo_historial', campo_nombre='tramite'), valores ALTA y MODIF medidos del libro (Alta 2473, Modif 2612, 1 NULL), NUNCA en motivo_id (ya sirve a dos catalogos) y NUNCA como varchar suelto; la columna 'tramite varchar(20)' queda vacia y sin usar; (3) arreglar el SELECT/INSERT del importador, ejecutable y no una errata en un comentario - sin eso la proxima corrida vuelve a vaciar todo; (4) cablear la UI para mostrar tipo de tramite y expediente de baja en el historial. FUERA DE ALCANCE: fecha_baja viviendo en borrado_en, que es MOVILBA-83. CIFRAS, con la clave de db03 (chasis normalizado + fecha_alta + COALESCE(fecha_baja,borrado_en::date) + expte_alta normalizado como el importador), replicada bit a bit por db-mba-l-cc: 3860 emparejan 1:1, 0 ambiguas, 103 sin match unico, 2118 expte_baja por llenar, 3859 tramite derivable, 1 en blanco. Las 104 que quedan NULL estan listadas en /resource/movilba/import-reports/2026-08-20-movilba-94-103-filas-sin-match-unico.tsv y son deliberadas, no un pendiente. DEV primero; prod necesita GO propio de Elazar describiendo la operacion.
Activity
-
DEV exception artifact published: /resource/movilba/import-reports/2026-08-20-movilba-94-103-filas-sin-match-unico.tsv. Matching criterion used for the confirmed 3859/2120 candidate set: normalized chassis + fecha_alta + COALESCE(vehiculo_historial.fecha_baja, vehiculo_historial.borrado_en::date) + expte_alta, with NBSP→space and whitespace-collapse normalization matching the original importer. Artifact contains 103 rows with no unique RUTAP match (89 no same Fecha_Alta; 9 no same Fecha_Baja; 3 no matching normalized chassis; 2 different Expte. Alta) and 1 one-to-one RUTAP match with Tramite NULL. All 104 remain excluded from automatic backfill.
-
CORRECCION A LA DESCRIPCION DE ESTE TICKET (coder-mba-l-cc, 2026-08-20 13:26). La descripcion de arriba dice dos cosas que ya no son ciertas y que hay que leer corregidas, porque si alguien la usa de fuente para planificar va a disenar sobre datos falsos. (1) DICE 4045 filas: es la cifra de PROD. En DEV son 3963. Toda cifra sale de la base objetivo al momento. (2) DICE que el tipo de tramite 'no existe la columna en vehiculo_historial': FALSO. Existen 'tramite varchar(20)', 'expte_baja varchar(110)', 'fecha_baja date' y 'motivo_id int FK opciones', y las CUATRO estan 100% vacias en las 3963 filas de dev. O sea que esto no es un ticket de DDL faltante: es un backfill, y lo unico que se crea es 'tramite_id integer FK opciones(id)' con su catalogo (grupo_nombre='vehiculo_historial', campo_nombre='tramite'), porque un enumerado no puede quedar como varchar suelto. La columna 'tramite varchar(20)' queda vacia y sin usar. CAUSA PROBADA (db03): docs/migrations/2026-08-13-historial-por-tramite-backfill-rutap.sql no selecciona expte_baja ni tramite del libro - ni en el SELECT de _tramites ni en la lista de columnas del INSERT. Es una omision del importador, no un parseo roto ni un shift de columnas. Por eso el cierre quedo solo en borrado_en. CIFRAS ACORDADAS, con la clave de db03 (chasis normalizado + fecha_alta + COALESCE(fecha_baja,borrado_en::date) + expte_alta normalizado como el importador: NBSP a espacio y colapso de espacios), replicada bit a bit por db-mba-l-cc: 3860 emparejan 1:1, 0 ambiguas, 103 sin match unico, 2120 deberian tener expte_baja (2 ya la tienen, las dos de AC751OM reparadas a mano), 3859 con tramite derivable, 1 con tramite en blanco en el libro. Un criterio mas angosto (solo chasis + fecha_alta) da 3803 y es el equivocado: descarta por ambiguas filas que la clave completa resuelve. ARTEFACTO: /resource/movilba/import-reports/2026-08-20-movilba-94-103-filas-sin-match-unico.tsv (103 + 1 = 104 filas que quedan NULL a proposito). Esas 104 NO son un error ni un pendiente: son las que no se pueden derivar del libro sin inventar dato.
-
was: Medido por db-mba-l-cc sobre dev el 2026-08-20 13:03, comparando fila por fila AC751OM (vehiculo 3608, chasis 8AB368187JA149026) contra rutap.v_rutap_latest_norm. Las tres filas del libro y las tres nuestras se corresponden 1:1. COINCIDEN EXACTO: fecha_alta, linea (34/4/4), observaciones, y expte_alta incluso en el caso feo (fila_excel 946 trae 'EX-2025-29934856- -GCABA-DGGSM' con DOS espacios, len 32, y nuestra fila 7833 lo guarda identico, 32=32). NO COINCIDEN, y son tres huecos distintos: (1) expte_baja - RUTAP lo trae en las dos filas cerradas (EX-2026-10266432 y EX-2026-18235670) y nosotros no lo guardamos en ninguna columna, asi que la ficha no puede mostrar con que expediente se cerro un tramite. (2) tramite Alta/Modif - no existe la columna en vehiculo_historial, asi que la pantalla no distingue un alta de una modificacion aunque el libro si lo hace; es lo que hace que el historial se lea como tres eventos iguales. (3) fecha_baja - la columna existe y esta VACIA en las tres filas; el cierre vive en borrado_en (2026-02-26 y 2026-04-17, que coinciden con las Fecha Baja del libro), o sea el dato correcto en la columna equivocada: eso es MOVILBA-83 y no se re-abre aca. Detectado porque Elazar comparo la ficha de dev01 contra el Excel de Eugenia. Alcance de este item: 1 y 2. Hay que decidir si tramite va como catalogo en opciones (grupo vehiculo) y de donde se rellena para las 4045 filas ya importadas.
-
MOVILBA-88 AHORA DEPENDE DE ESTE TICKET. Eugenia decidio (13:35) que la ficha muestre la Alta mas reciente, o sea max(fecha_alta) sobre las filas con tramite ALTA. Esa formula NO SE PUEDE EVALUAR contra nuestro historial hasta que 94 termine: el tipo de tramite recien se backfilleo en dev hoy 13:31 y todavia no lo expone v_vehiculo_historial. Sin el tramite en la vista, 'la Alta mas reciente' habria que derivarla del export (que la calcula contra RUTAP por chasis) en vez de de nuestros propios datos. Consecuencia practica: la vista tiene que exponer el tramite igual, y las 104 filas que quedan sin tramite_id (103 sin match unico + 1 en blanco en el libro) son exactamente las que van a dar 'sin dato' cuando se calcule la Alta mas reciente por vehiculo. Hay que medir a cuantos VEHICULOS afectan esas 104 filas antes de cerrar 88 - un vehiculo cuyas filas Alta esten todas entre las 104 no va a tener fecha que mostrar.
-
PROD read-only candidate census (base movilba, 2026-08-20): 4045 historial rows; 4028 one-to-one source matches; 17 no-match; 0 ambiguous. : 2282 RUTAP-source candidates, all 2282 already populated in PROD (0 missing). Future backfill target: 4027 nonblank one-to-one source values; 1 matched source NULL and 17 no-match remain NULL. PROD exception artifact: /resource/movilba/import-reports/2026-08-20-movilba-94-prod-17-filas-sin-match-unico.tsv. Same confirmed composite key as DEV; no PROD data or schema changed.
-
El import RUTAP-1601 a dev (21:56) puebla tramite_id y expte_baja DESDE el libro via el importer corregido - el backfill deja de ser el mecanismo. Colateral detectado por db: su backfill de la tarde apareo 11 filas de ZZ001ZZ/ZZ002ZZ con expedientes de AE801OE via chasis compartido; limpieza pendiente como mini-script propio con audit, owner db.
-
Correccion de db: son 12 filas contaminadas, no 11 (ids 9654-9665, 6 por dominio ZZ; 9654/9660 solo tramite_id, el resto tramite_id + expte_baja). TSV autoritativo: /resource/movilba/import-reports/2026-08-20-movilba94-zz-contamination-11.tsv. Alcance propuesto del mini-script (no escrito): UPDATE de esos 12 SET tramite_id=NULL, expte_baja=NULL - exactamente las dos columnas del backfill; expte_alta con texto de AE801OE viene del import del 08-13 y va por asunto 9, fuera de este scope. Preflight re-deriva los 12 por medicion (chasis compartido + dominio NOT IN libro), no ids hardcodeados. Nota: es una escritura en DEV -> firma habitual + audit; se agenda cuando el coder lo slotee.
-
Cleanup ZZ APLICADO en dev 22:06 (md5 3dc1f96128e710a43edbfc9ec5b902af, GO de audit 22:05 bajo el GO general de la noche; dos NO-GO previos corregidos: pre-imagen con ABORT ante tabla existente, igualdad de conjuntos por EXCEPT bidireccional contra los 12 ids del TSV testigo). Post con queries frescas de db: filas contaminadas 0; pre-imagen 12 filas en bkp.movilba94_zz_cleanup_preimage; tramite_id 3871->3859 (-12); expte_baja 2190->2180 (-10, correcto: 9654/9660 solo llevaban tramite_id); fichas con cierre sigue 7. Artefacto ZZ cerrado en dev. REGLA PARA EL PAQUETE 94 DE PROD: la clave DEBE llevar identidad de vehiculo - prod tiene 130 chasis duplicados y esta clase de artefacto es exactamente lo que eso previene.
-
Aplicado en prod 2026-08-21 07:24 ART (script docs/migrations/2026-08-21-movilba-94-prod-tramite-id.sql, md5 a8a93657a5e0d7ae4882e01e8760f74 -> exacto 0a8a93657a5e0d7ae4882e01e8760f74, writer db02-mba-l-cc, ejecutor superuser elazar). Autorizacion: GO de Elazar 07:09 en CLI (relay coder-mba-l-cc-mt2sfc8oh17l) + GO de audit tras pre-lectura bloqueante. Cuatro pasos: filas de catalogo 317 ALTA / 318 MODIF en grupo vehiculo_historial campo tramite con ids forzados para quedar alineados con dev; ADD COLUMN vehiculo_historial.tramite_id; backfill desde la columna de texto legada (1765 Alta + 2270 Modif + 10 NULL = 4045); CREATE OR REPLACE VIEW v_vehiculo_historial de 20 a 26 columnas (prefijo estricto verificado antes del REPLACE, nunca DROP). ACEPTACION independiente de db03 07:28: exactamente una fila viva por valor, tramite_id presente, 4035/4045 poblados, mismatch cero, vista de 26 columnas con forma identica a dev, svc_nextjs con SELECT. Hallazgo de metodo que salio de aca: setval NO es transaccional, el ensayo con ROLLBACK dejo la secuencia avanzada mientras el echo decia 'nada aplicado' - los echo ahora declaran que clase de efecto cubre el ensayo. Desbloquea el deploy de codigo a prod.