Cliente. Una empresa de gestión de deuda y cobranzas que gobernaba su operación financiera en planillas de Excel: el ciclo de vida de las facturas, los pagos parciales, la antigüedad de la deuda y los balances vivían en celdas, sin un sistema que los hiciera auditables ni una única fuente de verdad.
Enfoque
Este caso recorre dos eslabones del método —ingeniería de software e ingeniería de datos— sin handoff entre ellos: la misma cabeza que construyó la plataforma que reemplaza al Excel es la que después llevó los datos históricos a otro sistema sin degradar su significado en el camino. No hay un equipo que entrega el ERP y otro que migra los datos: hay un solo recorrido que entiende qué es una factura, un pago parcial y un comprobante en esta empresa, y lo conserva de punta a punta.
La tesis que ordena el trabajo es la del dato confiable como precondición, no como anexo. Un motor de balances solo es útil si es determinístico —si las mismas operaciones producen siempre el mismo saldo— y una migración solo sirve si es idempotente —si correrla dos veces no duplica ni corrompe—. En finanzas, esas dos propiedades no son detalles de implementación: son la diferencia entre una herramienta auditable y un Excel más rápido.
El problema detectado
La empresa operaba la gestión de deuda en Excel. Cada cobrador, cada lista de precios, cada pago parcial y cada cálculo de antigüedad de deuda dependía de planillas que nadie podía auditar y que se degradaban con cada copia. El problema declarado era “necesitamos un sistema”. El problema real era anterior: no existía un motor de balances confiable —el saldo de un cliente era el resultado de una cadena de celdas que ninguna persona podía reconstruir ni justificar ante una auditoría.
A ese problema se le sumaba un segundo, latente: una vez ordenada la operación, los datos históricos había que llevarlos a un software contable (vía su API) para cerrar el ciclo contable formal. Migrar desde el sistema legacy de gestión no era un volcado de tablas: era reconstruir el significado de cada comprobante en el modelo de datos de otro sistema, con sus propios campos obligatorios y sus propias reglas.
Relevamiento funcional
El relevamiento cubrió las dos patas del trabajo.
Del lado del ERP, se modeló el ciclo de vida de la factura —emisión, pagos parciales, saldo, antigüedad de deuda (debt-aging)— y se identificaron los workflows que el Excel resolvía de forma informal: la clasificación de antigüedad de la deuda, la validación de retención multi-etapa, los historiales completos de transacciones. Cada uno se relevó como proceso real, no como pantalla a dibujar.
Del lado de la migración, el relevamiento fue de datos. Se construyó un diccionario de datos y los mapeos origen→destino entre el sistema legacy de gestión y el software contable, con los requisitos de payload de la API de destino. El relevamiento incluyó documentar lo que no se podía obtener: los hallazgos sobre los límites de las fuentes —por ejemplo, campos obligatorios del software contable que las fuentes analíticas no exponían para reconstruir comprobantes completos—. Registrar la brecha es tan parte del relevamiento como registrar el dato disponible.
Construcción de la solución técnica
El trabajo tuvo dos patas técnicas que comparten una misma exigencia de auditabilidad.
La plataforma ERP full-stack. Una plataforma financiera construida con FastAPI, PostgreSQL y Next.js 14 / React / TypeScript, en reemplazo de la gestión en Excel. Su pieza central es un motor de balances determinístico: el saldo no es el residuo de una planilla, sino el resultado reproducible de un modelo del ciclo de vida de facturas y pagos parciales. Las APIs se aseguraron con RBAC, de modo que quién puede ver y operar qué quede gobernado por rol y no por convención. Los workflows del negocio —clasificación de antigüedad de deuda, validación de retención multi-etapa, historiales completos— se construyeron como flujos auditables, con dashboards de producción y reportería en PDF (ReportLab).
La migración de datos hacia el software contable. Un pipeline de migración que lleva los datos del sistema legacy de gestión a un software contable vía su API, con parseo y normalización de las fuentes, generación de los payloads que exige la API de destino y un push con checkpoint, progreso e idempotencia: el pipeline puede interrumpirse y retomarse sin duplicar ni corromper, y correrlo de nuevo converge al mismo estado en lugar de acumular errores. La ejecución se ordenó con trazabilidad por fases —maestros → comprobantes → validación → carga productiva controlada—, de modo que ninguna fase avance sobre datos que la anterior no validó. La carga masiva vía API cubrió la importación de clientes, la creación de listas de precio por región y la asignación masiva de códigos de cliente faltantes, cada operación con su reporte de ejecución.
Capa de información y datos
El gobierno del dato fue diseño, no anexo, en las dos patas.
- Determinismo y auditabilidad en el ERP. El motor de balances es determinístico por diseño: el saldo de un cliente es siempre reconstruible y justificable. Los historiales completos de transacciones y los flujos auditables hacen que cada estado del sistema tenga una traza, no una explicación verbal.
- Idempotencia y trazabilidad en la migración. El checkpoint y la idempotencia hacen que la migración sea repetible sin daño; la trazabilidad por fases hace que el estado de la carga sea siempre legible —qué maestros entraron, qué comprobantes se validaron, qué quedó pendiente—.
- Análisis funcional como fuente de verdad. El diccionario de datos, los mapeos origen→destino y los requisitos de payload se documentaron como artefactos versionados, de modo que las decisiones de migración queden auditables y no en la cabeza de una persona. Los hallazgos sobre los límites de las fuentes se registraron explícitamente, porque lo que el dato no dice también es información de gobierno.
Cómo se condujo el trabajo
El trabajo se ejecutó entre diciembre de 2025 y junio de 2026. Lo concreto y verificable fue ingeniería disciplinada, no un despliegue de herramientas de moda.
- El pipeline de migración se construyó con las propiedades que importan en finanzas: checkpoint, idempotencia, reporte de progreso y trazabilidad por fases. No es un script de un solo uso, sino un instrumento que se puede correr, interrumpir y volver a correr sin perder integridad.
- El análisis funcional se sostuvo con artefactos escritos —diccionario de datos, mapeos origen→destino, requisitos de payload, plan de migración y registro de fases de validación—, de modo que el trabajo de datos fuera reconstruible por alguien más.
- Las ejecuciones reales se registraron en una bitácora de estado operativo: qué se cargó, cuándo y con qué resultado. La bitácora es lo que distingue una migración ejecutada y verificada de un plan en el papel.
- Para los scripts repetitivos —generadores de payload por modelo de datos, normalizadores de fuentes— se usaron agentes de código como instrumento del ingeniero, para acelerar la parte mecánica. El criterio de diseño, las propiedades de integridad y la validación de cada fase fueron decisión y responsabilidad propias; la herramienta acelera, no decide.
Qué prueba este caso
- Desarrollo full-stack con disciplina financiera: un ERP con motor de balances determinístico, ciclo de vida de facturas, pagos parciales y APIs con RBAC, en reemplazo real de una gestión en Excel —no un prototipo.
- Migración de datos como ingeniería, no como volcado: un pipeline idempotente, con checkpoint y trazabilidad por fases, hacia un software contable vía su API, con análisis funcional documentado y bitácora de ejecuciones reales.
- Continuidad entre construir y migrar: la misma cabeza que ordenó la operación es la que llevó los datos a otro sistema sin degradar su significado en el empalme.