Saltar al contenido
MIGRACIÓN

Migrar de SICtax a Terraes · 7 pasos sin perder histórico catastral

SICtax es un sistema fiscal municipal sólido para impuesto predial, vehículos e ICA. Su módulo de catastro funcionó bien cuando el catastro era una herramienta de hacienda. Hoy, con el catastro multipropósito (R.388 IGAC) que exige LADM-COL, EPSG:9377, RIC/XTF al SINIC y portal ciudadano, SICtax queda corto en el componente catastral pero sigue siendo válido en el componente fiscal.

La pregunta correcta no es "¿reemplazo SICtax?" sino "¿cómo separo el catastro multipropósito del impuesto predial, sin romper lo que ya funciona?" Este post desagrega los 7 pasos.

Paso 0 · Decisión estratégica

Antes de mover datos, defina el modelo objetivo:

  • Catastro en Terraes (R.388 IGAC, LADM-COL nativo, conservación, portal ciudadano, RIC/XTF para SINIC)
  • Impuesto predial sigue en SICtax (cálculo, facturación, cobro coactivo, integración con tesorería)
  • Interface bidireccional entre los dos: Terraes envía avalúos actualizados, SICtax envía pagos para validar estado del predio

Esta arquitectura es la que tiene menos riesgo y mayor adopción. Reemplazar SICtax completo es un proyecto distinto y más grande.

Paso 1 · Diagnóstico de la base SICtax

Sesión técnica con el equipo de TI municipal:

  • ¿Qué versión de SICtax tienen?
  • ¿La base es PostgreSQL, Oracle o SQL Server?
  • ¿Cuántos predios urbanos y rurales hay registrados?
  • ¿Qué año tiene la última actualización catastral aplicada?
  • ¿Hay histórico de mutaciones o solo el estado actual?
  • ¿Hay fotografías, soportes documentales o solo metadata?

El diagnóstico identifica vacíos antes de migrar — si SICtax no tiene histórico de mutaciones, esa información no se puede recuperar y hay que decidir si se reconstruye o se acepta la pérdida.

Paso 2 · Mapeo de campos SICtax → LADM-COL

SICtax usa su propio modelo de datos. LADM-COL exige clases específicas:

| Concepto SICtax | LADM-COL | Notas | |---|---|---| | Predio | LA_BAUnit | Unidad básica administrativa | | Propietario | LA_Party | Persona natural o jurídica | | Linderos / polígono | LA_SpatialUnit | Geometría con tolerancia EPSG:9377 | | Avalúo | LA_Valuation | Histórico de avalúos por vigencia | | Mutación | LA_AdministrativeSource | Documento que motiva el cambio | | Tradición | LA_RRR (Right) | Derecho real con vigencia |

El mapeo se documenta como anexo técnico del contrato. Lo que SICtax tenga lo bajamos a LADM-COL; lo que no, queda explícito como gap a llenar en la actualización.

Paso 3 · Extracción controlada de datos

Tres formatos de extracción ordenados por preferencia:

  • Acceso directo a la base (read-only) — permite extracción incremental y reextracción cuando hay correcciones. Requiere autorización del proveedor SICtax y configuración de TI.
  • Exports estructurados (CSV, GeoPackage, GeoJSON) — generados desde SICtax con consultas SQL acordadas.
  • Reportes PDF / Excel — último recurso. Lectura semiautomatizada con riesgo de error.

La extracción se hace en ambiente de pruebas primero, nunca contra producción. Terraes nunca toca la base operativa de SICtax durante la migración.

Paso 4 · Carga estructurada en Terraes con bitácora

Cada registro migrado queda con:

  • Fuente: "Migración SICtax · YYYY-MM-DD"
  • Fecha de carga
  • Mapeo aplicado (campo SICtax → campo LADM-COL)
  • Validaciones que pasó
  • Validaciones que fallaron (y por qué)
  • Estado: importado, revisado, validado, rechazado

La bitácora es auditable. Si un mes después se descubre que un campo se mapeó mal, el histórico permite trazar el error y corregirlo.

Paso 5 · Validación topológica y consistencia

LADM-COL exige reglas que SICtax no necesariamente respetaba:

  • Cierre topológico (cada polígono predial cerrado)
  • No solapamiento entre predios (excepto servidumbres y restricciones específicas)
  • Vecindad consistente (qué predios colindan con qué)
  • Geometría dentro del límite municipal
  • Coherencia entre área catastral y área georreferenciada

Predios que fallan reglas se separan en un lote de "revisión" para corrección en oficina o validación en campo. No se importan con errores: se importan o quedan marcados para resolver.

Paso 6 · Interface bidireccional con SICtax

Con catastro ya en Terraes y SICtax operando el impuesto predial, se construye la interface:

  • Terraes → SICtax: notificación de mutaciones de avalúo (tipo V), cambios de área (II), cambios de propietario (I), englobes/desenglobes (III) y cambios de uso/destino (IV). Vía API REST con autenticación token y reintentos automáticos.
  • SICtax → Terraes: notificación de pagos, suspensiones de cobro, predios en cobro coactivo. Permite que el portal Mi Predio refleje estado del trámite.

La interface se documenta como anexo técnico. GEOSAT acompaña la implementación inicial y deja la sincronización operativa documentada para el equipo de TI del municipio.

Paso 7 · Cierre técnico y handoff

Antes del go-live:

  • Reconciliación: total de predios en Terraes == total en SICtax (con explicación documentada de cualquier diferencia)
  • Reconciliación de avalúos por vigencia
  • Pruebas de la interface con casos reales (mutación tipo I, II, III, IV, V)
  • Validación de portal Mi Predio con muestreo aleatorio
  • Generación de XTF para SINIC con la base migrada (validable antes de radicar)
  • Capacitación al equipo operativo (16–24 horas)
  • Documentación de runbook para incidentes operativos

Go-live se hace por fases, nunca de un golpe. Primero conservación con base migrada; luego, cuando la operación esté estable, actualización masiva si aplica.

Errores típicos a evitar

  1. Migrar sin diagnóstico — descubrir gaps de información durante el go-live es muy caro.
  2. No documentar el mapeo — cualquier corrección futura requiere arqueología.
  3. Romper SICtax — la operación fiscal NO se detiene durante la migración.
  4. Saltar la validación topológica — predios con geometría rota explotan al generar XTF.
  5. No capacitar a oficina — equipo que no entiende la herramienta no la usa bien.
  6. Cerrar interface antes de estabilizar — sin sincronización predial-fiscal hay desfase de avalúos.

Costo y tiempo típicos

Para municipio mediano (15.000–40.000 predios):

  • Diagnóstico + mapeo: 2–3 semanas
  • Extracción + carga + validación: 4–6 semanas
  • Interface bidireccional con SICtax: 2–4 semanas (en paralelo)
  • Capacitación + go-live por fases: 2 semanas
  • Total: 10–14 semanas hasta operación estable

El costo escala con el volumen y la complejidad del diagnóstico. Para una cotización defendible, solicite mesa técnica con el equipo de TI municipal en agenda.

En resumen

Migrar de SICtax catastro a Terraes no es reemplazar el sistema fiscal. Es separar dos cosas que el mercado ya separó: el catastro multipropósito (R.388 IGAC, LADM-COL, SINIC) y el impuesto predial (cálculo, facturación, cobro).

Cada uno se hace mejor con la herramienta diseñada para su rol. La interface bidireccional mantiene la coherencia. Y el histórico catastral, si se migra con bitácora desde el principio, queda trazable para inspección y para futuras correcciones.