Dibuja el recorrido del pedido
Conectar la tienda con el ERP implica acordar qué datos viajan, cuándo y quién puede cambiarlos. Antes de elegir un conector, sigue un pedido desde su creación hasta el envío, la cancelación y una posible devolución. Incluye los pasos manuales y los sistemas de pago o logística que intervienen.
Reúne las versiones de la tienda y del ERP, su documentación de integración y el contacto del proveedor. Comprueba qué lectura y escritura permiten, los permisos necesarios, los límites de uso y si hay un entorno de pruebas. La existencia de una API no garantiza que incluya todas las operaciones que necesitas.
Asigna una fuente de verdad a cada dato
| Dato | Pregunta que resolver | Regla que dejar escrita |
|---|---|---|
| Producto y variante | ¿Dónde se crean códigos, unidades y variantes? | Quién crea y quién solo recibe; cómo se retira un producto. |
| Contenido comercial | ¿Dónde se editan textos, imágenes y categorías? | Qué campos controla la tienda y cuáles el ERP. |
| Precio y tarifa | ¿Hay tarifas por cliente, descuentos o impuestos distintos? | Qué importe recibe la tienda y cuándo se recalcula. |
| Stock | ¿Se informa existencias físicas o disponibilidad descontando reservas? | Almacenes incluidos, reservas y momento de actualización. |
| Cliente | ¿Cómo se enlaza un cliente existente y quién modifica sus datos? | Identificador estable y política ante coincidencias dudosas. |
| Pedido | ¿Cuándo se registra y quién actualiza cada estado? | Condiciones de envío, confirmación y cancelación. |
Evita que ambos sistemas editen el mismo campo sin una regla de conflicto. Una sincronización en dos sentidos necesita definir cuál prevalece o quién revisa la discrepancia. Stock físico, reservado y disponible son conceptos que debes concretar con tu operativa; no los trates como una única cifra por defecto.
Acordad identificadores y estados
Un nombre de producto puede cambiar y no identifica de forma segura una variante. Define una correspondencia entre identificadores de ambos sistemas, y decide qué hacer cuando falta, se repite o se sustituye un código. Guarda también la relación entre el pedido de la tienda y el del ERP.
- Pedido recibido: ¿se transfiere al crearlo, al confirmar el pago o al aprobarlo comercialmente?
- Pedido en preparación: ¿quién reserva stock y qué ocurre si solo hay parte disponible?
- Enviado: ¿quién comunica transportista, seguimiento y envíos parciales?
- Cancelado: ¿hasta qué estado se admite y quién libera la reserva?
- Devuelto o reembolsado: ¿qué documento y qué ajuste de stock se necesitan?
Pago, preparación y facturación pueden avanzar por separado. Escribe las transiciones permitidas y qué ocurre si llega una actualización antigua después de una nueva. Confirma estas reglas con administración y operaciones antes de implementarlas.
Prepara la sincronización y la recuperación
Decide el retraso aceptable por dato: catálogo, stock y pedidos pueden necesitar frecuencias diferentes. Revisa si el proveedor permite avisos de cambios, consultas periódicas o ambas opciones. Incluye una comprobación que compare los datos de los dos sistemas y permita detectar desajustes.
Como ejemplo técnico concreto, Shopify documenta que un webhook puede entregarse más de una vez y recomienda operaciones idempotentes, que no duplican el resultado al repetir la entrada. Si usas otro proveedor, revisa sus garantías. En cualquier caso, prueba la recuperación de un pedido cuyo envío al ERP falló antes de volver a procesarlo.
Fuente oficial: verificación y duplicados en webhooks de Shopify
- Registrar referencia, estado y motivo del fallo, con acceso limitado y sin copiar datos personales innecesarios.
- Acordar quién recibe la alerta y cómo distingue una incidencia aislada de una parada completa.
- Definir cuándo reintentar y cuándo pedir revisión para evitar crear el mismo pedido dos veces.
- Probar desconexión, credenciales caducadas, código desconocido y actualizaciones simultáneas.
- Preparar una vuelta al proceso manual y una comprobación posterior de pedidos y stock.
Ejemplo ilustrativo: una variante sin correspondencia
Una tienda ficticia vende una variante que aún no tiene código vinculado en el ERP. Este ejemplo es ilustrativo, no un caso de cliente. La integración apartaría el pedido con una referencia y un motivo, en lugar de sustituir el producto por otro parecido. Operaciones corregiría la correspondencia antes de autorizar el reenvío.
La prueba debería confirmar que el pedido queda visible como pendiente, que la corrección permite recuperarlo y que repetir el envío no crea otro pedido. También debería mostrar qué se comunica al cliente durante la incidencia según la política de la tienda. Un pedido de prueba que llega al ERP no valida por sí solo todo el recorrido.
Delimita el alcance antes de pedir presupuesto
Prepara el mapa de datos, los estados, un pedido normal y uno con incidencia, todos anonimizados. Anota volumen habitual y picos, retraso aceptable, proveedores implicados y quién mantendrá la integración. Separa lo imprescindible para la primera entrega de devoluciones, tarifas o almacenes que puedan estudiarse en otra fase.