Devoluciones y RMA en PrestaShop: qué trae de serie y qué se monta
PrestaShop incluye un sistema de devoluciones que casi nadie enciende. Qué cubre, dónde se queda corto y qué acaban…
Once de la noche. Un instalador entra en la tienda desde el móvil, mete tres metros de canal, una caja de mecanismos y un diferencial, y paga. A la mañana siguiente, en el almacén, resulta que de esa caja quedaba una: las otras dos salieron por mostrador el viernes a las seis y media.
El cliente no ha hecho nada mal y la tienda tampoco. Lo que pasa es que la tienda y el almacén viven en dos sitios distintos —la web por un lado, el ERP por otro— y entre ellos hay una persona copiando precios y existencias cuando le queda un rato.
Esto es lo que montamos para un distribuidor de material eléctrico y fontanería que trabaja con dos herramientas muy conocidas en el sector: Go!Manage, el ERP de Telematel, y Aunabase, la base de datos de producto del grupo Aúna Distribución.
La empresa no tenía un problema de software. Tenía el ERP al día, con casi treinta mil artículos dados de alta, sus tarifas y su stock por almacén. Y tenía acceso a Aunabase, que es donde los fabricantes del grupo dejan las fichas buenas: el nombre comercial de verdad, la descripción técnica, las fotos, el código de barras, la marca, en qué unidades se vende cada cosa.
Lo que no tenía era tienda. Y la tentación, cuando montas una, es rellenarla a mano: exportar un Excel, subirlo, retocar, y a los tres meses tener un tercer catálogo que no se parece a ninguno de los otros dos.
La tienda no es otro sitio donde guardar el catálogo. Es el escaparate de lo que ya está en el ERP.
Con esa idea, el trabajo dejó de ser «meter productos en PrestaShop» y pasó a ser otra cosa mucho más sencilla de explicar: repartir quién manda sobre qué.
Todo el proyecto se sostiene en este reparto, y es la parte que conviene tener clara antes de tocar nada:
De los casi treinta mil artículos del ERP, la tienda enseña una selección de 16.700 referencias: las que el distribuidor quiere vender online. El resto siguen en el ERP y no aparecen. Ampliar o recortar esa lista es una decisión comercial que se toma en el ERP, no una tarea de mantenimiento de la web.
El día a día de la tienda, ya montada, se parece bastante a esto:
Nada de esto lo mantiene una persona. Es lo mismo que ya se mantiene en el ERP y en Aunabase, visto desde la web.
La mitad interesante de una integración es la que va en sentido contrario. Cuando el cliente paga, el pedido entra en Go!Manage con sus líneas, sus cantidades, la dirección de entrega, la de facturación y la forma de pago traducida a la que el ERP entiende. Nadie lo teclea otra vez.
Y como esto tiene que ser comprobable, en la ficha del pedido del panel se ve si entró en el ERP o no, y hay un botón para volver a enviarlo. Ese es el cambio real para la empresa: se acabó el «cuando pueda lo paso al ERP». El almacén ve el pedido donde ve todos los demás.
Una integración se juzga a los seis meses, no el día que se enciende. Estas son las tres que evitan los problemas clásicos:
Cuando alguien nos pregunta por esto, lo que necesitamos saber es poco:
Con eso ya se puede montar una primera pasada de prueba y ver el catálogo real dentro de la tienda antes de decidir nada más.
Conocemos las dos por dentro y sabemos dónde suelen doler: las referencias que el ERP tiene duplicadas, las familias que no encajan con cómo compra el cliente, los productos sin foto, las tarifas especiales. Nada de eso es raro y nada de eso impide salir.
Y si tu ERP es otro, el planteamiento es el mismo: el ERP manda en precio y stock, el catálogo bueno manda en las fichas, y los pedidos vuelven solos.
¿Tienes el ERP al día y la tienda a mano? Cuéntanos qué usas y te decimos qué se puede conectar y en qué orden.
PrestaShop incluye un sistema de devoluciones que casi nadie enciende. Qué cubre, dónde se queda corto y qué acaban…
Un módulo, un desarrollo o solo una opinión. La primera consulta no cuesta nada, y de ahí sale un presupuesto cerrado con precio y fecha.