Construir un ERP desde cero suena intimidante. La mayoría de las empresas asumen que necesitan un equipo de 20 desarrolladores, un presupuesto de seis cifras y 18 meses de desarrollo. La realidad es que con el stack tecnológico correcto, un ERP funcional para e-commerce se puede entregar en 8 semanas con un equipo de 2-3 personas.
En BucaInk hemos perfeccionado una arquitectura basada en Angular, Firebase Firestore y PrestaShop que nos permite construir ERPs custom rápidamente sin sacrificar calidad ni escalabilidad. En este artículo compartimos los detalles técnicos de cómo funciona esta arquitectura y por qué supera a soluciones como Odoo o SAP Business One para operaciones de e-commerce.
Arquitectura general del sistema
El ERP se compone de tres capas principales que se comunican a través de APIs REST y eventos en tiempo real:
Capa de presentación: Angular 17+
Elegimos Angular sobre React o Vue por tres razones específicas:
- Estructura opinada: Angular impone una arquitectura de módulos, servicios y componentes que facilita mantener un proyecto grande. En un ERP con 15+ módulos, la libertad de React se convierte en caos sin disciplina extrema.
- Angular Material: La biblioteca de componentes UI provee tablas con paginación, formularios con validación, diálogos y snackbars listos para producción. Esto reduce el tiempo de desarrollo de interfaces en un 60%.
- RxJS nativo: La programación reactiva es fundamental para un ERP que maneja datos en tiempo real. Los Observables de RxJS se integran perfectamente con los snapshots de Firestore.
- Standalone Components: Desde Angular 17, los componentes standalone eliminan la necesidad de NgModules, simplificando la arquitectura y mejorando el tree-shaking.
La estructura típica de nuestro ERP en Angular sigue este patrón:
src/
app/
core/ → Guards, interceptors, servicios globales
shared/ → Componentes reutilizables, pipes, directivas
features/
inventory/ → Módulo de inventario
orders/ → Módulo de pedidos
invoicing/ → Módulo de facturación
shipping/ → Módulo de envíos
dashboard/ → Panel principal
customers/ → Gestión de clientes
layouts/ → Sidebar, toolbar, layouts responsivos
Capa de datos: Firebase Firestore
Firebase Firestore es el corazón del sistema. A diferencia de una base de datos SQL tradicional, Firestore ofrece ventajas críticas para un ERP moderno:
- Tiempo real sin WebSockets manuales: Cuando un operador de almacén actualiza el stock, todos los usuarios ven el cambio instantáneamente sin necesidad de refrescar. Esto es imposible de lograr fácilmente con PostgreSQL o MySQL.
- Escalado automático: No hay servidores que administrar, no hay conexiones de base de datos que optimizar. Firestore escala de 10 a 10,000 usuarios sin cambiar una línea de código.
- Modelo de datos flexible: Las colecciones y documentos permiten evolucionar el esquema sin migraciones destructivas. Cuando agregas un nuevo campo a los productos, los documentos existentes simplemente no tienen ese campo — no se rompe nada.
- Reglas de seguridad granulares: Cada documento puede tener reglas de acceso basadas en el rol del usuario, sin necesidad de un backend separado para autorización.
La estructura de colecciones típica en nuestro ERP:
firestore/
products/ → Catálogo sincronizado con PrestaShop
orders/ → Pedidos de todas las fuentes
invoices/ → CFDIs generados
inventory_moves/ → Movimientos de inventario (trazabilidad)
warehouses/ → Configuración de almacenes
customers/ → Datos fiscales y de contacto
shipping_labels/ → Guías generadas
settings/ → Configuración global del sistema
Capa de integración: PrestaShop API REST
PrestaShop actúa como la fuente de verdad para el catálogo de productos y como el punto de entrada de pedidos del e-commerce. La integración funciona en ambas direcciones:
- PrestaShop → ERP: Cuando un cliente realiza un pedido en la tienda, un webhook de PrestaShop dispara un workflow en n8n que crea el pedido en Firestore con toda la información necesaria para procesamiento.
- ERP → PrestaShop: Cuando el operador actualiza stock en el ERP, un Cloud Function de Firebase actualiza las cantidades en PrestaShop via API REST automáticamente.
Sincronización de inventario en tiempo real
El módulo de inventario es donde el ERP custom demuestra su superioridad sobre Odoo de forma más evidente. Nuestro sistema maneja:
Multi-almacén con transferencias
Cada producto tiene un subdocumento de stock por almacén. Las transferencias entre almacenes generan dos movimientos atómicos (salida del origen, entrada al destino) usando transacciones de Firestore que garantizan consistencia incluso con múltiples usuarios operando simultáneamente.
Reglas de reorden inteligentes
Cada producto puede tener un punto de reorden y una cantidad sugerida de compra. Cuando el stock cae por debajo del punto de reorden, el sistema genera una orden de compra sugerida automáticamente. A diferencia de Odoo, donde configurar estas reglas requiere navegar por 5 pantallas diferentes, en nuestro ERP se configura directamente en la ficha del producto.
Trazabilidad completa
Cada movimiento de inventario queda registrado con timestamp, usuario, razón y referencia (pedido, transferencia, ajuste manual). La colección inventory_moves funciona como un ledger inmutable que permite auditar cualquier discrepancia de stock.
Flujo completo de un pedido
Para ilustrar cómo todas las piezas trabajan juntas, este es el flujo completo desde que un cliente compra hasta que recibe su paquete:
- Cliente compra en PrestaShop → Se genera un pedido con estado "Pago aceptado".
- Webhook dispara workflow n8n → n8n lee el pedido via API de PrestaShop y crea un documento en la colección
ordersde Firestore. - ERP notifica al equipo → El dashboard muestra el nuevo pedido en tiempo real. Si es urgente, se envía notificación por WhatsApp via Chatwoot.
- Operador procesa el pedido → Verifica stock, selecciona almacén de origen, confirma artículos.
- Generación automática de guía → El sistema calcula la mejor paquetería según peso, destino y costo via Envia.com API.
- Facturación CFDI automática → Si el cliente solicitó factura, se genera el CFDI 4.0 via Facturapi sin intervención manual.
- Actualización en PrestaShop → El estado del pedido se actualiza a "Enviado" con número de tracking.
- Stock se ajusta → El inventario se descuenta automáticamente del almacén de origen.
Todo este flujo ocurre en menos de 2 minutos, comparado con los 10-15 minutos que toma en Odoo con sus múltiples pantallas y confirmaciones manuales.
Rendimiento y costos de operación
Una de las mayores ventajas de esta arquitectura es su costo operativo. Firebase cobra por operaciones de lectura/escritura y almacenamiento, no por usuarios. Un e-commerce típico con 500-2,000 pedidos mensuales genera:
- Lecturas Firestore: ~500,000/mes → $0.30 USD
- Escrituras Firestore: ~100,000/mes → $0.18 USD
- Hosting Angular (Firebase Hosting): ~$5 USD/mes
- Cloud Functions: ~$3 USD/mes
- Total: menos de $10 USD/mes
Compáralo con Odoo Enterprise: $24-$44 USD por usuario por mes. Con 5 usuarios, estás pagando $120-$220 USD mensuales solo en licencias, sin contar hosting.
Seguridad y respaldos
La seguridad en Firebase es robusta por defecto:
- Autenticación: Firebase Auth con soporte para email/password, Google Sign-In y autenticación multifactor.
- Autorización: Security Rules de Firestore que validan cada operación a nivel de documento.
- Respaldos: Exportaciones automáticas diarias a Google Cloud Storage.
- Encriptación: Datos encriptados en tránsito (TLS) y en reposo por defecto.
- Auditoría: Cloud Audit Logs para cada operación administrativa.
Extensibilidad: Agregar módulos nuevos
La verdadera prueba de un ERP es qué tan fácil es agregar funcionalidad nueva. Con nuestra arquitectura Angular + Firebase, agregar un módulo nuevo (por ejemplo, gestión de devoluciones) implica:
- Crear una nueva colección en Firestore (0 minutos, no hay esquema que migrar).
- Crear un feature module en Angular con sus componentes, servicios y rutas (2-3 días).
- Agregar los workflows de automatización en n8n (1 día).
- Configurar Security Rules para la nueva colección (1 hora).
En Odoo, agregar un módulo custom requiere conocimiento de Python, el ORM propietario de Odoo, QWeb templates, y el sistema de herencia de vistas. Un desarrollador Angular junior puede extender nuestro ERP; un desarrollador Odoo necesita meses de especialización.
Lecciones aprendidas
Después de construir múltiples ERPs con esta arquitectura, estas son las lecciones más importantes:
- No intentes replicar Odoo: El error más común es querer recrear todas las funcionalidades de un ERP genérico. Construye solo lo que usas diariamente.
- Firestore tiene límites: Las queries complejas con múltiples filtros requieren índices compuestos. Planifica tus consultas desde el diseño del esquema.
- Invierte en el dashboard: El 80% del tiempo de tus usuarios estará en el dashboard. Hazlo rápido, limpio e informativo.
- Automatiza desde el día uno: Cada proceso manual que dejes "para después" se convertirá en deuda técnica. Integra n8n desde el inicio.
¿Quieres ver esta arquitectura en acción? En BucaInk te mostramos un demo funcional de nuestro ERP custom integrado con PrestaShop. Agenda una demo y descubre cómo transformar tu operación.