Automatizar los pedidos del eCommerce en el ERP significa que cada pedido confirmado en la tienda online se crea automáticamente como documento de venta en el ERP, sin que nadie tenga que abrir dos pantallas, copiar datos ni teclear referencias. El pedido llega al ERP en segundos, con todos los datos mapeados: cliente, productos, cantidades, precios, dirección de envío, método de pago y referencia de la tienda.
El proceso manual —abrir el pedido en la tienda, buscar el cliente en el ERP, crear el pedido línea a línea, verificar precios, asignar almacén— consume entre 5 y 15 minutos por pedido. Con 100 pedidos diarios, son 8-25 horas de trabajo al día dedicadas solo a traspasar datos. La automatización reduce ese tiempo a cero y elimina los errores de transcripción que generan devoluciones y reclamaciones.
Flujo manual vs. flujo automatizado
Proceso manual típico
- El operador revisa los nuevos pedidos en el panel del eCommerce
- Abre el ERP y busca al cliente por nombre o NIF
- Si el cliente no existe, lo crea manualmente con todos sus datos
- Crea un nuevo pedido de venta en el ERP
- Busca cada producto por referencia y lo añade al pedido
- Verifica que los precios coinciden con los de la tienda
- Asigna el almacén y las condiciones de envío
- Guarda el pedido y anota la referencia en la tienda online
- Repite para cada pedido
Errores comunes en el proceso manual: referencia de producto mal tecleada, cantidad incorrecta, cliente asignado al partner equivocado, precio sin descuento aplicado, dirección de envío antigua del cliente en vez de la nueva.
Proceso automatizado con middleware
- El cliente completa la compra en la tienda online
- La tienda envía un webhook o el middleware consulta nuevos pedidos
- El middleware verifica si el cliente existe en el ERP (busca por email, NIF o código)
- Si no existe, lo crea automáticamente con los datos del pedido
- El middleware transforma el pedido al formato del ERP
- Crea el documento de venta en el ERP con todas las líneas
- El ERP confirma la creación y devuelve el número de pedido
- El middleware actualiza la tienda con la referencia del ERP
- Todo queda registrado en el log de sincronización
Tiempo total: 2-10 segundos por pedido. Sin intervención humana.
Paso 1: Definir el trigger del pedido
El primer paso es decidir cuándo se envía el pedido al ERP. Las opciones habituales:
- Al confirmar el pago: el pedido se envía cuando el pago está confirmado. Es la opción más segura para B2C —evita crear pedidos en el ERP que luego se cancelan por falta de pago.
- Al crear el pedido: el pedido se envía inmediatamente, aunque el pago esté pendiente. Habitual en B2B donde el pago es a 30/60 días y no hay pasarela.
- Al cambiar a un estado específico: el operador revisa el pedido en la tienda y lo marca como «Validado». Solo entonces se envía al ERP. Útil cuando hay pedidos que requieren revisión humana.
En un middleware como Integrafy, el trigger se configura como una regla: «cuando el pedido pase a estado X, ejecutar el flujo de creación en ERP».
Paso 2: Mapeo de datos del pedido
El mapeo de datos es el núcleo de la automatización. Cada campo del pedido de la tienda debe tener un destino en el ERP. Los campos críticos:
Cabecera del pedido
- Referencia del pedido: número de pedido de la tienda → campo de referencia externa en el ERP (NumAtCard en SAP, client_order_ref en Odoo)
- Fecha del pedido: fecha de la tienda → fecha del documento en el ERP
- Cliente: customer_id de la tienda → código de cliente en el ERP. Requiere un mapeo previo o búsqueda por campo común (email, NIF)
- Dirección de envío: puede ser diferente a la dirección fiscal. El ERP debe recibirla como dirección de entrega del documento
- Método de pago: transferencia, tarjeta, contrareembolso → código de forma de pago en el ERP
Líneas del pedido
- Referencia de producto: referencia de la tienda → código de artículo en el ERP. Deben coincidir o tener un mapeo de equivalencias
- Cantidad: directa, sin transformación
- Precio unitario: atención al IVA. La tienda puede enviar precio con IVA, el ERP trabaja sin IVA. El middleware debe calcular la conversión
- Descuentos: si la tienda aplica descuentos por línea, deben reflejarse en el ERP como descuento o como precio neto
Gastos de envío
Los gastos de envío son una línea especial. En la tienda son un concepto aparte. En el ERP suelen ser una línea más del pedido con un artículo de tipo servicio (por ejemplo, «PORTES»). El middleware crea esta línea adicional con el importe de envío.
Paso 3: Validaciones antes de crear en el ERP
Antes de crear el pedido en el ERP, el middleware debe validar:
- Cliente existe: si el cliente no existe en el ERP, crearlo primero. Si falla la creación del cliente (datos fiscales incompletos, NIF duplicado), el pedido queda en cola con el error.
- Productos existen: cada referencia del pedido debe existir como artículo en el ERP. Si un producto no existe (fue eliminado del ERP pero sigue activo en la tienda), el pedido no se puede crear.
- Stock disponible: opcionalmente, verificar que hay stock antes de crear el pedido. Si no hay stock, el pedido se puede crear igualmente (el ERP gestionará el backorder) o se puede retener.
- Precios coherentes: comparar el precio del pedido con el precio del ERP. Si hay diferencia superior a un umbral (por ejemplo, 5%), alertar. Puede indicar que los precios de la tienda no están actualizados.
- Pedido duplicado: verificar que el pedido no se ha creado ya (por referencia de la tienda). Evita duplicados si un webhook se recibe dos veces.
Paso 4: Gestión de errores
Los errores van a ocurrir. La pregunta no es si ocurren, sino cómo se gestionan. Un middleware robusto implementa:
Reintentos automáticos
Si el ERP devuelve un error temporal (timeout, servidor ocupado), el middleware reintenta automáticamente con backoff exponencial: 30 segundos, 1 minuto, 5 minutos, 15 minutos. Si tras N reintentos sigue fallando, el pedido pasa a estado «error» y se genera una alerta.
Cola de errores
Los pedidos que no se pueden crear quedan en una cola de errores con el detalle del fallo. Un operador puede revisar la cola, corregir el problema (crear el cliente que faltaba, activar el producto) y relanzar el pedido con un clic.
Alertas configurables
Email o notificación en Slack cuando un pedido falla. Alerta diferenciada por tipo de error: error de datos (requiere acción humana) vs. error técnico (se resuelve con reintento). Alerta cuando la cola de errores supera un umbral.
Log de auditoría
Cada pedido procesado queda registrado: fecha/hora de recepción, datos originales, transformaciones aplicadas, resultado (éxito/error), referencia del ERP, tiempo de procesamiento. Este log es esencial para resolver incidencias y para auditoría.
Paso 5: Flujo de retorno (ERP → tienda)
La automatización no termina con la creación del pedido en el ERP. El flujo de retorno es igual de importante:
- Confirmación de pedido: el middleware actualiza la tienda con el número de pedido del ERP para trazabilidad
- Estado de preparación: cuando el almacén confirma la preparación en el ERP, se actualiza el estado en la tienda
- Número de seguimiento: cuando se genera la expedición con tracking, se envía a la tienda y al cliente
- Factura: cuando el ERP genera la factura, el PDF puede adjuntarse al pedido en la tienda para descarga del cliente
Con estos cinco pasos —trigger, mapeo, validación, errores y retorno— tienes un flujo completo de automatización de pedidos que funciona 24/7, procesa cientos de pedidos sin intervención y te libera para dedicarte a lo que importa: vender más.