0A-001 · APLICACIÓN WEB · 2026
CTI ERP: Sistema a medida de inventario y gestión de pedidos para un distribuidor de telecomunicaciones
Reemplazo de una hoja de cálculo de 100,000 filas y tres herramientas desconectadas por un solo ERP: inventario de tarjetas SIM, pedidos multietapa, integración con FedEx, facturación y registros de auditoría en varias ubicaciones.
- cliente
- CTI
- industria
- Telecom
- entregado
- feb 2026
- estado
- Live

El problema
CTI mueve tarjetas SIM. Muchas. Un solo pedido a un revendedor regional puede incluir 10,000 tarjetas individuales, cada una con un ICCID único que tiene que rastrearse desde la entrada hasta el envío y la factura.
Cuando los conocimos, todo eso corría en una hoja de cálculo. Los pedidos vivían en hilos de correo. Los envíos se hacían a mano en FedEx Ship Manager. Las facturas se conciliaban a fin de mes con una calculadora y un montón de impresiones. Un solo ICCID duplicado podía mandar al equipo a una cacería de varias horas entre cuatro sistemas que no se hablaban entre sí.
Los ERPs estándar no encajaban. Salesforce y NetSuite asumen que tu negocio se parece a todos los demás. El de CTI es mover hardware de telecomunicaciones serializado a escala, y las herramientas que existen para eso son o de hace décadas o están hechas para carriers, no distribuidores.
Lo que construimos
Inventario que maneja diez mil SIMs a la vez. Importación masiva de ICCID, deduplicación automática y estado en vivo por tarjeta: en stock, reservada, asignada, enviada. La vista de detalle del pedido limita la visualización del inventario a 100 tarjetas por rendimiento; un endpoint de exportación aparte devuelve la lista completa cuando el equipo la necesita.
Pedidos con estado real. Cada pedido avanza por 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. Los números de pedido (SO-####) usan un patrón de secuencia máxima que sobrevive a las eliminaciones sin colisiones.
FedEx, nativo. Integración directa con la API para cotizaciones, generación de etiquetas y seguimiento. La validación de direcciones corre antes de comprar la etiqueta. Las tarifas se deduplican por tipo de servicio para que el equipo no vea cinco variantes del mismo FedEx 2Day.
Facturación que se vincula al trabajo. Números de factura autogenerados (mismo patrón de secuencia máxima que los pedidos, porque un COUNT() ingenuo se rompe en el momento en que se anula una factura). Generación de PDF, seguimiento de pagos y una línea limpia de regreso al pedido de origen. La conciliación de fin de mes que antes tomaba un día ahora toma minutos.
Permisos que de verdad significan algo. Permisos como MANAGE_SETTINGS, SHIP_ORDERS y DELETE_ORDERS se otorgan individualmente. Cada acción de crear, actualizar, eliminar y enviar cae en un registro de auditoría con el actor, la marca de tiempo y los valores que cambiaron.
Multiubicación. El inventario y los pedidos están segmentados por almacén. Los reportes se consolidan entre ubicaciones o filtran a una sola.
Cómo está construido
El backend es Node.js con Express, Prisma contra PostgreSQL. Las clases de servicio son singletons con límites explícitos: OrderService, InventoryService, ShippingService, cada una dueña de su porción de lógica de negocio. Cada mutación pasa por el registro de auditoría.
El frontend es React con Vite, hablando con un único cliente de API tipado. El estado de la interfaz se queda en el navegador; todo lo durable vive en PostgreSQL.
Corre en un contenedor Proxmox LXC dentro del entorno del cliente, con PM2 gestionando los procesos de Node. Las migraciones de esquema corren como dueño de la base de datos, no como el rol de la aplicación: una restricción aprendida a la mala después de que migraciones tempranas fallaron en silencio contra tablas bloqueadas por permisos.
Elegimos este stack por longevidad. El software interno tiene que seguir funcionando dentro de cinco años, después de que el framework de moda haya sido reemplazado dos veces. Postgres maneja consultas relacionales complejas (pedidos vinculados a SIMs vinculadas a facturas vinculadas a registros de envío) sin despeinarse. React y Node seguirán funcionando mientras existan los navegadores.
Lo que cambió para el equipo
La cacería se acabó. El estado del pedido, la asignación de SIMs, la etiqueta de envío y la factura ahora viven en un solo lugar, todos actualizados en tiempo real, todos con registro de auditoría.
La incorporación de personal nuevo pasó de semanas de acompañamiento a un solo día de capacitación, porque 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 nombre del actor y los valores originales ahí mismo.
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
- Frontend: React, Vite, sistema de diseño a medida
- Backend: Node.js, Express, Prisma
- 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, PM2, respaldos diarios de PostgreSQL
No encaja en Salesforce. No encaja en NetSuite. No encaja en ninguno de los ERPs genéricos. Construido alrededor del flujo de trabajo que de verdad existe, de propiedad total de CTI, sin tarifas por usuario y sin modelo de licencias.
fin del archivo · 0A-001
Iniciar un proyecto similar