Qué datos conviene sincronizar entre un ecommerce y un ERP
Del ERP a la tienda: productos, stock, precios, tarifas, disponibilidad. De la tienda al ERP: pedidos, clientes y estados. Maestro, conflictos, frecuencia y errores.
Por Opium Software · Fecha editorial · Actualizado
Empieza por decidir qué sistema es responsable de cada dato. El ERP suele calcular el stock vendible y las tarifas, mientras que la tienda origina el pedido. Define cómo se confirma cada envío y cómo se recupera un error sin duplicar ventas.
Ideas clave
- Cada dato necesita un sistema de referencia y una regla de intercambio.
- Un pedido debe conservar la identidad del cliente, los artículos y la operación.
- La validación incluye cancelaciones, devoluciones y reintentos.
Conectar una tienda online con el ERP requiere definir qué información mantiene cada herramienta y cómo continúa una operación entre ambas. El recorrido relaciona catálogo, precios, existencias, clientes y pedidos. Su calidad se comprueba tanto en una venta habitual como en los cambios y las incidencias que pueden producirse después.
ERP → ecommerce: lo que la tienda debe leer
- Productos: código, nombre, variantes, activo/inactivo. El alta nueva suele nacer en gestión.
- Stock: unidades por almacén o el agregado que hayáis definido como vendible online.
- Precios: el precio de la tienda pública, con IVA y reglas de campaña.
- Tarifas: si hay B2B en la misma plataforma, la tarifa de cuenta; si no, el portal va aparte.
- Disponibilidad: no solo un número: si se puede vender, plazo, rotura.
Ecommerce → ERP: lo que la gestión debe recibir
- Pedidos: líneas, cliente, dirección, método de envío. Al pagar (o al confirmar), el documento debe existir en gestión.
- Clientes: alta o cruce con la ficha. Sin identificar, no hay tarifa ni histórico.
- Pagos y estados: pagado, enviado, cancelado, devuelto —cuando el proceso lo necesita para servir y facturar.
Sistema maestro, conflictos y frecuencia
El maestro de artículos y de stock de almacén suele ser el ERP. El maestro de la ficha “bonita” de la web (fotos, copy) puede ser la tienda. Si los dos editan el precio, hay conflicto: gana el último o gana nadie. Hay que escribir la regla. La frecuencia depende del riesgo: stock en tiempo casi real si vendéis en tienda y online a la vez; catálogo puede ir a lotes. Un CSV nocturno basta para un catálogo que casi no cambia y se queda corto cuando el mismo SKU se se vende en el punto de venta.
Validaciones y errores
| Qué falla | Síntoma | Qué validar |
|---|---|---|
| Dos códigos para el mismo artículo | Stock que no cuadra | Un SKU maestro |
| Pedido web que no nace en el ERP | Se sirve a ojo o se introduce manualmente | Alta al confirmar o al pagar |
| Precio distinto en web y gestión | Reclamaciones | Quién puede editar el precio |
| Cancelación en la tienda, no en el ERP | Se sirve lo cancelado | Estados en los dos sentidos |
| Stock negativo o retraso de horas | Over selling | Reserva al vender y frecuencia del push |
Ejemplo: se vende la última unidad desde dos canales
La tienda física y la web consultan disponibilidad y pueden generar operaciones en momentos próximos. El diseño debe precisar qué existencias se ofrecen online, cuándo se reserva una cantidad y qué respuesta recibe cada canal si ya no puede completarse la venta. Esa regla necesita contrastarse con el trabajo de almacén y con las condiciones comerciales de la empresa.
Una lista de pruebas para la puesta en marcha
- Alta o modificación de un artículo con sus variantes.
- Cambio de precio y actualización de disponibilidad.
- Pedido de un cliente existente y alta de uno nuevo.
- Cancelación o devolución después de registrar la venta.
- Reenvío de una operación ya tratada e interrupción de la conexión.
En cada prueba se comprueba el resultado de los dos sistemas y la referencia que permite relacionarlos. El equipo debe poder reconocer una operación completada, una pendiente y una rechazada, junto con la información necesaria para resolverla.
Quién manda sobre cada dato
En una tienda con almacén físico, parte del stock puede estar reservado, en tránsito o pendiente de recuento. Publica en la web la cantidad vendible que calcule el ERP. Si esa cantidad cae a cero mientras hay un pedido en curso, el pedido debe pasar a revisión con su número original. Durante una caída de conexión, conservar ese identificador permite reintentar el envío sin crear dos pedidos.
- Stock disponible. ERP → tienda. Enviar cambios de reserva y comparar saldos al cierre.
- Tarifas. ERP → tienda. Programar la fecha de entrada en vigor y comprobar moneda, impuestos y promociones.
- Pedidos. Tienda → ERP. Guardar el identificador de la venta y devolver la confirmación al canal.
Soluciones y guías para continuar
Artículos relacionados
Opium Software S.L. · NIF B67336016 · Avinguda Diagonal 449, 4ª, 08036 Barcelona, España · +34 930 42 27 96
Cuéntanos qué necesitas · Aplicaciones · Integraciones · Inteligencia artificial · Automatización · Desarrollo a medida · ERP · Odoo · Actualidad