CTI ERP: Un sistema a medida de inventario y gestión de pedidos para un distribuidor de telecomunicaciones

El problema

CTI es un distribuidor de telecomunicaciones que mueve tarjetas SIM, planes prepago y hardware de telecomunicaciones a minoristas y revendedores. Su operación había superado las herramientas con las que funcionaba: inventario de SIMs en hojas de cálculo, pedidos rastreados en hilos de correo, envíos manejados manualmente en FedEx Ship Manager y facturación conciliada a mano al final de cada mes.

El punto de quiebre fue la escala. Un solo pedido puede incluir más de 10,000 SIMs individuales. Un solo error (un ICCID duplicado, una dirección de envío equivocada, una actualización de estado que se pasó por alto) le cuesta al equipo horas de investigación entre sistemas que no se hablan entre sí. La solución no era una suscripción SaaS. Era un sistema moldeado en torno a cómo funciona de verdad la distribución de telecomunicaciones.

Lo que construimos

CTI ERP es un sistema de planificación de recursos empresariales (ERP) full-stack que cubre todo el ciclo de vida de un pedido de SIMs, desde la entrada al inventario hasta el envío y la factura. Cada componente está construido a medida en torno al flujo de trabajo de CTI, no adaptado de una plantilla de ERP genérica.

Gestión de inventario de tarjetas SIM

Flujos de importación masiva para listas de ICCID, de-duplicación automática, seguimiento de estado por SIM (en stock, reservada, asignada a un pedido, enviada). El sistema maneja pedidos de más de 10,000 SIMs sin perder velocidad, incluyendo un endpoint de exportación dedicado para listas completas de SIMs, ya que la vista estándar de pedidos limita el detalle de las respuestas por rendimiento.

Flujo de pedidos multietapa

Los pedidos avanzan por una secuencia estricta de estados: Pendiente → Listo para enviar → Enviado → Completado, con Cancelado disponible en cualquier etapa. Cada transición está restringida por permisos y registrada en la auditoría. Existen flujos de venta rápida para transacciones de mostrador; existen flujos de importación masiva para pedidos por lotes. Los números de pedido autogenerados (SO-####) usan un patrón de secuencia máxima que sobrevive a las eliminaciones sin colisiones.

Integración de envíos con FedEx

La integración directa con la API de FedEx maneja cotizaciones de tarifas, generación de etiquetas y seguimiento. La validación de direcciones se ejecuta antes de comprar la etiqueta para detectar correcciones a tiempo. Las tarifas se de-duplican por tipo de servicio para que el equipo no vea cinco variantes de la misma opción FedEx 2Day.

Facturación y conciliación

Los números de factura se generan con el mismo patrón de secuencia máxima que los pedidos (el enfoque ingenuo basado en COUNT se rompe en el momento en que se anula una factura). Generación de PDF, seguimiento de pagos y vínculo de regreso a los pedidos de origen. La conciliación de fin de mes que antes tomaba un día ahora toma minutos.

Acceso por roles y registros de auditoría

Permisos como MANAGE_SETTINGS, SHIP_ORDERS y DELETE_ORDERS se otorgan individualmente. Cada acción de crear, actualizar, eliminar y enviar se escribe en un registro de auditoría con el actor, la marca de tiempo y los valores modificados. La configuración misma vive como filas clave-valor en la base de datos en lugar de variables de entorno, para que el equipo pueda ajustar el comportamiento del sistema en tiempo de ejecución sin volver a desplegar.

Soporte multiubicación

El inventario y los pedidos están segmentados por ubicación. Los reportes se consolidan entre ubicaciones o se filtran a un solo almacén.

Cómo está construido

El backend es Node.js con Express, usando Prisma ORM contra una base de datos PostgreSQL. Las clases de servicio siguen un patrón singleton con límites explícitos (OrderService, InventoryService, ShippingService), cada una dueña de su porción de lógica de negocio y con sus mutaciones pasando por el registro de auditoría.

El frontend es React con Vite, comunicándose a través de un único cliente de API tipado. El estado de la interfaz se queda en el navegador; el estado durable vive en PostgreSQL, donde corresponde.

El despliegue corre en un contenedor Proxmox LXC en el entorno del cliente, con PM2 gestionando los procesos de Node. Las migraciones de esquema están restringidas para ejecutarse como el dueño de la base de datos, no como el rol de la aplicación, una restricción de seguridad aprendida a la mala después de que migraciones tempranas fallaran en silencio contra tablas bloqueadas por permisos.

El stack se eligió por longevidad. El software interno tiene que seguir funcionando dentro de cinco años, mucho después de que el framework de moda haya sido reemplazado. Postgres maneja consultas relacionales complejas (pedidos vinculados a SIMs vinculadas a facturas vinculadas a registros de envío) sin despeinarse. React con un backend de verdad seguirá funcionando mientras existan los navegadores web.

Lo que cambió para el equipo

El equipo dejó de perseguir datos entre hojas de cálculo, hilos de correo y FedEx Ship Manager. El estado del pedido, la asignación de SIMs, la etiqueta de envío y la factura viven todos en un solo lugar, todos actualizados en tiempo real, todos con registro de auditoría.

La incorporación de personal nuevo pasó de un periodo de acompañamiento de varias semanas a un solo día de capacitación: el sistema refleja cómo ya trabajaba el equipo, solo que sin el impuesto de la conciliación manual. Los errores que antes costaban horas de investigación ahora aparecen de inmediato en el registro de auditoría con el actor y los valores originales.

Lo más importante: el sistema creció con el negocio. Nuevos tipos de producto, nuevas etapas del flujo, nuevas integraciones; cada una se entrega como una actualización de funciones, no como un ticket de soporte a un proveedor de SaaS.

El stack de un vistazo

• Frontend: React, Vite, sistema de diseño a medida
• Backend: Node.js, Express, Prisma ORM
• Base de datos: PostgreSQL
• Integraciones: API de envíos de FedEx, generación de facturas en PDF
• Autenticación: basada en sesión con sistema de roles y permisos
• Infraestructura: Proxmox LXC, gestor de procesos PM2, respaldos diarios de PostgreSQL

Este es el tipo de proyecto que no encaja en Salesforce, no encaja en NetSuite y no encaja en ninguno de los ERPs genéricos. Construido a medida en torno al flujo de trabajo real, y de propiedad total del cliente, sin tarifas por usuario y sin modelo de licencias.