Sistema de Facturación Electrónica White-Label con arquitectura de microservicios, integrado con el SRI de Ecuador — adaptable para cualquier empresa.
Plataforma white-label donde cada cliente empresarial tiene su propio panel de administración, sus certificados, sus series y su branding — sin interferir con los demás.
Cada cliente tiene su instancia configurada con RUC, certificado electrónico, logo, colores y datos fiscales propios. El SuperAdmin gestiona todas las instancias desde un panel central.
Facturas, notas de crédito y débito, retenciones, guías de remisión y liquidaciones de compra — todos con firma XAdES-BES y comunicación con los web services del SRI.
API REST pública por empresa para conectar ERPs e inventarios. Exportación en formatos compatibles con Conta, Mónica y otros sistemas contables del mercado ecuatoriano.
Sin dependencias innecesarias entre módulos. Cada servicio escala de forma independiente: el SRI Service puede tener más réplicas en picos de emisión sin afectar el resto.
Los certificados electrónicos de cada empresa se almacenan cifrados. Autenticación JWT con roles (SuperAdmin / AdminEmpresa / Operador / Solo lectura).
Generación automática del Anexo Transaccional Simplificado, reportes de IVA mensual, retenciones y cuadre de comprobantes para declaraciones al SRI.
Cada servicio es un proceso independiente, con su propia base de datos y responsabilidad única. Se comunican vía API REST interna y cola de mensajes para operaciones asíncronas.
Punto de entrada único. Routing, rate limiting, autenticación de tokens y documentación Swagger pública.
JWT, refresh tokens, roles, sesiones. Emite tokens que validan los demás servicios de forma independiente.
Configuración white-label por empresa: RUC, certificado cifrado, series, establecimientos, branding del RIDE.
Gestión de productos, servicios y directorio de clientes. Búsqueda y paginación optimizados.
CRUD de comprobantes, estados del ciclo de vida, historial de versiones y búsqueda avanzada.
Motor XML (XSD SRI), clave de acceso 49 dígitos, firma XAdES-BES, WS Recepción, polling Autorización y cola Redis con reintentos exponenciales.
Generación de RIDE en PDF, envío de email al cliente final, webhooks de estado para sistemas externos.
API pública por empresa, conectores ERP, exportación a Conta/Mónica, importación de pedidos y productos.
Roles amplios con conocimiento compartido. El Tech Lead es dueño del módulo más crítico (SRI) y centraliza las decisiones arquitectónicas. Los tres trabajan en paralelo desde la semana 1.
Con 3 devs el MVP se alcanza en 14 semanas. Menos paralelismo en ruta crítica, pero la arquitectura de microservicios mantiene el trabajo desacoplado entre los tres roles.
Desde el ingreso de datos hasta la autorización del SRI y entrega al cliente. Cada etapa está encapsulada en el microservicio responsable.
Visión completa del sistema: fuentes externas, API Gateway, microservicios core y salidas hacia el SRI y sistemas contables.
El MVP emite facturas válidas en el SRI. Las iteraciones agregan funcionalidades que mejoran la operación pero no bloquean la emisión.
Identificados desde el inicio para no encontrarlos en producción con el primer cliente real.
Lo que hay que hacer en los próximos 15 días para que el equipo pueda arrancar la semana 1 sin fricciones.
Son los dos roles más críticos. El Tech Lead define la estructura del monorepo y el Backend SRI conoce los web services del SRI. Sin ellos no arranca nada.
Necesario para testear la firma XAdES-BES desde el primer día. El SRI Ecuador tiene ambiente de pruebas (celcer.sri.gob.ec) que requiere certificado real o de prueba.
Desde el portal del SRI Ecuador → sección Facturación Electrónica. Son los esquemas que rigen el formato de todos los comprobantes. Versionar en el repo desde el inicio.
NestJS monorepo con Nx o Turborepo. Un paquete por servicio. Docker Compose para desarrollo local con PostgreSQL y Redis. CI/CD con GitHub Actions desde el primer commit.
Antes de implementar, acordar los endpoints internos entre servicios con DTOs TypeScript compartidos. Esto evita re-trabajo al integrar servicios más tarde.
El MVP necesita ser probado con facturas reales en ambiente de pruebas. Empresas conocidas que puedan dar feedback concreto antes de abrir el sistema a otros clientes.