Re-medir la hoja Errores cronologia RUTAP contra el libro vigente
La hoja 'Errores cronologia RUTAP' del tracker (/data-lezama/movilba/import-reports/todo-rutap-importacion-prestaciones.xlsx) tiene 244 filas y su encabezado esta pineado al snapshot del 2026-09-01, o sea que toda la hoja esta medida contra un libro viejo. Censada por db03 el 2026-09-30: no se re-midio en la pasada de la hoja Datos porque el emparejamiento cronologico (fila + fila paralela) no es un diff de un solo campo. Entregable: un CSV con un veredicto por fila (VIGENTE / YA_NO_CIERTO / DOMINIO_AUSENTE / NO_MEDIDO) contra el libro vigente 2026-09-30-1305, con el par de filas que sustenta cada veredicto y el valor actual del libro para las que dejaron de ser ciertas. La fidelidad se mide contra el libro pineado, nunca contra filas de PROD o DEV. El archivo lo escribe el carril coder, no este item.
Activity
-
db03-mba-l-cc, 2026-10-01 09:40 ART. Antes de re-medir: la hoja 'Errores cronologia RUTAP' declara dims A1:Y245 / max_row=245 (el item cita 244 filas de ese numero), pero iter_rows() muestra UNA sola fila de datos real (fila 5, dominio AC098EJ) - filas 6-245 estan completamente vacias, confirmado tanto con data_only=True (valores) como data_only=False (sin formulas sin evaluar tampoco). max_row miente, como ya documenta el protocolo del tracker - aca minte por 244 filas, no por una sobra menor. El denominador real de este item es 1, no 244. Re-medida esa unica fila contra snapshot 8 (2026-09-30-1305): el error original (fila vieja 3454 del libro 2026-09-17-0942, Modif con fecha_alta 2025-07-17, anterior a la fecha_baja 2025-12-29 que el mismo expediente EX-2025-55684039 produce en la fila 3376) YA NO EXISTE. En snapshot 8, AC098EJ tiene 2 filas: fila_excel 1210 Alta fecha_alta 2025-07-08 fecha_baja 2025-12-29 (expte_baja EX-2025-55684039), y fila_excel 5315 Modif fecha_alta 2025-12-29 (= exactamente la fecha_baja de la fila anterior, cadena por el mismo expediente EX-2025-55684039), sin fecha_baja (abierta). La fecha 2025-07-17 no aparece en ningun lado de la cadena actual. Veredicto: YA_NO_CIERTO - el libro corrigio la fecha, la inconsistencia cronologica reportada ya no esta. SIN EJERCITAR: las 244 filas que el item esperaba (no existen en el archivo hoy, se reporta la ausencia, no se inventa contenido); ningun otro dominio de esta hoja mas alla de AC098EJ.
-
coder03-mba-l-cc 2026-10-01 13:06 -03 - provenance de las filas faltantes, medida contra los 130 respaldos de /data-lezama/movilba/import-reports/archived y no inferida. db03 tiene razon en que las 244 anotaciones declaradas no existen y en que max_row 245 es inflado, pero la hoja SI tuvo filas reales y conviene que quede escrito que no se perdieron: el 2026-08-31 la hoja 'Errores cronologia RUTAP' tenia 27 filas de datos, el 2026-09-02 bajo a 3, el 2026-09-05 a 1, y desde el 2026-09-18 viene con 2. La caida del 09-02 fue deliberada: el archivo 2026-09-02-cronologia-descartada-registro-interno.xlsx tiene una hoja 'Cronologia descartada' cuyo encabezado dice literalmente 'Filas que estuvieron en Errores cronologia R...' con 20 filas de datos. O sea que las filas se movieron a un registro interno a proposito, no las borro un script. No hay perdida de dato que investigar y la medicion de db03 queda en pie: una sola fila real, AC098EJ, y su error de cronologia YA NO ES CIERTO contra el snapshot 8 porque el libro ahora trae la cadena limpia -alta 2025-07-08, baja 2025-12-29 y Modif que abre el mismo 2025-12-29 por el mismo expediente. No medido: el contenido fila por fila de las 20 descartadas contra el libro vigente; nadie reviso si alguna volvio a ser cierta.
-
completed