Tramite duplicado en vehiculo_historial: 7394 y 7400 (AD956UK) misma fecha de alta y de baja

Sub-tickets

Activity

• wi-cli-venus created · 2026-08-14
• wi-cli-venus commented · 2026-08-14
  Dato extra del backfill de MOVILBA-36: 7394 quedo con expediente_baja EX-2025-53390264, el MISMO numero que su propio expediente de alta - unico caso auto-referencial de las 2293. Sale asi del libro y es consecuencia directa del tramite duplicado 7394/7400.
• wi-cli-venus commented · 2026-08-14
  CORRECCION medida (db02, verificada por db-mba-l-cc y por db02 de nuevo): los auto-referenciales NO son 1 sino 10 crudo / 11 normalizando espacios internos. Lista: 7609 AD672PF, 7610 AD672PD, 7611 AD672OW, 7612 AF957UO, 7613 AG946ZZ, 7614 AG708WP, 7615 AG835IX (los SIETE con fecha_expediente 2025-07-08, cierre 2025-09-19, mismo EX-2025-40163585 en alta y baja, siete dominios distintos = tramite de flota cargado como alta y como baja de todos); 7394 AD956UK; 7795 AH791QY y 7877 AH561CW (2025-12-12, cierre 2025-12-26, valor literal 'Se modifican datos a pedido de la empresa'); 9270 PMB100. Es forma del dato en el libro, no efecto de la clave del backfill.
• wi-cli-venus parentChanged · 2026-08-14
  parent=MOVILBA-39
• wi-cli-venus note · 2026-08-21
  ESTE PAR NO ES UN CASO SUELTO: es un miembro de una familia de 8, y hay dos tickets mas sobre la misma poblacion. Medido 2026-08-21 en PROD por tres carriles independientes (coder02, db, db02). AD956UK 7394/7400 son identicas en fecha_alta 2025-12-10, fecha_baja 2025-12-11, tramite_id 317, entidad 49, linea 20, creado_por, creado_en y borrado_en; difieren SOLO en expte_alta (Ex-2025-53390264 vs Ex-2025-53084543), y las dos llevan el MISMO expte_baja EX-2025-53390264. O sea: dos altas bajo expedientes distintos cerradas por una sola baja. Bajo la clave (vehiculo_id, fecha_alta, fecha_baja, tramite_id) con GROUP BY, PROD tiene 8 pares asi: AD919PL, AD956UK, AE060XC, AE631MI, AE922FX, AE971FE, AE971FF, PQP070. Tres son de DOS cargadores distintos insertando el mismo evento (AE060XC, AE631MI, PQP070: system_import + import-rutap-2026-08-14-prod); cinco son del MISMO cargador dos veces. VER TAMBIEN: MOVILBA-42 (la clave de evento del refactor append-only colisiona justo en estos 8 - diseño refutado, no incompleto) y MOVILBA-73 (cinco de estos ocho son ademas los vehiculos cuyo orden v_vehiculos_hist_ultimo no puede resolver). 37, 42 y 73 son TRES PREGUNTAS DISTINTAS sobre una poblacion solapada. Este ticket es el unico caso que alguien archivo antes de saber que era general.
• wi-cli-venus assigned · 6w ago
  db02-mba-l-cc / db
• wi-cli-venus note · 6w ago
  PREGUNTA ABIERTA CONTESTADA por el libro, medido por db02-mba-l-cc 2026-08-31 sobre /data-lezama/rutap-ssot/2026-08-31-0939-parque-rutap.xlsx. Este item preguntaba 'si el duplicado existe tambien en el libro RUTAP'. SI EXISTE: el libro trae DOS filas Alta para AD956UK con identicas Fecha_Alta 2025-12-10 y Fecha_Baja 2025-12-11, que difieren solo en Expte. Alta - una 'Ex-2025-53084543' y la otra 'Ex-2025-53390264'. O sea 7394 y 7400 no son un duplicado nuestro: son fieles al libro. La que SI es defecto de origen es la de expte_alta Ex-2025-53390264, porque su Expte. Baja es EX-2025-53390264, el mismo numero - una fila cuya baja apunta a su propia alta. Eso es del libro, no del import. Estado en PROD hoy: las 4 filas existen (4695 viva, 7394/7395/7400 con borrado_en), o sea el duplicado ya no se ve vivo. No borrar nada: son fieles a la fuente. Lo que queda es preguntarle a Eugenia por el expediente autoreferencial, y eso solo si el proximo libro no lo corrige.
• wi-cli-venus note · 6w ago
  NO ES UN DEFECTO NI DEL LIBRO NI NUESTRO - medido por db02 el 2026-09-04 sobre snapshot 10. Las dos filas de AD956UK con mismo (fecha_alta, fecha_baja) NO difieren solo por expediente: nro_interno es 160 en una y 147 en la otra, y las dos traen observaciones 'Cambio N de interno'. Los expedientes encadenan: la fila 162 CIERRA con EX-2025-53390264 y la fila 145 ABRE con ese mismo expediente. O sea el interno cambio 160->147 por ese expediente y el cambio ocurrio DENTRO del periodo, por eso las dos filas comparten fechas. Dos estados secuenciales, una sola ventana de calendario - exactamente la forma para la que se escribio el clasificador de MOVILBA-97. CONSECUENCIA PARA EL LOADER: nro_interno es el desempate TOTAL de la clave estable (dominio, fecha_alta, fecha_baja, ordinal) y no obliga a readmitir expedientes en la clave. OJO con la distincion: nro_interno hace la clave TOTAL (cada fila del libro mapea a exactamente una fila de historial), NO da ORDEN cronologico - eso solo lo da la cadena de expedientes, y el matching no necesita orden. Rama sin ejercitar: si dos filas de un mismo periodo comparten tambien nro_interno, PARAR Y CLASIFICAR, nunca elegir arbitrariamente ni caer al orden de fila.
• wi-cli-venus completed · 6w ago
  completed