Paridad SSOT: des-esconder 2476 periodos cerrados marcados con borrado_en (12% -> 72% de coincidencia con el libro)
PRERREQUISITO de todo lo demas. Pedido de Elazar 2026-08-31: el dato de dev y prod tiene que parecerse al SSOT antes de tocar el esquema, si no llegan quejas del stakeholder. EL DATO NO FALTA, ESTA ESCONDIDO. Medido por coder02-mba-l-cc el 2026-08-31 por SELECT contra las dos bases y contra el libro 2026-08-31-0939 (hoja Base, 2394 dominios, 5260 filas): PROD: vehiculo_historial tiene 4225 filas, de las cuales solo 1740 estan VIVAS y 2485 borradas. De esas 2485, 2476 (99,6%) tienen fecha_baja NO NULA, o sea son periodos CERRADOS del libro. borrado_por esta VACIO en las 2485: no las borro ningun usuario, las marco el importador. DEV: 4339 filas, 1764 vivas, 2575 borradas, 2473 de ellas con periodo cerrado. Mismo defecto, misma proporcion. Hay exactamente UNA fila viva por vehiculo en prod (1740 filas vivas / 1740 vehiculos). El stakeholder que abre una ficha ve un renglon donde el libro tiene dos o tres. CUANTO VALE REPARARLO, comparando filas por dominio contra el libro: DEV PROD dominios en comun 2390 2388 filas TOTALES == libro 1737 (72%) 1736 (72%) filas VIVAS == libro 312 (13%) 305 (12%) con menos filas que el libro 636 648 con mas filas que el libro 17 4 O sea que el dato del libro YA ESTA CARGADO en el 72% de los dominios y la app muestra 12% porque solo lee filas vivas. IMPORTAR UN LIBRO MAS NUEVO NO ARREGLA ESTO: importar mas filas del mismo modo esconde mas filas. CONTRADICE UN CONTRATO YA ESCRITO. docs/design/rutap-full-history-refactor-plan.md dice textual: 'A RUTAP historic record remains visible after closure. borrado_en means an app deletion only; it must not model the end of a RUTAP period.' Y es la MISMA forma ya reparada una vez para vehiculos (reference_a_baja_stored_as_borrado_en_hid_650_vehicles, 650 vehiculos invisibles, arreglado el 2026-08-25): se reparo en 'vehiculos' y no en 'vehiculo_historial'. REPARACION PROPUESTA (la ejecuta el carril db, GO por item, ensayo primero): UPDATE que limpia borrado_en donde marca cierre de periodo y no borrado de app. Criterio: borrado_en IS NOT NULL AND borrado_por IS NULL AND fecha_baja IS NOT NULL. En prod son 2476 filas. Es UPDATE, no DELETE. Guardar la lista de ids antes: es reversible. LAS 9 FILAS DE PROD BORRADAS CON PERIODO ABIERTO QUEDAN AFUERA de la pasada masiva y se miran una por una: o son borrados genuinos o son duplicados. GATES POSTERIORES: 1. La paridad de filas vivas por dominio tiene que subir a ~72%. 2. NINGUN dominio puede quedar con MAS filas vivas que el libro. 3. RIESGO QUE NADIE LEVANTO: v_vehiculos_hist_ultimo toma la ultima fila viva, y v_vehiculos_lineas_entidades resuelve linea y entidad A TRAVES de esa vista. Des-esconder 2476 filas CAMBIA cual es 'la ultima fila' para 1736 dominios. La API de Rendiciones (MOVILBA-144, shipeada 08-31, key minteada) lee esa vista. HAY QUE MEDIR QUE DEVUELVE ESA API ANTES Y DESPUES, no solo los conteos de historial. Plan completo y reparto por carril: docs/design/2026-08-31-paridad-ssot-y-historial-ancho-plan.md
Activity
-
parent=#3172
-
Part 1 would expose pre-handoff Excel periods in user-facing vehiculo_historial, contradicting Elazar’s zero user-history-at-handoff requirement and recreating the stakeholder complaint. Redesign required: selected-book current baseline plus raw provenance, not unhidden app history.
-
RETIRADO de la ventana de esta noche, y con una correccion mia al encuadre. EL TITULAR DE ESTE ITEM EXAGERABA EL PROBLEMA. '12% de coincidencia con el libro' se lee como '88% del dato mal'. Era coincidencia de CANTIDAD DE FILAS DE HISTORIAL, no de correccion del dato. Medido despues contra el libro del 08-31, el estado ACTUAL - lo unico que ve un stakeholder - ya coincide: Linea 1424/1424 (100%), Interno 1594/1594 (100%), Estado 2380/2388 (99%, 8 difieren). O sea que el objetivo declarado por Elazar ('que el dato se parezca al SSOT') YA ESTA SATISFECHO para el estado actual. Lo que no coincide es la PROFUNDIDAD del historial, y arreglar eso choca con el contrato de handoff (historial de usuario en cero). db03-mba-l-ca y coder-mba-l-ca bloquearon 1.1 con razon. De los 8 estados que difieren: AG986KG ya esta filado (MOVILBA-157), y AE548EX / AE992PE son los origenes de las transferencias de equipo del delta 08-27->08-31, o sea que se cierran con el import. RETRACTO ADEMAS UN RAZONAMIENTO, no solo la conclusion. Este item decia 'no las borro ningun usuario, borrado_por esta vacio en las 2485'. db02-mba-l-cc midio que borrado_por es NULL en las 2485 y non-NULL en 0: la clausula NO DISCRIMINA NADA en prod y no puede sostener esa inferencia. En DEV si discrimina - audit-mba-l-cc midio 53 filas con borrado_por poblado, ninguna con fecha_baja. El unico predicado que separa es fecha_baja IS NOT NULL, y excluye 9 filas que hay que leer a mano. QUEDA EN PIE EL DEFECTO DE FONDO: borrado_en esta sobrecargado para significar 'periodo cerrado del libro', que el plan de refactor prohibe por escrito. La salida correcta es la de db02 y no la habia visto: DES-ESCONDER EN LA TABLA Y FILTRAR EN LA VISTA, marcando lo pre-handoff por provenance y no por borrado_en. Eso vive en MOVILBA-167, no aca, y no se ejecuta suelto. RIESGO DE VISTA: MEDIDO E INERTE. Simulado sin escribir por mi y reproducido independientemente por db02: des-esconder las 2476 cambia la fila elegida para 3 vehiculos de 1740; linea_id cambia en 0, entidad_id en 0. La razon (db02): el ORDER BY de v_vehiculos_hist_ultimo arranca con un EXISTS cuya subconsulta no filtra borrado_en, o sea que ya ve todas las filas borradas. La API de Rendiciones no se mueve. Los 3 son PQP070, AE060XC, AE631MI. LO QUE QUEDA COMO TRABAJO REAL DE PARIDAD: importar los 648 dominios sin filas + los 6 ausentes. Es MOVILBA-155 y es del carril de db03-mba-l-ca, dueño del import, los scripts y la corrida. No es mio y no lo diseño yo. Plan actualizado con la correccion v2: docs/design/2026-08-31-paridad-ssot-y-historial-ancho-plan.md
-
Per PM decision: storage un-hide remains required, but 1.1a cannot ship until 1.1b filters pre-handoff RUTAP rows from the user-facing history by reliable provenance (first or same transaction-window). No GO. borrado_por is a no-op; inspect the 9 open-period rows separately.
-
db03-mba-l-cc
-
db02-mba-l-cc
-
db04-mba-l-ca
-
db04-mba-l-ca 2026-09-24 04:03 -03 — SELECT-only current-state check: DEV movilba_dev snapshot 18 and PROD movilba snapshot 5 both identify 2026-09-19-0648-parque-rutap-corrected.xlsx with 5528 source rows. The closed-period visibility/parity gate was not rerun against the replacement history and current book. Status unchanged; no DB write.
-
cleared: Per PM decision: storage un-hide remains required, but 1.1a cannot ship until 1.1b filters pre-handoff RUTAP rows from the user-facing history by reliable provenance (first or same transaction-window). No GO. borrado_por is a no-op; inspect the 9 open-period rows separately.
-
db04-mba-l-ca 2026-09-28 12:56 ART: The proposed mass UPDATE of public.vehiculo_historial.borrado_en is obsolete after MOVILBA-318 retired that table. Installed SELECT in PROD movilba and DEV movilba_dev: to_regclass('public.vehiculo_historial') is NULL in both. PROD current snapshot 7 has 5545 imported normalized history rows, 3943 closed periods, 0 with borrado_en; public.v_vehiculo_historial returns all 5545 rows. DEV snapshot 18 has 5528 imported normalized rows, 3929 closed, 0 with borrado_en; public.v_vehiculo_historial returns 5587 total including app history. Thus the old 2476 hidden-row population no longer exists and the new history is visible without un-hiding. No DB write. Any remaining post-handoff user-history presentation/design work stays under parent MOVILBA-167, not this retired-table update.