ERP de gestión comercial conectado con PrestaShop

1 Contexto

Varios de nuestros clientes tenían tienda física y una tienda PrestaShop que nosotros mismos habíamos implantado y manteníamos. Todos compartían el mismo problema: el catálogo, el stock y la venta en mostrador se gestionaban por un lado y la tienda online por otro. Cada producto nuevo, cada cambio de precio y cada venta había que repetirlo a mano en los dos sistemas, con errores de stock, pedidos online de artículos agotados y muchas horas de trabajo administrativo.

En lugar de resolverlo cliente a cliente, ideamos una solución común para todos ellos: una herramienta propia que fuera la fuente única de verdad del negocio y que mantuviera la tienda online sincronizada sin intervención manual.

2 Desafíos

• Un mismo producto para negocios distintos. Cada comercio tenía su catálogo, sus impuestos y su forma de trabajar, y la solución debía adaptarse a todos sin desarrollos a medida para cada uno.
• Sincronización fiable en ambos sentidos. El catálogo, los precios y el stock debían subir del ERP a la tienda, y los pedidos y clientes online debían bajar al ERP, sin duplicados ni pérdidas.
• Productos con combinaciones. Tallas, colores y otros atributos en PrestaShop se gestionan como combinaciones, con su propio stock, precio e imagen y una combinación por defecto. Había que modelarlas en el ERP y mantenerlas coherentes en la tienda.
• Stock real y valorado. El stock debía calcularse a partir de entradas de mercancía con su precio de compra, ventas, devoluciones y productos compuestos (packs), para conocer el coste medio, el último coste y el margen.
• Carga inicial del catálogo. Miles de referencias venían de hojas de cálculo de proveedores, cada una con un formato distinto.
• Escalabilidad y solidez. Algunas tiendas trabajaban con miles de referencias de productos, y el sistema debía mantenerse estable y operativo con ese volumen, día tras día y durante años.
• Puesto de venta. El sistema debía funcionar también en el mostrador: tickets, cobros, devoluciones, vales y arqueos de caja.
• Actualizaciones sin riesgo. Cada nueva versión podía cambiar la estructura de la base de datos instalada en cada cliente.

3 Solución

Desarrollamos NovaERP, una aplicación de escritorio en C# sobre SQL Server, organizada en módulos:

• Catálogo: productos, categorías jerárquicas, fabricantes, proveedores, atributos, características, imágenes y descripciones con editor HTML. Un asistente genera de forma automática todas las combinaciones de un producto a partir de sus atributos.
• Precios e impuestos: precio de compra, mayorista y venta al público, márgenes, precios específicos y ofertas, y configuración de los tipos de IVA enlazados con las reglas de impuestos de PrestaShop.
• Entradas y stock: recepción de mercancía con su coste, stock por entrada, cálculo de coste medio y último coste, productos compuestos y alertas de stock mínimo.
• Importación masiva: carga de catálogos desde Excel y CSV con perfiles de importación reutilizables, emparejamiento de campos e importación de imágenes.
• Ventas: pedidos con estados e historial, tickets de mostrador con código de barras, devoluciones, vales, cobros múltiples y facturas.
• Caja: apertura y cierre, movimientos, arqueos y control de gastos e ingresos.
• Informes: un generador de informes configurable por campos y una librería propia de impresión de documentos.
• Motor de sincronización con PrestaShop: a través de su API (Webservice), con tablas de control propias. Cada cambio en el ERP queda marcado para sincronizar. Un proceso automático en segundo plano, con periodicidad configurable, descarga los pedidos y clientes nuevos y sube el stock. La sincronización completa cubre catálogo, combinaciones, imágenes, precios, destacados y bajas, y registra cada operación.
• Soporte remoto: asistencia a los usuarios y resolución de incidencias a distancia.
• Instalador con migración automática: la base de datos se versiona como proyecto de SQL Server. Al iniciar sesión, la aplicación compara versiones y aplica los cambios de esquema y de datos (DACPAC) sin intervención del usuario.

4 Tecnologías

5 Seguridad y buenas prácticas

• Control de acceso por usuario y perfil, con permisos por módulo y por tipo de acción.
• Credenciales y claves de conexión cifradas (AES con derivación de clave PBKDF2).
• Registro de transacciones y log detallado de cada sincronización.
• Esquema de base de datos versionado y migraciones automáticas al actualizar.
• Activación de licencia por instalación.
• Ayuda contextual integrada en cada pantalla.

6 Resultados

• El catálogo, el stock y los pedidos se gestionan en un único sistema y la tienda online se actualiza sola.
• Desaparecen la doble entrada de datos y los desajustes de stock entre la tienda física y la online.
• Los pedidos online llegan al ERP con su cliente y su dirección de envío, listos para preparar y facturar.
• Las altas de catálogo pasan de hacerse a mano a cargarse desde la hoja del proveedor.
• El sistema evolucionó durante más de tres años, con nuevas versiones instaladas sin perder datos.
• Sigue funcionando más de diez años después. Aunque el producto está descontinuado y ya no recibe nuevas funciones, algunos clientes lo siguen usando a diario para gestionar su negocio. Lo atribuimos a una arquitectura sólida, a un modelo de datos bien diseñado y a un sistema de actualización que nunca obligó a empezar de cero.

7 Conclusión

Integrar un sistema de gestión con una plataforma de e-commerce no consiste en copiar datos: hay que decidir qué sistema manda en cada dato, controlar qué ha cambiado y resolver bien los casos difíciles, como las combinaciones o los packs.

Que siga en uso tantos años después demuestra que el software bien construido aguanta mucho más que el ciclo de vida de una tecnología. Este proyecto muestra también nuestra experiencia en el ecosistema Microsoft (.NET, C#, SQL Server) y en integraciones con plataformas de terceros.