Consolidación y avisos de cobranza sobre el ERP

Contexto

Un grupo empresarial B2B opera tres de sus empresas sobre el mismo sistema ERP. La información de cuentas por cobrar de las tres vivía únicamente ahí, sin consolidarse entre ellas y sin generar avisos automáticos a los clientes. Se decidió construir una aplicación que tomara esos datos del ERP y los complementara, sin reemplazarlo como fuente de verdad.

Problema

La falta de consolidación impedía tener una vista única de la deuda de clientes entre las tres empresas, calcular antigüedad de vencimientos y automatizar el aviso de cobranza. Durante el desarrollo, una reconciliación contra el ERP detectó alrededor de 374 facturas que la aplicación seguía mostrando como abiertas pese a estar ya pagadas o canceladas en el sistema de origen, acumuladas en un par de meses y repartidas de forma desigual entre las tres empresas: el proceso de ingesta las agregaba y actualizaba, pero nunca las cerraba.

Solución

Se construyó una aplicación en la nube con tres componentes: un extractor que trae los datos de cuentas por cobrar de las tres empresas desde el ERP, un notificador que arma los estados de cuenta semanales y diarios, y un tablero interno con vistas de clientes, facturas, antigüedad de deuda y conciliación.

• El ERP se mantiene como única fuente de verdad; la aplicación solo consolida y notifica, sin modificar datos de origen.
• Las reglas de negocio (cadencia de envío, umbrales, escalamiento) se documentaron como especificación revisable por el área de cobranzas antes de traducirse a código.
• Para las facturas que seguían abiertas sin corresponder ya a deuda real, se construyó un cierre automático, protegido por un interruptor que se activa con la validación del área de negocio.
• Se realizaron dos revisiones internas de seguridad, con corrección de los hallazgos identificados antes de continuar.

Resultados

• Aplicación desplegada en un ambiente único, con ingesta diaria automática de las tres empresas y envío programado semanal y diario ya construido.
• Para las ~374 facturas fantasma detectadas en la reconciliación se construyó un cierre automático, con activación sujeta a la validación del área de negocio.
• Suite de pruebas automatizada de unas 150 funciones de test.
• 69 cambios registrados en el repositorio de trabajo durante el desarrollo, 53 de ellos con coautoría explícita de un asistente de IA.

Arquitectura y decisiones

La arquitectura evolucionó de un esquema híbrido —descarga externa de datos, procesamiento en funciones independientes y una cola de eventos intermedia— hacia una aplicación única en la nube, con un extractor, un notificador y un tablero conectados directamente a la base de datos, al servicio de correo y al ERP. El esquema anterior se retiró una vez confirmado que el nuevo extractor operaba de forma estable durante más de dos semanas como única fuente activa.

Los ambientes de prueba y de producción se separaron por decisión de gobierno del programa, con la infraestructura descrita como código y la operación del ambiente productivo a cargo de un equipo de infraestructura dedicado del grupo.

Las reglas de negocio se organizaron como un conjunto de decisiones documentadas —cadencia de envío, umbrales mínimos, escalamiento y baja de notificaciones—, cada una revisable por el área de cobranzas antes de activarse en producción. El cierre automático de facturas que dejan de tener respaldo en el ERP quedó como una función más de esa misma lógica de control, con su propia llave de activación independiente del resto de las reglas.