El historial no dice QUE cambio en cada tramite: derivarlo del libro y backfillear vehiculo_historial.cambios
Elazar 2026-08-20 13:58, verificado a mano contra el Excel y confirmado por db03: cada fila de RUTAP es un SNAPSHOT COMPLETO de los campos de negocio, asi que el 'que cambio' de cada tramite es DERIVABLE comparando filas consecutivas del mismo dominio ordenadas POR FECHA (nunca por fila_excel). Caso testigo: AG358KX (vehiculo 4453), expediente EX-2026-11778166- -GCABA-DGGSM corresponde al cambio de id_mdvr a 253016442111000F0820137, y el Modif siguiente lo cambia a 16400014827 con id_adas y camaras_internas iguales. Hoy la ficha muestra tres tramites que se leen identicos porque el unico texto es el boilerplate 'Se modifican datos a pedido de la empresa', que es el mismo en todas las filas Modif del libro entero. NO CONFUNDIR CON MOVILBA-94, que es el backfill del tipo de tramite y del expediente de baja y ya tiene alcance cerrado y firmado. FORMA PROPUESTA: la columna vehiculo_historial.cambios jsonb YA EXISTE, esta 100% NULL, y su contrato ya establecido es {campo:{anterior,nuevo}} - ExpedienteForm.tsx ya lo renderiza. O sea que esto es backfill de una columna existente mas el fix del importador para que la proxima corrida lo escriba, no modelo nuevo. TRAMPAS QUE APLICAN: ordenar por fecha y no por fila_excel; resolver los campos de catalogo por opciones ANTES de comparar (un id contra una etiqueta no es una comparacion, ya produjo 1598 diferencias falsas el 2026-08-20); y reportar cuantas filas Modif NO producen ningun campo distinto, que son las que van a mostrar 'sin cambios detectados' y son parte del entregable, no un residuo. Dev primero; prod con GO propio.
Activity
-
DOS MEDICIONES INDEPENDIENTES, CERCANAS PERO DISTINTAS - hay que unificar el criterio ANTES de backfillear, no despues. Las dos sobre las 5086 filas del libro, 2612 Modif, ordenando por fecha y nunca por fila_excel. audit-mba-l-ca: 2329 con al menos un campo cambiado, 156 sin cambio, 127 sin fila previa. db03-mba-l-ca: 2402 con cambio, 85 sin cambio, 125 sin fila previa. La diferencia esta en la NORMALIZACION, no en el orden: db03 normalizo 0/vacio en campos de dispositivo y conteo, coma/punto en consumo, y Si/Si-con-tilde/No; audit excluyo explicitamente metadata de transaccion (CUIT, identificador de empresa, dominio, fechas, Tramite, Expte Alta/Baja) y no declara esas normalizaciones. Se ve en el detalle: db03 cuenta cuit_norm 210 e identificador_empresa 210 como campos cambiados y audit los excluye por definicion. O sea que NO miden el mismo conjunto de campos - una diferencia de 73 filas que sale de que cuenta como 'campo de negocio', no de un error de nadie. DECISION PENDIENTE antes del SQL: (1) la lista exacta de campos de negocio que entran al diff, escrita, con la metadata de transaccion excluida y dicho cuales son; (2) las normalizaciones exactas, porque un cambio de 'Si' a 'Si' con tilde no es un cambio y una coma decimal tampoco; (3) la regla de desempate para los 13 casos con fecha identica en la fila anterior - audit uso el orden de fila como provisorio y eso NO puede quedar asi, el orden de fila del Excel no es un dato. Y antes de que sea visible al usuario: los campos de catalogo se resuelven por opciones; comparar un id contra una etiqueta no es una comparacion.
-
MODELO DE NEGOCIO APORTADO POR ELAZAR 2026-08-20 14:00, y resuelve la discusion de que campos entran al diff: cuando un colectivo pasa de una empresa a otra, hacen BAJA en una y ALTA en la otra. O sea Modif es donde se miran los cambios de CAMPO, y Alta/Baja es donde se mira el cambio de EMPRESA (cuit). Eso explica por que las dos mediciones diferian sin que ninguna estuviera mal: audit excluia cuit e identificador_empresa por definicion y db03 los contaba, y los 73 de diferencia salian justo de ahi. No era un error de medicion, era que faltaba el modelo. EL DIFF QUEDA DEFINIDO POR TIPO DE EVENTO, no por una lista negociada: Modif -> campos de negocio (equipamiento, identidad, chasis, observaciones); Alta/Baja -> empresa, entidad, linea, interno. Consistente con lo que midio db02: las filas Alta cambian interno 62% y linea 75%, las Modif 0,2% y 0,04%. PENDIENTE DE VERIFICACION, porque Elazar pidio chequear igual: db03 reporto cuit_norm 210 e identificador_empresa 210 cambiando en filas Modif, y bajo este modelo eso no deberia pasar. Los dos numeros iguales sugieren que es la misma cosa contada dos veces. Si se confirma que hay 210 Modif con cambio de empresa, no es una excepcion del diff sino un hallazgo de datos - transferencias cargadas con el tramite equivocado - y va como ticket propio.
-
CHANGED, sigue abierto pero SOLO PARA PROD. Medido por db03-mba-l-ca 2026-08-21 08:11 ART: prod tiene 45 de 4052 filas de historial con 'cambios' poblado y 4007 en NULL; dev tiene 4003 de 4146 poblado y 143 en NULL. O sea que el backfill de dev entro y prod no lo tiene. Consecuencia para lo que viene: MOVILBA-97 (subtipo de modificacion derivado del diff) y MOVILBA-99 (leer el historial como intervalos) los dos consumen 'cambios', asi que en prod hoy no tienen de donde leer. El item deja de ser 'derivar el diff' - eso ya se sabe hacer y se hizo - y pasa a ser 'llevar el backfill a prod', que necesita GO de Elazar.
-
parent=MOVILBA-125
-
AUDIT 2026-08-25: la remedio propuesta aca (backfillear vehiculo_historial.cambios) queda SUPERADA por docs/design/rutap-full-history-refactor-plan.md, que ordena retirar cambios enteramente ('Replace all readers with explicit columns and SQL comparison views, then remove cambios in the same refactor. Do not leave a compatibility JSON writer or reader'). El hallazgo de este item sigue vigente y medido de nuevo hoy (45/4225 filas con cambios poblado, prod), pero el vehiculo de solucion cambio: diff calculado en runtime comparando snapshots consecutivos, no backfill de la columna JSON. Requiere decision de Elazar/db02 sobre si este item se cierra a favor del plan o se mantiene como medicion de referencia.
-
--reason
-
CORRECCION DE UNA CIFRA DE ESTE ITEM que se venia citando como cobertura parcial (medido por coder02-mba-l-cc en PROD 2026-08-28): las '45 de 4225 filas con cambios poblado' son 45 filas con el objeto VACIO '{}', no con contenido. El desglose real es 4180 NULL + 45 '{}' + 0 con datos. La cobertura de cambios en prod es CERO, no 45. No cambia la resolucion del item (queda cerrado a favor del plan de refactor) pero si cambia el impacto: mientras estuvo asi, la ficha y el PDF mostraban 'Sin cambios detectados' en las 2485 filas no-primeras de prod. Arreglado en MOVILBA-99 commit 3fabec37 calculando el diff contra la fila anterior.