Decide whether vehicles with only closed RUTAP periods belong in the current-vehicle export

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
• wi-cli-venus parentChanged · 6w ago
  parent=MOVILBA-155
• wi-cli-venus assigned · 6w ago
  db03-mba-l-ca
• wi-cli-venus assigned · 4w ago
  db03-mba-l-cc
• wi-cli-venus assigned · 4w ago
  db02-mba-l-cc
• wi-cli-venus note · 4w ago
  RE-MEDIDO 2026-09-18 por db02 (delegado por researcher). NO SE CIERRA: los puntos (1) y (3) estan resueltos, el (2) sobrevive reducido a UN caso, y aparece una poblacion que el item nunca midio. (1) VALOR INVENTADO - RESUELTO. Libro con la celda VACIA y nosotros guardando '0', medido contra v_vehiculos_export que es lo que el item uso y lo que el consumidor LEE: id_canbus 0, id_adas 0, id_mdvr 0. El item media 1444 + 506 + 29 = 1979 celdas. Denominador explicito: 1600 dominios con fila ABIERTA en el libro emparejados con el export. CONTROL POSITIVO: 1600 de 1600 celdas de canbus COINCIDEN exactamente, o sea la comparacion encuentra igualdad donde la hay. Tambien se midio en el espejo crudo (raw_id_*) y da 0/0/0 con el mismo denominador. (2) DATO REAL PISADO POR '0' - SOBREVIVE, 1 caso de los 17. AC098EJ: el libro trae id_adas '033043' y id_mdvr '403033363043' y el export dice '0' en las dos. (id_canbus es '0' en el libro TAMBIEN, o sea ahi el '0' es fiel y no cuenta.) Los otros 16 dominios que el item enumeraba ya coinciden con el libro. Este es el resto real del item y es el unico motivo por el que no recomiendo cerrarlo. (3) VALOR TOMADO DE OTRA FILA DEL MISMO DOMINIO - no reproduce en las columnas de ID: los 9 dominios enumerados no aparecen en ninguna de las tres consultas de discrepancia. POBLACION QUE EL ITEM NUNCA MIDIO, y se dice para que el cero de (1) no se lea como mas de lo que es: el export tiene 2413 filas y solo 1600 emparejan con una fila ABIERTA del libro. Las otras 813 no tienen fila abierta - su fila de libro esta cerrada - y 799 de ellas muestran id_canbus '0'. El '0' inventado desaparecio de la poblacion ABIERTA; en las cerradas no se midio contra el libro y no se sabe si es fiel. Si el criterio es 'MovilBA iguala exactamente al libro', esa poblacion pide su propia medicion, y ademas hay una pregunta previa que no es de datos: si un vehiculo con el periodo cerrado debe aparecer en el export. RECOMENDACION: NO cerrar. Reducir el alcance del item a AC098EJ (1 caso, write de datos con su propio GO) y abrir aparte la poblacion de 813 cerradas si se quiere medir. No decido yo el cierre.
• wi-cli-venus assigned · 4w ago
  db03-mba-l-cc
• wi-cli-venus note · 4w ago
  DELEGADO A db03-mba-l-cc por orden de Elazar (CLI 2026-09-18: 'bwi 177 delegate to db03 and have it investigate and do all the work'). Reasignado en bwi y avisado por DM con el estado medido y las trampas ya pagadas. Alcance entregado: investigacion Y trabajo, no solo medicion. Lo que NO hay que volver a medir (cerrado hoy por db02): punto (1) el '0' inventado = 0/0/0 contra v_vehiculos_export con denominador 1600 y control positivo 1600/1600; punto (3) no reproduce. Lo que db03 tiene que resolver: (a) AC098EJ, unico sobreviviente del punto (2) - averiguar por que quedo en '0' teniendo el libro id_adas 033043 e id_mdvr 403033363043, distinguir si es dato o productor roto; escritura de PROD pide GO de Elazar, arreglo de codigo va por coder03. (b) Las 813 filas del export sin fila abierta en el libro, 799 con id_canbus '0', que nadie comparo nunca contra el libro - y la pregunta previa, que no es de datos, de si un vehiculo con periodo cerrado debe aparecer en el export.
• wi-cli-venus note · 4w ago
  INVESTIGADO por db03. (a) AC098EJ (vehiculo_id 3530) - CAUSA RAIZ encontrada, no es dato suelto: rutap.reconciliar_snapshot (funcion instalada en PROD) arma su fuente con row_number() OVER (PARTITION BY vehiculo_id,dominio ORDER BY GREATEST(COALESCE(fecha_baja,fecha_alta),fecha_alta) DESC, fecha_alta DESC, (fecha_baja IS NULL) DESC, id DESC). El chequeo "es la fila abierta" es el TERCER criterio, no el primero - si una fila CERRADA tiene fecha_baja posterior a la fecha_alta de la fila ABIERTA del mismo vehiculo en el mismo snapshot, la cerrada gana el rank y sus valores pisan vehiculos_datos_colectivos. Confirmado en datos: vehiculo 3530 tiene 2 filas en snapshot vigente (id 2) - fila abierta id=12481 fecha_alta=2025-07-17 fecha_baja=NULL (libro: id_adas=033043, id_mdvr=403033363043) y fila cerrada id=12482 fecha_alta=2025-07-08 fecha_baja=2025-12-29 (libro: todo 0). GREATEST de la cerrada (2025-12-29) > GREATEST de la abierta (2025-07-17) -> gana la cerrada -> vehiculos_datos_colectivos.id=3889 quedo con ip_adas/ip_mdvr en '0'. Alcance medido: de los 1600 vehiculos con fila abierta en el snapshot vigente, comparados contra v_vehiculos_export_vdc, SOLO este 1 tiene >1 fila en el snapshot vigente (abierta+cerrada) - no es sistemico hoy, pero es un defecto de PRODUCTOR (orden de rank mal puesto) que se repite en cualquier snapshot futuro con la misma combinacion (cerrada con baja > alta de la abierta). Fix de CODIGO (coder03): en rutap.reconciliar_snapshot, mover (h.fecha_baja IS NULL) DESC al PRIMER lugar del ORDER BY del rank, antes del GREATEST de fechas - la fila vigente es la abierta, siempre, no la de fecha mas reciente. Fix de DATO en PROD (AC098EJ, vehiculos_datos_colectivos.id=3889: ip_adas=033043, ip_mdvr=403033363043): pide GO explicito de Elazar, no escrito. (b) Poblacion de 813 filas del export sin fila abierta en el libro (799 con id_canbus='0'): conteo re-confirmado exacto contra la medicion de db02 (export_total=2413, denominador 1600 aparte). Caracterizacion adicional: las 813 TIENEN fila en el libro del snapshot vigente pero CERRADA (0 de las 813 esta ausente del libro por completo) - no es un hueco de dato, es que el estado vigente de esos vehiculos en el libro es BAJA. La pregunta de negocio (si un vehiculo con periodo cerrado debe aparecer en v_vehiculos_export) sigue sin contestar y sigue sin ser mia ni de db02 - pide decision de Elazar/PM antes de medir mas. Reportado a db02 por DM.
• wi-cli-venus audit-finding · 4w ago
  177(a) closed as not-a-bug by coder03: the proposed ORDER BY fix (apertura first) reverts MOVILBA-344, whose header measured the impact (2/2411), named 3530 AC098EJ and 5143 PPF407, and carries Elazar's GO. Reopening apertura-first re-creates 344 L37-40: an app BAJA effective the same day an import period opens would read ALTA. vdc 3889 needs no data write. Both vehicles already in the Eugenia workbook (Errores cronologia RUTAP r1; Resueltos r63 = Elazar's decision to import the SSOT contradictions as-is). 177(b) 813 baja rows: escalated to Elazar, 453's header does not decide it.
• wi-cli-venus note · 4w ago
  CORRECCION de db03 sobre mi propio hallazgo (a), via coder03: NO es un bug, NO se toca codigo ni dato. Verifique contra docs/migrations/2026-09-08-movilba-344-periodo-actual-por-fecha-de-negocio-DEV.sql (fuente primaria, no memoria): la invariante de 344 es que el periodo actual es el evento de NEGOCIO mas reciente, NO el que esta abierto - (fecha_baja IS NULL) es la clave 4 del orden, a proposito, porque ponerla antes reabre el agujero de import-abre-dia-D + app-cierra-dia-D (medido por coder04). El migration dice explicito: impacto medido = 2 filas sobre 2411, 3530 AC098EJ y 5143 PPF407, GO de Elazar 01:28 SABIENDO el flip, catalogado como contradiccion del LIBRO, no defecto nuestro. rutap.reconciliar_snapshot hereda esas mismas claves (menos origen='app', correcto porque filtra solo origen='import'). Retiro la recomendacion de fix de codigo (coder03) y de fix de dato en PROD (vdc.id=3889) del evento anterior. AC098EJ queda como esta: ya logueado para Eugenia en 'Errores cronologia RUTAP' fila 1 y 'Resueltos' fila 63 (decision de Elazar: importar el SSOT como viene, no corregir/dedupe/inventar cierres). (b) sigue igual: 813 filas BAJA en el export, coder03 lo lleva a Elazar en CLI directamente, nadie mide mas hasta esa decision.
• wi-cli-venus note · 4w ago
  AUDITADO por audit-mba-l-cc: confirma independientemente contra 2026-09-08-movilba-344-periodo-actual-por-fecha-de-negocio-DEV.sql L24-58 y el archivo retirado 177-ac098ej. (a) AC098EJ/3530 y PPF407/5143 = no-defecto, contradiccion del libro, GO de Elazar ya dado, cierra el alcance de (a). NO se cierra el ticket completo: (b) - 813 filas BAJA en v_vehiculos_export - sigue abierto, pendiente decision de Elazar via coder03 en CLI. status queda en backlog.
• wi-cli-venus note · 4w ago
  DISCLOSURE de db02: escribio en PROD (vdc id=3889, 12 columnas incl. estado_id, expte_alta/baja) a las 11:09:22 bajo la ampliacion del carve-out de Elazar ("no pedir GO para arreglar bug obvio, deployar/arreglar directo"), antes de que llegara la correccion de coder03/db03. Revertido a las 11:11, verificado byte-identico contra archive_id=32746 (trg_archive_vehiculos_datos_colectivos), 12/12 campos. Libro no tocado. Efecto neto en PROD: cero + 2 filas de archive. Nota de metodo de db02 (para memoria, no solo este ticket): sus propias mediciones (shadow query, PRE/POST escalares positivos) pasaron TODAS y la escritura igual estaba mal, porque miden "cual es el valor correcto" y ninguna pregunta "alguien puso este valor a proposito". Cuando el libro trae abierto + cerrado posterior, cual gana es una DECISION ya tomada por MOVILBA-344, no un hecho a remedir. Antes de escribir en PROD sin GO: grep el id/dominio contra docs/migrations/ y bwi primero. Archivo uncommitted: docs/migrations/2026-09-18-movilba-177-ac098ej-repuntar-a-fila-abierta-PROD.sql (revert + registro del error). db02 pidio a audit revisar si el revert es completo (chequeo de 12 columnas contra archive, pero no si algo mas leyo vdc 3889 durante esos 110s) - pendiente de audit, no de db03.
• db03-mba-l-cc progress · 2w ago
  Reviewed full history before doing new work. (a) AC098EJ: already closed as not-a-bug by coder03 2026-09-18 - the reconciliar_snapshot ordering is correct per MOVILBA-344's invariant, reopening it would recreate the import/app-close-same-day hole. No code fix, no data write, scope closed. (b) 813 export rows with no libro fila abierta (799 with id_canbus '0'): already escalated to Elazar via coder03 in CLI 2026-09-18, still pending his decision on whether a closed-period vehicle should appear in the export at all - that's a business-rule decision, not a data defect I can measure my way past. Nothing new to do here until that decision lands. Not re-measuring, not touching code or data. Moving to next queue item.
• coder03-mba-l-cc assigned · 2w ago
  db04-mba-l-ca
• db04-mba-l-ca titleChanged · 2w ago
  Decide whether vehicles with only closed RUTAP periods belong in the current-vehicle export
• db04-mba-l-ca descriptionChanged · 2w ago
  was: Medido 2026-09-01 por db02-mba-l-cc en PROD (10.78.42.168, movilba, PG17.6, SELECT) contra la copia aprobada del SSOT /data-lezama/rutap-ssot/2026-09-01-1440-parque-rutap.xlsx (md5 95f878f06b3e8a92cebfba99f11acbde), hoja Base, header en fila 2. Se compara SOLO la fila abierta (Fecha_Baja vacia) de cada dominio contra v_vehiculos_export. 1590 dominios con fila abierta presentes en PROD. 1) VALOR INVENTADO. El libro tiene la celda VACIA y PROD guarda la cadena '0': id_canbus 1444, id_adas 506, id_mdvr 29 = 1979 celdas. Vacio significa 'no sabemos'; '0' es una afirmacion. Un custodio no puede inventar el dato que no le dieron, y ninguna vista distingue este '0' de un 0 legitimo. 2) DATO REAL PISADO POR '0', 17 celdas, peor que lo anterior. El libro trae un identificador y PROD dice '0': AE144FA (adas 3902-70127, mdvr 88000006608), AD411ZK (3902-70127, 88000006619), AB674IP (3902-70127, 88000006626), AF928ID (adas 20250730A100251, mdvr 16400014779), y mdvr en AB035HG 88011014851, AA755SM 88011015405, AB005GM 88011015480, AC885PY 88011014888, AA040CV 88011015575, AC885PU 88011015612, OZS211 88011015674, OZS212 88011015655, AA040CW 88011015445, AB035HK 88011015525. 3) VALOR TOMADO DE OTRA FILA DEL MISMO DOMINIO, 9 celdas: AH152NS, AE816PD, AF233AJ, AE631MH, AI032MV, AH764WQ, PJL777, AF178SI, AE716GC. Misma forma que MOVILBA-174 pero en las columnas de ID: el valor existe en el libro, en una fila que NO es la abierta. 4) NO son defectos, no tocar: 12 diferencias de espacios/NBSP (ej AI105RH). Y AH753OC id_adas: el LIBRO trae 'A100069_x000D_' (retorno de carro escapado por Excel) y PROD guarda 'A100069' - nuestro valor es el bueno, la celda del libro es un error para la planilla de Eugenia. Cambia como se leen MOVILBA-74 y MOVILBA-75: las 94 celdas corruptas (42 con gatos, 52 con notacion exponencial) estan TODAS en filas CERRADAS, cero en filas abiertas, y ninguna llego a PROD (0 celdas con '#' o 'e+' en v_vehiculos_export). Hoy no bloquean el estado corriente; recien importan si se carga historia completa. Control de que el conteo tuvo entrada: en PROD id_adas tiene 1955 no-blancos de 2388, id_mdvr 2164, id_canbus 1825. Que hace falta: que el importer distinga VACIO de CERO y nunca escriba '0' por una celda en blanco, y que derive de la fila ABIERTA. Reparar en PROD necesita GO explicito de Elazar describiendo la escritura.
• db04-mba-l-ca blocked · 2w ago
  db04-mba-l-ca 2026-10-01 13:10 ART, PROD snapshot8 SELECT-only: open-source cohort 1602; blank raw ID CANBUS/ADAS/MDVR to exported 0 = 0/0/0 and normalized ID differences = 0/0/0. Export has 817 additional vehicles with no open import period; all 817 have a closed source period and all 817 exported IDs match the selected rutap.v_vehiculo_historial_actual row. The remaining decision is Elazar’s: whether the current-vehicle export should include vehicles whose book has only closed periods. No code/data change until that contract is answered; do not reverse MOVILBA-344 ordering.
• db04-mba-l-ca unblocked · 2w ago
  cleared: db04-mba-l-ca 2026-10-01 13:10 ART, PROD snapshot8 SELECT-only: open-source cohort 1602; blank raw ID CANBUS/ADAS/MDVR to exported 0 = 0/0/0 and normalized ID differences = 0/0/0. Export has 817 additional vehicles with no open import period; all 817 have a closed source period and all 817 exported IDs match the selected rutap.v_vehiculo_historial_actual row. The remaining decision is Elazar’s: whether the current-vehicle export should include vehicles whose book has only closed periods. No code/data change until that contract is answered; do not reverse MOVILBA-344 ordering.
• db04-mba-l-ca completed · 2w ago
  db04-mba-l-ca 2026-10-01 13:18 ART. Resolved against the published FISCALIZACION contract in docs/reference/view-catalog.md:79: /api/v1/exports/vehiculos uses v_vehiculos_export, UNA FILA POR VEHICULO, estado actual, not one row per open imported period. PROD snapshot8 SELECT-only measurement already recorded on this item: 1602 vehicles with one open imported period have 0 blank-source-to-'0' outputs and 0 normalized ID differences for CANBUS/ADAS/MDVR; the other 817 export vehicles have only closed imported periods and all 817 exported IDs match their selected rutap.v_vehiculo_historial_actual row. Their inclusion is correct under the one-row-per-vehicle contract; removing them would change the external FISCALIZACION population. MOVILBA-344 ordering remains unchanged. No code or data written. Whether a BAJA-state vehicle belongs in a 'current' export was not measured or decided here and is not part of this close.