Cash Control
Primera plataforma con integración nativa a ASPEL SAE para automatización de cobranza con IA en PyMEs mexicanas. Este case study documenta el reto técnico principal: conectar inteligencia artificial a Firebird, la base de datos de los 90s que nadie había integrado antes.
El reto de integración que nadie había resuelto
ASPEL SAE controla aproximadamente el 60% del mercado de ERP para PyMEs mexicanas. Su base de datos es Firebird — una tecnología de los años 90 que prácticamente no tiene integraciones modernas, documentación oficial del esquema, ni soporte para APIs REST.
El problema concreto: un agente de IA de cobranza necesita leer las facturas vencidas del ERP del cliente para saber a quién cobrar, cuánto, y cuándo. Sin eso, el agente opera en el vacío.
- ✗ Exportar a CSV/Excel manualmenteElimina la automatización. El punto es que el agente actúe sin intervención humana.
- ✗ Usar la API oficial de ASPELNo existe una API pública de datos para ASPEL SAE en versiones on-premise.
- ✗ Migrar el ERP del clienteNadie cambia su ERP. El conector debe adaptarse al cliente, no al revés.
Sistema completo
Cash Control no es un script de cobranza. Es una plataforma SaaS multi-tenant donde cada cliente tiene su propio conector a su instancia local de ASPEL SAE y su propia cartera de deudores gestionada por el agente.
ASPEL SAE (Firebird DB)
↓ Conector Python (solo lectura, cifrado 256-bit)
Cash Control Backend (.NET 9 / Azure)
├── API de autenticación multi-tenant
├── Motor de segmentación de cartera
│ └── Agente IA (Claude API)
│ └── Clasifica deudores por comportamiento
├── Orquestador de comunicaciones
│ ├── WhatsApp Business API
│ ├── Email (SendGrid)
│ └── SMS (en roadmap)
└── CRM de cobranza
├── Historial de contactos
├── Scoring de recuperabilidad
└── Dashboard de resultadosConectar Python a Firebird
El conector usa fdb (o firebird-driver en versiones recientes) para conectarse directamente a la base de datos de ASPEL. La conexión es de solo lectura — el conector nunca escribe en el ERP del cliente. Principio de menor privilegio aplicado desde el diseño.
ASPEL SAE tiene ~200 tablas y 0 documentación oficial. El schema se obtuvo por reverse engineering: instalación limpia, exploración con DBeaver, correlación de tablas con comportamiento visible en la UI.
ASPEL SAE existe en versiones 4.x, 5.x y 6.x con schemas diferentes. El conector detecta la versión y aplica el mapeo correcto. En la práctica, ~80% de clientes usan versión 5.x.
ASPEL no está en la nube — está en el servidor o PC del cliente. El conector se instala en la red local del cliente como servicio Windows y se comunica con Cash Control vía HTTPS.
Las credenciales de Firebird se almacenan cifradas localmente (AES-256). La comunicación con el backend de Cash Control usa mTLS. El cliente nunca expone Firebird al internet.
Cómo el agente "cobra"
El agente lee la cartera vencida de ASPEL, segmenta a los deudores por comportamiento histórico, y genera mensajes de cobro adaptados a cada segmento. No es un template de WhatsApp — es un mensaje generado por Claude API con contexto específico del cliente.
El resultado es que los destinatarios frecuentemente no se dan cuenta de que el mensaje es automatizado. Ese fue el criterio de calidad durante el desarrollo: si parece spam, el prompt falla.
Arquitectura en Azure
.NET 9 Minimal APIs. Elegí .NET sobre FastAPI porque la madurez del runtime de Microsoft para workloads de producción justifica la curva de aprendizaje.
Next.js 16 con App Router. Static export para el sitio público, SSR para el dashboard del CRM.
Aislamiento por tenant_id en todas las queries. Cada empresa ve solo su propia cartera. Las credenciales de Firebird son por tenant, cifradas en reposo.
Azure Container Apps. Auto-scaling basado en cola de mensajes — el orquestador de comunicaciones escala horizontalmente en picos de envío.
PostgreSQL para datos de Cash Control. Firebird del cliente es solo lectura, nunca migrado.
Empezar con PostgreSQL desde el día 1 en lugar de SQLite. Migrar el schema multi-tenant a las 3 semanas fue costoso.
Lo que fue difícil, lo que funcionó, lo que cambiaría
- — ASPEL SAE: 200+ tablas, 0 documentación del schema
- — Los clientes tienen ASPEL en red local — el conector debe funcionar con VPN o túnel
- — Multi-tenancy con Firebird: cada cliente tiene su propia instancia física del ERP
- — Playwright para envíos donde no hay API — frágil ante cambios de UI
- — Claude API para mensajes de cobro: los usuarios no los identifican como automatizados
- — Azure Container Apps para auto-scaling en picos de envío
- — El funnel diagnóstico como lead magnet: 46 visitas desde 1 solo post orgánico
- — fdb (Python) funciona de forma confiable con Firebird 2.5 y 3.x
- — PostgreSQL desde el día 1, no SQLite con migración posterior
- — Diseñar el schema multi-tenant antes del primer feature
- — Invertir más en testing del conector Firebird — las diferencias de versión ASPEL no son triviales