Un municipio cuyano con 11 sistemas: el día que cayó la planilla
Mesa de entradas en SQL Server, catastro en FoxPro, tributos en una nube provincial, sueldos en Excel: el municipio caminaba sobre una planilla compartida. Hasta que la abrieron dos al mismo tiempo.
Un viernes de mayo a las 11:40 de la mañana, dos administrativas del área de Catastro de un municipio cuyano de 80.000 habitantes abrieron al mismo tiempo el archivo padron_unico_v17_FINAL_uso_real.xlsx desde la red. Una corrigió un domicilio. La otra dio de baja un contribuyente. El que guardó después borró el cambio del primero. Nadie se enteró hasta tres semanas más tarde, cuando llegó una intimación de tributos al titular dado de baja por error. Esa planilla — 11.300 filas, 47 columnas, 14 hojas — era la única "tabla maestra" que conectaba los once sistemas del municipio.
El problema, en términos humanos
La queja que le llega al intendente no es técnica. Es: "vine al municipio, me hicieron ir a tres oficinas, me pidieron el mismo formulario tres veces, y al final me dijeron que el sistema decía algo distinto". El esquema federal de unificación tributaria, formalizado en el Registro Único Tributario - Padrón Federal, recorre exactamente ese problema entre AFIP, las administraciones provinciales y los municipios. La auditoría posterior del caso de esta nota contó: cuatro bases SQL Server distintas, dos aplicaciones en FoxPro, un sistema de tributos hospedado por la provincia, dos planillas de Google, un sistema de sueldos sobre escritorio y un mostrador con cinta scotch.
Cuando los sistemas no comparten un identificador único, la diferencia de un dígito en un DNI rompe el cruce. El municipio caso de esta nota tenía cinco "padrones únicos" distintos. La planilla maestra de catastro era el quinto, y vivía en una carpeta compartida sin control de versiones.
Por qué la solución obvia ("compremos un ERP") nunca arrancó
Dos veces en los últimos seis años, el municipio había firmado convenio con un proveedor para implementar un ERP municipal completo. Las dos veces el proyecto se cayó: la primera, porque el gobierno cambió y el sucesor no quiso heredar el contrato; la segunda, porque la migración de catastro requería cargar 30.000 expedientes en papel que estaban en un sótano húmedo. La factura conjunta acumulada de los dos intentos: USD 412.000, sin un solo módulo en producción. Toda la teoría de integración municipal que publica TangoID coincide en lo mismo: el problema no es de software, es de gobernanza del dato.
La conclusión incómoda que costó dos gestiones: los sistemas heredados no se reemplazan en un municipio mediano. Se integran.
La salida: una pila de integración, no de reemplazo
Lo que se montó en cuatro meses, con un equipo de dos desarrolladores y una funcionaria responsable del proyecto, fue una pila de integración explícita. Postgres 17 como base maestra de personas, domicilios y actos administrativos, con una sola tabla persona con CUIT/DNI normalizado y triggers de auditoría. n8n autohospedado como capa de integración: 36 flujos que leen los sistemas heredados — incluyendo los de FoxPro vía CSV nocturno — y empujan los cambios al maestro. PostgREST delante de la base maestra, exponiendo lectura por API a las nuevas pantallas. Metabase para los tableros del intendente y los secretarios. Y un Keycloak chico, integrado al directorio activo del municipio, para que cada login deje rastro.
El SQL Server de mesa de entradas, los dos FoxPro y el sistema de tributos provincial siguen funcionando. La diferencia es que ahora hay una verdad única detrás, y los nuevos servicios — turnero, app de reclamos, tablero de gestión — leen de ahí. La planilla padron_unico_v17_FINAL_uso_real.xlsx se archivó en read-only un día martes a las 4 de la tarde, con champagne barato y un cartel impreso pegado en la oficina.
A cuatro meses del go-live: cero incidentes de doble edición, tiempo promedio de un trámite de catastro reducido de 7,2 a 2,1 días según la propia auditoría interna del municipio, y una sola planilla compartida sobreviviente — la del calendario de cumpleaños.
Qué hay que mirar antes de copiarlo
Tres advertencias para cualquier municipio que mire este patrón. La primera: la integración no es un proyecto, es una práctica. Si no nombrás un equipo permanente que cuide los flujos de n8n, el primer cambio en el FoxPro de catastro rompe todo en silencio dos meses después. Recomendación: una persona, mitad de su tiempo, y un calendario de revisión mensual escrito en un Google Calendar compartido. La segunda: identidad antes que datos. Si no resolvés primero el padrón único de personas — con regla escrita para resolver duplicados, no a criterio del que carga — el resto es decoración. Hay que decidir si gana el CUIT, el DNI o el correo, y aceptar el costo de los casos que pasan a manual. La tercera, la política: el convenio con el sistema provincial de tributos te entrega los datos "como vienen". Negociar SLA en la entrega del archivo nocturno es más útil que cualquier tablero. Si el archivo llega tarde, el tablero miente al intendente y la sospecha de que "el sistema no anda" se instala para todo el año.
La planilla maestra todavía aparece en el cumpleaños del jefe de catastro como meme. Pero ya no decide quién paga el ABL.