Una integración ERP-Shopify es un sistema, no un conector
Una integración ERP-Shopify conecta catálogo, stock, precios, clientes, pedidos, facturación y logística entre dos sistemas que modelan el negocio de forma distinta.
El error más común es empezar por la API sin decidir qué sistema manda sobre cada dato. Si Shopify y el ERP pueden modificar el mismo stock, precio o dirección al mismo tiempo, la sincronización puede funcionar técnicamente y aun así producir información incorrecta.
Antes de elegir app, middleware o desarrollo propio, define:
- objetos que se sincronizan;
- sistema fuente de cada campo;
- dirección y frecuencia;
- transformación de datos;
- tratamiento de errores;
- proceso manual de recuperación;
- responsable de negocio y responsable técnico.
PIXELWOLF aborda esta capa dentro de integraciones Shopify, conectando arquitectura con operación y QA.
Mapa de responsabilidad de datos
| Objeto | Fuente habitual | Destino | Decisión crítica |
|---|---|---|---|
| Producto base | ERP o PIM | Shopify | SKU, estado y campos obligatorios. |
| Contenido comercial | Shopify o PIM | Shopify | Título, descripción, SEO e imágenes. |
| Precio | ERP, Shopify o motor de pricing | Shopify | Mercados, listas B2B y promociones. |
| Stock | ERP/WMS | Shopify | Ubicaciones, stock de seguridad y reservas. |
| Pedido | Shopify | ERP/OMS | Momento de exportación y estados. |
| Fulfillment | ERP/WMS/3PL | Shopify | Tracking, parciales y cancelaciones. |
| Cliente | CRM/ERP/Shopify | Bidireccional controlado | Identidad, consentimiento y duplicados. |
| Factura | ERP | Portal o cliente | Fiscalidad, abonos y numeración. |
No existe un reparto universal. Una marca DTC puede gobernar catálogo en Shopify; una industria B2B puede hacerlo en ERP o PIM.
Productos, variantes y metafields
El ERP suele pensar en artículos; Shopify trabaja con productos, opciones y variantes. El mapping debe resolver:
- SKU único por variante;
- EAN/GTIN;
- producto padre y variantes;
- opciones como talla o color;
- estado activo, borrador o archivado;
- colecciones;
- imágenes y orden;
- metafields y metaobjects;
- traducciones y mercados;
- bundles o kits.
Crear productos automáticamente sin reglas editoriales puede publicar títulos internos, descripciones vacías o categorías incoherentes. La integración debe separar datos operativos de contenido comercial.
Stock y ubicaciones
El inventario es una de las capas más sensibles. Define:
- ubicación Shopify equivalente a cada almacén;
- stock disponible frente a stock físico;
- pedidos pendientes y reservas;
- stock de seguridad;
- frecuencia de actualización;
- prioridad de almacenes;
- venta sin stock;
- devoluciones y ajustes;
- comportamiento en picos.
Para muchas tiendas, el ERP o WMS debe ser la fuente de stock y Shopify el canal de venta. Si Shopify también modifica cantidades manualmente, hay que decidir si ese cambio vuelve al ERP o será sobrescrito.
Precios, impuestos y B2B
El precio puede depender de:
- mercado y moneda;
- tarifa o cliente B2B;
- cantidad;
- impuestos incluidos o excluidos;
- promoción;
- contrato comercial;
- coste o margen;
- canal.
No conviene sincronizar un único campo de precio si el negocio usa varias lógicas. En Shopify B2B, catálogos y empresas pueden necesitar un modelo distinto del DTC.
Ciclo de vida del pedido
La integración debe especificar cuándo un pedido entra en ERP:
- al crearse;
- al autorizarse el pago;
- al marcarse como pagado;
- después de una revisión antifraude;
- al cumplir una condición de negocio.
También debe cubrir:
- descuentos por línea y pedido;
- gastos de envío;
- impuestos;
- gift cards;
- pedidos con varias monedas;
- pagos parciales;
- devoluciones;
- cancelaciones;
- pedidos editados;
- fulfillment parcial;
- pedidos B2B o draft orders.
Si solo se prueba un pedido simple pagado con tarjeta, la integración no está validada.
Patrones de integración
App o conector estándar
Encaja cuando el flujo y modelo de datos son comunes. Reduce tiempo de implementación, pero hay que verificar límites, roadmap, soporte y tratamiento de errores.
Middleware o iPaaS
Útil para orquestar varios sistemas, transformar datos y monitorizar flujos. Añade una capa que también necesita gobierno y coste recurrente.
Desarrollo propio
Adecuado cuando la lógica es diferencial o los conectores existentes no cubren el caso. Requiere responsabilidad técnica, observabilidad, mantenimiento y adaptación a cambios de API.
Integración por lotes
Puede ser suficiente para catálogos o precios que no necesitan tiempo real. Es más simple y recuperable, pero introduce latencia.
Eventos y webhooks
Los webhooks permiten reaccionar a cambios, pero deben tratarse como señales que pueden repetirse. La implementación necesita idempotencia, reintentos y reconciliación.
Idempotencia, reintentos y reconciliación
Una integración seria asume que habrá caídas.
- Idempotencia: procesar dos veces el mismo evento no crea dos pedidos.
- Reintentos: un fallo temporal vuelve a intentarse con límites.
- Dead-letter queue: los errores persistentes quedan visibles para revisión.
- Reconciliación: un proceso periódico compara sistemas y corrige desviaciones.
- Trazabilidad: cada objeto conserva IDs de ambos sistemas.
Sin estas capas, el equipo descubre errores cuando un cliente reclama.
Observabilidad mínima
El panel o registro debe mostrar:
- fecha y duración;
- objeto e identificadores;
- origen y destino;
- resultado;
- error legible;
- número de reintentos;
- payload seguro o referencia;
- acción manual disponible;
- backlog pendiente.
No guardes datos personales completos en logs si no son necesarios.
Plan de QA
Prueba al menos:
- producto simple y producto con variantes;
- SKU inexistente o duplicado;
- actualización de precio y stock;
- pedido con descuento y envío;
- pedido internacional;
- pedido B2B si aplica;
- cancelación y devolución parcial;
- fulfillment parcial con tracking;
- caída temporal del ERP;
- evento duplicado;
- reconciliación posterior;
- carga representativa de catálogo y pedidos.
Señales de que hace falta rediseñar
- el equipo corrige stock manualmente cada día;
- hay pedidos duplicados o incompletos;
- un cambio de SKU rompe el flujo;
- nadie sabe qué sistema manda;
- no existe historial de errores;
- las devoluciones no vuelven a Shopify;
- las promociones se interpretan distinto;
- cada campaña necesita una excepción nueva;
- el conector bloquea el roadmap comercial.
Preguntas frecuentes
¿La integración debe ser en tiempo real?
Solo donde el negocio lo necesita. Pedidos y stock pueden requerir baja latencia; catálogo editorial o informes pueden funcionar por lotes.
¿Qué API de Shopify se utiliza?
La Admin GraphQL API es la base actual para muchas operaciones administrativas. El diseño concreto depende de objetos, permisos y versión vigente.
¿Conector estándar o desarrollo a medida?
Empieza por el conector si cubre procesos, datos, errores y soporte. El desarrollo propio se justifica cuando existe una diferencia real y capacidad para mantenerlo.
¿Quién debe ser la fuente de verdad del stock?
Normalmente el sistema que conoce almacenes, reservas y disponibilidad real: ERP o WMS. Shopify consume esa disponibilidad para vender.
Conclusión
Una integración ERP-Shopify funciona cuando el negocio puede explicar qué dato manda, cómo viaja, qué ocurre si falla y cómo se recupera. La API es solo una pieza; la arquitectura operativa decide la fiabilidad.
Fuentes oficiales revisadas
Referencias usadas para contrastar recomendaciones técnicas, documentación de plataforma y criterios de búsqueda.
