Fecha imposible en el SSOT: el expediente EX2026-17669949 aparece en una fila con Fecha Alta 1900-01-06 (AH924PV)
Detectado por db02 en el ensayo de MOVILBA-76 pasos 1+2 contra PROD, 06:22 del 2026-08-20. Prod tiene para AH924PV (vehiculo_historial id 4615) fecha_expediente 2026-04-15 con expediente EX2026-17669949. En el libro 2026-08-20-0211-Parque_RUTAP.xlsx ese mismo expediente esta en una fila cuya Fecha Alta es 1900-01-06 -- una fecha imposible, tipica de una celda de Excel que quedo como numero de serie 0 o similar. La carga de 76 deja tramite y fecha_baja en NULL para esa fila en vez de propagar la fecha imposible. Ver [[reference_impossible_dates_warn_on_import_abort_on_write]]. NO es un bloqueo del archivo de 76. PARA RESOLVER: confirmar con Eugenia la Fecha Alta real de ese expediente. Nota: AH924PV es el mismo dominio cuyo fecha_alta db-mba-l-cc sincronizo en prod esa misma noche (UPDATE 1 via rutap-sync-prod.sql), asi que conviene mirar las dos cosas juntas.
Activity
-
CONFIRMADO Y ES UNICO EN EL LIBRO (coder02, 06:23): fila 3673, Fecha_Alta 1900-01-06, SIN Fecha_Baja -- o sea que la fila VIVA del vehiculo es la que lleva la fecha imposible. Sobre las 5086 filas hay EXACTAMENTE UNA con Fecha_Alta anterior al anio 2000. 1900-01-06 es el serial 6 de Excel: una celda vacia o en cero renderizada como fecha. Dejarla en NULL es lo correcto; escribirla pondria un alta de 126 anios de antigueedad sobre un vehiculo vigente.
-
DUPLICADO - ya estaba resuelto y documentado desde el 2026-08-14 (Elazar, 06:25 del 08-20). AH924PV con Fecha_Alta 1900-01-06 esta EN CUARENTENA EXPLICITA en docs/migrations/2026-08-14-historial-por-tramite-backfill-rutap-PROD.sql: la fila entra en la tabla _skip_vigente con el motivo 'su fila abierta tiene Fecha_Alta 1900-01-06, corrupta en el origen', y el WHERE r.fecha_alta::date >= DATE '2000-01-01' la corta. Sus 2 tramites cerrados SI entran y su fila activa previa queda intacta; la cadena queda con un hueco desde 2026-04-15, y el propio script lo dice en un RAISE NOTICE. La abstencion de db02 en el ensayo de 76 pasos 1+2 es el MISMO manejo, correcto y consistente con lo ya decidido -- no es un hallazgo nuevo. LECCION, no el bug: cuatro carriles re-descubrimos de cero una decision documentada en docs/migrations/ hace seis dias. La cuarentena estaba en el codigo y no en ningun ticket ni en memoria, asi que nada la superficio. Antes de filear un dato raro del libro: grep en docs/migrations/.