El xlsx de RUTAP tiene 4 hojas y solo ingerimos una: Hoja2 trae 47 expedientes por dominio que nadie leyo nunca
db02-mba-l-cc 2026-08-20, verificado por coder-mba-l-cc leyendo el xlsx directo con openpyxl. El SSOT 2026-08-20-0211-Parque_RUTAP.xlsx tiene 4 hojas: Hoja1, Base, Hoja5, Hoja2. rutap.snapshots.hoja registra SOLO 'Base'. HOJA2 (48 filas, 47 de datos) ES LA IMPORTANTE: columnas DOMINIO | NUMERO EXPEDIENTE | Fecha | Titulo | Anexos. Es una tabla de expediente POR DOMINIO con fecha, por ejemplo AA865SH EX-2025-30092573--GCABA-DGGSM 2025-07-18. Toca directo a MOVILBA-46 (exigir expediente siempre) y a MOVILBA-69 (cobertura de expediente de los 131). Nadie la leyo nunca. Cruzarla contra vdc/historial ANTES de escribir nada en 69. Hoja1 (32 filas) y Hoja5 (14 filas) son pivots de control de Eugenia, no datos: Hoja1 cuenta filas abiertas por Linea x Unidad_Propulsora (total 1592), Hoja5 cuenta Carroceria (total 4946). Los dos estan DESACTUALIZADOS respecto de su propia hoja Base (1599 y 5086): los pivots de Excel no se refrescan solos. No ingerirlos como dato; sirven como control cruzado y como aviso a Eugenia. ALCANCE: leer Hoja2 e ingerirla con su propia procedencia (hoja + fila), NO mezclada con las filas de Base. Los pivots NO se ingieren. Y el importador debe REPORTAR toda hoja que no ingiere, en vez de ignorarla en silencio - que es como estas tres pasaron desapercibidas.
Activity
-
DONE, commit dea15f69. Hoja2 ingested into the sqlite SSOT as its own table rutap_expedientes (snapshot_id / hoja / fila_excel / dominio / expediente / fecha / titulo / anexos), 47 rows backfilled for snapshot 4, NOT merged into Base's rows. Hoja1 and Hoja5 deliberately not ingested - they are Eugenia's pivots and are 140 rows behind her own Base sheet. Separately shipped in d349f2ee: the importer now REPORTS every sheet it does not ingest, on every import, which is what makes the three-unread-sheets failure impossible to repeat silently. SCOPE LIMIT, explicit: this is in the SQLITE ONLY. Nothing loaded rutap_expedientes into Postgres - the rutap schema there holds snapshots and rutap_rows and nothing else - so no view, query or migration in prod can see Hoja2. Making it available to SQL against prod is a SEPARATE schema decision with its own GO. Ingesting it did NOT make either sheet authoritative: the Hoja2-vs-Base disagreements (expediente 30092573 on 10 plates vs 3; Fecha differing from fecha_alta by -103..+12 days on 46 of 47) stand unresolved and are questions for Eugenia (tracker rows 33 and 34). Reversal if ever wanted is one DROP TABLE on the sqlite plus a commit revert; nothing in prod depends on it.
-
Superseded by Elazar on 2026-09-03: Hoja2 has no approved application consumer and must not be imported. The operational importer now reads Base only; all other sheets are visibility-only reports. The retired SQLite stage and any rutap_expedientes copy are not part of the current workflow.