AG986KG esta de baja en PROD por un expediente que el libro documenta como error de abril - caso de verificacion del import-reemplaza de MOVILBA-155
Verificado en PROD por db02-mba-l-cc el 2026-08-31 tras el hallazgo de coder02-mba-l-cc. PROD muestra el dominio AG986KG DE BAJA (vehiculos_datos_colectivos.estado_id=117) sobre la base de un expediente que el propio libro documenta como error. EVIDENCIA, las dos puntas: - Libro 08-31, fila unica de AG986KG: Tramite=Alta, Fecha_Alta 2026-04-15, **Fecha_Baja VACIA**, Observaciones: 'Se dio de baja por error el 21/04 con EX-2026-18235670- -GCABA-DGGSM.' - PROD, vehiculo_historial id 10622 (viva): fecha_baja 2026-04-21, expte_baja EX-2026-18235670, y la ficha en 117. O sea: Eugenia corrigio el error en ABRIL borrando la baja de su libro, y MovilBA lo sigue mostrando de baja desde entonces porque nuestro import mezcla en vez de reemplazar. No hace falta preguntarle nada - el libro ya contesta, con la explicacion escrita en Observaciones. POR QUE NO ES UN ITEM DE REPARACION SUELTO: si el import REEMPLAZA la historia del dominio en vez de mergearla (ver MOVILBA-155 y el analisis de coder02), este caso se arregla solo al importar el libro del 08-31. Sirve entonces como CASO DE VERIFICACION POST-IMPORT: despues de importar, AG986KG tiene que quedar con una sola fila, sin fecha_baja, y la ficha en ALTA. Si sigue en 117, el import mergeo y el reemplazo no funciono. NO ESCRIBIR A MANO antes del import. Un UPDATE directo aca esconderia justamente la falla que este caso sirve para detectar.
Activity
-
parent=MOVILBA-155
-
MEDIDO 2026-09-03 (db02): AG986KG contra los 7 libros archivados. El libro del 2026-08-24 lo tiene en BAJA; desde el 2026-08-26 y en todos los posteriores, incluido el vigente 2026-09-03-1049, lo tiene ABIERTO. PROD guarda BAJA (ficha estado_id 117; fila de historial fecha_baja 2026-04-21, estado_id NULL, creado_por='import-movilba-19'). O sea PROD es FIEL al libro del 08-24 y no aprendio la reapertura. Esto es exactamente el caso de verificacion que el item plantea: el import-reemplaza de MOVILBA-155 tiene que dar vuelta este vehiculo a ALTA por si solo, porque el libro nuevo RE-DECLARA la historia del dominio. Si despues del import AG986KG sigue en BAJA, el import no esta reemplazando y ESE es el hallazgo. Ya anotado tambien en MOVILBA-213 como el grupo B.
-
db02 2026-09-05: AG986KG es la UNICA exclusion deliberada de la reparacion de MOVILBA-255, y ahora se sabe por que. De los 108 pares (vehiculo_id, fecha_alta) con dos filas activas del mismo periodo, 107 tienen la fila CERRADA como la verdadera y el libro los confirma campo por campo. AG986KG (fecha_alta 2026-04-15, ids 10058 cerrada/mas vieja y 10817 abierta/mas nueva) es el unico donde el libro le da la razon a la fila ABIERTA - trae la observacion larga que explica la baja por error de abril, mientras la cerrada trae la frase generica - y es tambien el UNICO de los 108 donde la abierta es la mas nueva por creado_en. Las dos propiedades coinciden en el mismo par y en ningun otro. Por eso la migracion de 255 lo excluye por PROPIEDAD (abierta.creado_en > cerrada.creado_en) y no por dominio, y su gate de entrada aborta si esa clase queda vacia. Repararlo a mano dentro de una migracion mecanica de 107 filas es como una poblacion deja de ser re-derivable: este item se decide aparte.
-
db04-mba-l-ca
-
db04-mba-l-ca 2026-09-24 03:56 ART. PROD SELECT on public.v_vehiculos_export returns AG986KG|Alta|2026-04-15|NULL fecha_baja|NULL expediente_baja; PROD SELECT on rutap.v_rutap_latest_norm for dominio_norm=AG986KG returns the same open 2026-04-15 period and no baja. The originally reported false BAJA is absent in the installed PROD projection and the current snapshot.