Integraciones de WooCommerce con ERP y API de mayoristas

#Integraciones de WooCommerce con ERP y API de mayoristas

Si necesita ayuda general para construir y hacer crecer una tienda, empiece por la página de desarrollador de WooCommerce. Esta página trata un problema más concreto y técnico: el intercambio de datos entre WooCommerce y sistemas externos.

#Qué es realmente una integración de WooCommerce

En la mayoría de las tiendas, la verdad sobre los productos no vive en WooCommerce. Vive en el ERP, en el sistema de almacén o en la API de un mayorista. WooCommerce es el escaparate de venta, pero el stock, los precios y parte de los datos de producto vienen de otro sitio. Una integración es la capa que mantiene esos dos mundos en concordancia.

En la práctica, una integración responde a tres preguntas:

• Qué sincronizamos - catálogo, atributos, niveles de stock, precios, pedidos, datos de clientes.
• En qué dirección - unidireccional (el sistema de origen dicta a la tienda) o bidireccional (por ejemplo, los pedidos regresan al ERP).
• Con qué frecuencia - desde consultas programadas cada pocos minutos hasta actualizaciones basadas en eventos mediante webhooks.

#Con qué puede integrar WooCommerce

No tiene que hacerlo todo a la vez. El primer paso más habitual es la sincronización de stock y precios, porque es la que se amortiza más rápido en tiempo de soporte recuperado y reembolsos evitados.

#Cómo funciona la sincronización de datos

La mecánica es similar en todos los casos, tanto si el origen es un ERP como una API de mayorista. Cambia el origen, no el principio.

#Mapeo de datos

El sistema de origen describe los productos con su propia estructura de campos. La primera tarea de una integración es traducir eso al modelo de productos y atributos de WooCommerce: EAN e índice como claves que enlazan los registros, atributos técnicos a atributos y variaciones, medios y descripciones a las páginas de producto. Mantenemos el mapa de campos declarativo, de modo que añadir un nuevo parámetro significa ampliar el mapeo, no reescribir la lógica.

#Sincronización de stock y precios

El núcleo de la mayoría de las integraciones es la consulta programada de dos cosas: el nivel de stock y el precio. Los artículos no disponibles en el sistema de origen se ocultan o marcan como no disponibles automáticamente, lo que elimina el fallo más caro que puede cometer una tienda - vender algo que no se puede entregar. Un cambio de precio en el sistema de origen se propaga a la tienda en el siguiente ciclo.

#Lógica de margen

Los precios de un ERP o un mayorista suelen ser de coste, no el precio de venta. Por encima de la capa de extracción de datos se sitúa la lógica de margen: el sistema aplica un margen definido sobre el precio de origen y solo el resultado llega a WooCommerce. El propietario dirige la rentabilidad con reglas, no editando precios a mano.

#Una integración real

La misma mecánica está detrás de nuestro proyecto para una tienda de recambios de automoción conectada directamente a la API REST de un mayorista: integración de WooCommerce con la API de un mayorista. Allí el catálogo, el stock y los precios se mantienen actualizados por sí solos, y el margen protege la rentabilidad frente a una lista de proveedor cambiante.

#Con qué sistemas ERP integramos

Una distinción importante: integramos WooCommerce con la API de estos sistemas, no implementamos el ERP en sí. Este es trabajo de WordPress, PHP e intercambio de datos, no consultoría de ERP.

• ERP en la nube: Microsoft Dynamics 365 Business Central, SAP Business One, Oracle NetSuite, Odoo. Estos exponen API REST, lo que mantiene limpia la conexión con la tienda.
• Contabilidad y ERP locales: sistemas como Sage, Holded o A3 (Wolters Kluwer), habituales en el mercado español, integrados normalmente a través de su API o de una capa de middleware.

Si su sistema no está en la lista pero tiene alguna API o exportación de datos, normalmente se puede integrar.

#Cómo diseñamos la arquitectura de integraciones para ERP concretos

Cada ERP tiene su propia API, formato de datos y trampas. A continuación explicamos cómo abordamos los sistemas más habituales. Son patrones de arquitectura, no un plugin comprado por unos euros.

#SAP Business One - escala y el problema de wp_postmeta

Distribución industrial: decenas de miles de productos activos, actualizaciones de precios frecuentes (varias veces al día cuando se mueven los tipos de cambio), cientos de atributos. La estructura EAV por defecto de WordPress guarda cada atributo en wp_postmeta, que a esa escala se hincha hasta millones de filas; las actualizaciones de precios en tiempo real provocan entonces deadlocks de MySQL y timeouts 504 para los compradores.

• HPOS y tablas personalizadas: dejamos de escribir los atributos en wp_postmeta y usamos una tabla MySQL plana y dedicada, diseñada para las consultas de SAP B1.
• Elasticsearch como capa de búsqueda: SAP actualiza los datos en Elasticsearch por API y el front obtiene los resultados y los filtros desde ahí, esquivando MySQL. Esta capa puede reducir el TTFB de varios segundos al rango de los ~150 ms.
• Colas (RabbitMQ): las actualizaciones de SAP aterrizan en una cola de mensajes y un worker en segundo plano procesa lotes de unos cientos de productos cada vez, manteniendo la tienda receptiva 24/7.

#Microsoft Dynamics 365 (con BaseLinker y POS)

Un gran minorista que vende a través de WooCommerce, marketplaces (vía BaseLinker) y tiendas físicas con un POS sobre Dynamics 365. Sin una jerarquía estricta aparecen bucles de sincronización y condiciones de carrera (la última unidad vendida en tienda y un segundo después en un marketplace), que producen stock negativo.

• Única fuente de verdad: imponemos una jerarquía en la que Dynamics es el maestro absoluto y WooCommerce y BaseLinker son esclavos.
• Capa Redis: en lugar de consultar constantemente la lenta API de Dynamics, ejecutamos Redis en memoria. Una venta en tienda dispara un webhook que actualiza Redis, y WooCommerce y BaseLinker comprueban la disponibilidad en Redis (respuesta de un solo dígito de milisegundos) antes de finalizar un carrito, eliminando la sobreventa.

#Odoo (open source) - configuradores bajo pedido

Los fabricantes configuran los productos en Odoo (una lista de materiales) donde el precio de un componente depende de otras elecciones. Las variaciones de WooCommerce no pueden modelar eso, y trasladar la lógica de producción a PHP produce código imposible de mantener.

• Enfoque desacoplado / headless: WooCommerce es el sistema de carrito y de transacciones (pago, correos), mientras que el frontend (Astro/Vue) habla directamente con la API de Odoo, pidiéndole precios y viabilidad de producción al vuelo. Al hacer “añadir al carrito” se envía a WooCommerce un producto personalizado con un precio calculado por Odoo y un PDF de especificaciones generado, sin duplicar la lógica de negocio.

#Comarch Optima, InsERT Subiekt, enova365 (mercado polaco y de Europa Central)

• Comarch Optima: Optima expone los datos por un WebService/API, así que construimos un middleware dedicado en PHP y usamos sincronización diferencial (delta) - un trabajo CRON pide solo los índices que han cambiado en la última ventana, reduciendo la carga de MySQL en un orden de magnitud frente a una importación completa. Los precios B2B se calculan en tiempo real a partir del grupo de descuento del cliente, en lugar de almacenarse como miles de variaciones de precio en wp_postmeta.
• InsERT Subiekt GT / nexo: intercambio de datos por EPP y API; una reserva dura bloquea el stock en Subiekt durante unos minutos en el checkout para evitar la sobreventa en los picos, y un documento de corrección dispara un webhook que pasa el pedido de WooCommerce a devuelto y repone el artículo.
• enova365: para productos con muchas variantes (colores x tallas, cada una con su propio EAN) usamos variantes planas mapeadas a JSON y cargadas de forma asíncrona por REST, en lugar de generar cientos de miles de posts product_variation.

#JTL-Wawi (Alemania) y Holded (España)

• JTL-Wawi: omnicanal con multialmacén. Un enrutamiento lógico analiza el código postal del cliente y elige algorítmicamente el almacén con el envío más rápido; la gestión del One Stop Shop recalcula el IVA al vuelo según el país de destino, de modo que la factura en JTL lleva el tipo correcto. WooCommerce funciona en paralelo con BaseLinker para Amazon y eBay.
• Holded: un ERP en la nube y API-first - una integración totalmente sin archivos sobre la API REST nativa, con autenticación por token y webhooks. La lógica de facturación reconoce el importe del carrito e indica a Holded que genere el tipo de documento correcto (por ejemplo, una factura simplificada para importes pequeños), devolviendo un PDF para adjuntar al correo de WooCommerce.

#Arquitectura enterprise: rendimiento y fiabilidad

A gran escala de ERP dejamos atrás el “instala un plugin”. Esto es ingeniería exigente:

• Headless / desacoplado: WordPress es el motor de administración (backend) y la tienda se renderiza en Astro o Next.js, atacando una API GraphQL o REST y esquivando el SQL lento, lo que hace la tienda más rápida y resistente. Más en soluciones enterprise.
• Procesamiento asíncrono (colas): sincronizar decenas de miles de productos en un script PHP plano provoca timeouts. Lo basamos en colas (RabbitMQ o Redis) que procesan pequeños fragmentos en segundo plano.
• Gestión de errores y logging: si la API del ERP no responde, bloqueamos el checkout con un mensaje en lugar de aceptar pedidos en el vacío; un logging completo de errores permite un diagnóstico rápido.

#Problemas técnicos que resolvemos

• Límite de peticiones de la API (429): los sistemas en la nube limitan las peticiones. Implementamos backoff exponencial (ante un 429 el script espera y reintenta) más chunking, empaquetando los datos en peticiones JSON de bulk-update en lugar de miles de llamadas individuales.
• Desajustes de tipos de datos (redondeo): un ERP puede guardar los precios con cuatro decimales mientras WooCommerce espera dos. En el middleware aplicamos casting estricto de tipos y conciliamos el redondeo por línea de factura, evitando errores de céntimos que se acumulan a lo largo de cientos de pedidos.
• Imágenes, ancho de banda y el límite de inodos: importar imágenes físicas a la biblioteca de medios de WordPress (generando varias miniaturas de cada una) agota el límite de archivos del servidor. En su lugar, servimos las imágenes desde almacenamiento externo (Amazon S3 o Cloudflare Image Resizing) mediante URLs mapeadas desde el ERP, ahorrando espacio y acelerando la propia sincronización.

#Cuándo merece la pena plantearse una integración

• Actualiza el stock y los precios a mano o por importación de archivos y no escala.
• Recibe pedidos de productos que el proveedor en realidad no tiene en stock.
• Los precios de la tienda se desvían de la lista de precios del mayorista o del ERP.
• Los pedidos hay que reintroducirlos a mano en el sistema contable o de almacén.