169 vehiculos en servicio sin linea asignada en MovilBA que el libro si tiene: una sola corrida (snapshot5 nuevos-eslabones 08-25) dejo linea_id y estado_id vacios en 170 filas
Medido 2026-09-03 en PROD por db02-mba-l-cc (SELECT) contra el libro vigente /data-lezama/rutap-ssot/2026-09-03-1049-parque-rutap.xlsx (md5 b9880577fb9d886bfca4aaadba124ea5), hoja Base. 169 VEHICULOS EN SERVICIO NO TIENEN LINEA EN MOVILBA Y EL LIBRO SI SE LA DA. De los 1600 vehiculos con ficha en ALTA, 1430 tienen asignacion de linea por v_vehiculos_lineas_entidades y 170 no. De esos 170, el libro tiene fila ABIERTA CON Linea cargada en 169; el restante es un dominio que el libro da de baja (cae en MOVILBA-213). Ejemplos: AG732SW linea 42, AH764WQ 34, AH846RG 109, AI095HG 151, AE716GC 102. CAUSA UNICA Y NOMBRADA: los 170 tienen fila de historial viva - no es el caso de 'sin fila' - y las 170 las escribio el MISMO loader, creado_por='db-mba-l-cc-snapshot5-nuevos-eslabones-2026-08-25'. Las 170 filas tienen linea_id NULL y estado_id NULL, y entidad_id CARGADO en las 170. O sea esa corrida creo el eslabon con la empresa pero sin linea ni estado. ES EL MISMO CONJUNTO QUE LAS 170 FILAS ABIERTAS SIN estado_id DE MOVILBA-117. No son dos defectos: es una escritura del 2026-08-25 que dejo dos columnas vacias. Cerrar 117 por el lado del estado sin completar la linea deja 169 vehiculos sin linea igual. CONTRASTE QUE HACE FALTA PARA NO ARREGLAR LO QUE NO ESTA ROTO: la pregunta original era la inversa - si un vehiculo de BAJA que conserva linea vigente es un defecto. NO LO ES. Son 140 (no 788; 788 es el total de fichas en BAJA) y en 139 de 140 la ultima fila CERRADA del libro trae Linea cargada y COINCIDE con la que publica la vista; cero difieren. El libro no vacia la Linea al cerrar un periodo, asi que conservarla es fidelidad al SSOT. El caso 140 restante es un dominio que el libro tiene ABIERTO y la ficha da de baja: es de MOVILBA-213. CONTROL POSITIVO: 140 entradas resueltas sin residuo del lado BAJA, 170 del lado ALTA. PENDIENTE DE DECIDIR: completar linea_id (y estado_id) de esas 170 filas desde la fila abierta del libro es una ESCRITURA y necesita GO nombrando que se escribe. Probablemente corresponde al mismo lote que MOVILBA-155. NO EJERCITADO: no medi DEV; no verifique si la linea del libro existe como fila en la tabla lineas para los 169; cero escrituras.
Activity
-
parent=MOVILBA-155
-
0
-
VERIFICADO INDEPENDIENTEMENTE por coder02 en PROD 2026-09-03: 1600 fichas en ALTA, 1430 con linea, 170 sin linea - identico a lo que reporto db02. Y la causa unica se confirma en una sola consulta: TODAS las filas vivas de vehiculo_historial con linea_id NULL son 170, todas de creado_por='db-mba-l-cc-snapshot5-nuevos-eslabones-2026-08-25', las 170 con linea_id NULL, las 170 con estado_id NULL y las 170 con entidad_id CARGADO. Un solo write del 2026-08-25 que dejo dos columnas vacias y ninguna otra corrida contribuye una sola fila. ES EL MISMO CONJUNTO QUE MOVILBA-117: los '170 abiertos sin estado' de 117 y los '170 sin linea' de aca son las mismas 170 filas. No son dos defectos, es uno con dos columnas. Cerrar 117 solo por el lado del estado deja 169 colectivos en servicio sin linea. Se completan en UNA sola pasada. REQUIERE GO DE ELAZAR: completar linea_id y estado_id desde la fila ABIERTA del libro es una ESCRITURA sobre 170 filas de PROD. El GO tiene que nombrar que se escribe, sobre que filas y de que libro se deriva (2026-09-03-1049). Va en el mismo lote que MOVILBA-155, no suelto: importar el libro primero puede cambiar cuales son las 170. GATE ANTES DE ESCRIBIR, y es de db02: verificar que la Linea que da el libro EXISTE como fila en la tabla lineas para los 169. Un write que crea una FK a una linea inexistente es peor que el NULL que reemplaza.
-
GATE PRE-ESCRITURA EJECUTADO (db02, 2026-09-03, SELECT en PROD). El que coder02 nombro como mio: verificar que la Linea que da el libro EXISTE como fila en la tabla lineas antes de escribir un linea_id. PASA, sin residuo. METODO: las 170 filas vivas de vehiculo_historial con linea_id NULL y creado_por='db-mba-l-cc-snapshot5-nuevos-eslabones-2026-08-25', resueltas a dominio, cruzadas contra la fila ABIERTA del dominio en el libro 2026-09-03-1049 y su columna Linea, y esa Linea contra btrim(numero_linea) de las 28 filas vivas de lineas. RESULTADO: 169 de 170 tienen fila abierta con Linea cargada y la linea EXISTE en la tabla. 1 no tiene fila abierta en el libro - es el caso que ya cae en MOVILBA-213. Cero lineas faltantes. LAS 8 LINEAS QUE NECESITA EL WRITE, con cuantos vehiculos cada una: 151 (77), 65 (58), 109 (11), 47 (10), 34 (6), 102 (4), 4 (2), 42 (1). Suman 169. Las ocho estan vivas en lineas hoy. NO SE CRUZA CON MOVILBA-220: las lineas que faltan en PROD son 23, 90 y 99, y ninguna de las tres aparece entre las 8 que este write necesita. 220 no bloquea a 216. VIGENCIA DE ESTE GATE: se derivo del libro 2026-09-03-1049. Si 155 importa un libro posterior el conjunto de 170 puede cambiar y el gate se vuelve a correr - es barato y no se hereda. SIGUE SIN GO: no escribi nada. Completar linea_id y estado_id en 170 filas de PROD sigue necesitando GO fresco de Elazar nombrando las filas y el libro del que se deriva.
-
db02, 2026-09-04, DEV, solo lecturas. LA CONSULTA QUE FALTABA PARA EL GATE DE 216, con denominador. DEV tiene 170 filas de vehiculo_historial ABIERTAS y vivas (fecha_baja IS NULL, borrado_en IS NULL) con linea_id NULL. De esas, 169 TIENEN linea no vacia en la fila ABIERTA del libro; 1 viene vacia en el libro y 1 no tiene fila abierta. O sea el dato existe en el SSOT y se perdio en el import: la recarga fiel lo restituye. GATE: despues del reload, filas abiertas vivas con linea_id NULL baja de 170 a <=1, y FALLA si el pre-estado no es 170 (denominador capturado antes, como los demas). CASO TRABAJADO - AI239RS: el libro trae linea 151 en la fila abierta, DEV guardo linea_id NULL. Sus DOS filas del libro dicen tramite 'Modif' y ambas linea 151; la cerrada termina 2026-08-19 y la abierta arranca 2026-08-19, bajo el expediente EX-2026-37226779. Y ESE EXPEDIENTE EXPLICA LA CLASE: cubre 154 filas del libro sobre 77 DOMINIOS, sus unicos tramites son 'Alta' y 'Modif' (NINGUNA baja), y los 77 de 77 MANTIENEN la misma linea antes y despues (cero cambian). Es exactamente lo que contesto Eugenia: un expediente de MODIFICACION cierra un periodo tecnico y abre otro en la MISMA linea, y no es una baja. Un loader que lea 'periodo cerrado + expediente' como baja inventa 77 bajas con este solo expediente. Ojo, no generalizar: 77/77 es de ESTE lote, no una afirmacion sobre todos los expedientes del libro. DOS CORRECCIONES AL SINTOMA REPORTADO (ficha de AI239RS con 3 tarjetas y AH850GX vinculado): AI239RS tiene DOS filas de historial, no tres - vehiculo_historial devuelve 2 y v_vehiculo_historial devuelve 2, y esa vista joinea solo por vh.vehiculo_id, no tiene join por expediente. Y AH850GX NO comparte expediente con AI239RS (AH850GX: EX-2026-09877019; AI239RS: EX-2026-20573807 y EX-2026-37226779). La hipotesis de vinculo por expediente era muy plausible - el expediente ES clave de lote, 77 a 1 - y aun asi es falsa para este par. NO EJERCITADO: no abri la ficha, asi que no se que renderiza la tercera tarjeta, solo que no es v_vehiculo_historial; no medi la clase de 170 en PROD; no lei el clasificador de MOVILBA-97. Cero escrituras.
-
GATE ACORDADO (db02, 2026-09-04, DEV): **170 filas de historial abiertas y vivas con `linea_id` NULL, y 169 de ellas TIENEN linea no vacia en la fila ABIERTA del libro.** Una trae blanco en el libro, otra no tiene fila abierta. O sea el dato existe en el SSOT y se perdio en el import: un reload fiel lo restituye. Gate del rebuild: filas abiertas vivas con linea_id NULL pasa de 170 a COMO MUCHO 1, y FALLA si el pre-estado no es 170. Esta es la consulta que faltaba para que 216 entrara al script de gates de MOVILBA-226 - la deje afuera a proposito por no tener consulta acordada, y ahora la hay, medida y no inventada. Causa raiz: la modificacion tecnica se leyo como algo que tira la linea en vez de conservarla (ver MOVILBA-97). NO EJERCITADO: no se midio la clase en PROD.
-
RE-MEDIDO 2026-09-18 por db02 (delegado por researcher). ARREGLADO en PROD, medido por los dos lados. HISTORIAL: filas abiertas con linea_id NULL = 0, estado_id NULL = 0, entidad_id NULL = 0, sobre denominador 1600 filas abiertas. Las tres columnas que la corrida culpable dejo vacias estan completas. SUPERFICIE DE ASIGNACION, que es lo que el item midio originalmente: vehiculos con ficha viva y periodo abierto SIN asignacion en v_vehiculos_lineas_entidades = 0. La vista cubre 2413 vehiculos. Se midio contra la relacion que el consumidor lee de verdad, no solo contra el historial. LA CORRIDA CULPABLE YA NO EXISTE: filas con creado_por LIKE '%snapshot5%' = 0. El loader de 'snapshot5-nuevos-eslabones-2026-08-25' no dejo ni una fila en la relacion vigente; el modelo entero se reemplazo (486/269). El item decia que es el mismo conjunto que las 170 filas sin estado_id de MOVILBA-117: las dos mediciones dan 0, asi que cierra por los dos lados a la vez. RECOMENDACION: cerrar. No lo cierro yo, lo delego researcher.
-
Cerrado por db02 2026-09-18 con su propia medicion en PROD: filas abiertas con linea_id NULL 0, estado_id NULL 0, entidad_id NULL 0 sobre denominador 1600; vehiculos con periodo abierto sin asignacion en v_vehiculos_lineas_entidades 0, vista cubriendo 2413; filas de la corrida culpable (creado_por LIKE '%snapshot5%') 0. Cierra tambien el lado de MOVILBA-117. Detalle en el event anterior. Se pide doble chequeo a audit-mba-l-cc.