Integrar WooCommerce con un ERP en B2B no consiste en conectar dos APIs y dar el proyecto por resuelto. La dificultad real está en decidir qué sistema manda sobre cada dato, qué información necesita tiempo real, cómo se modelan reglas de cuenta y qué ocurre cuando una sincronización falla a mitad de una operación.
La arquitectura correcta no intenta que ambos sistemas sepan todo. Intenta que cada uno sea responsable de aquello que entiende mejor y que la integración transporte cambios de forma observable y recuperable.
Cuándo WooCommerce encaja en un escenario B2B
WooCommerce puede funcionar muy bien cuando el negocio necesita flexibilidad de contenido, catálogo, experiencia y extensibilidad, y el ERP ya concentra clientes, precios, pedidos o facturación. El encaje empeora cuando se espera que WordPress replique una lógica comercial extremadamente compleja que ya existe en otro sistema y cambia constantemente.
La pregunta no es si WooCommerce “puede” hacer una regla concreta; casi siempre puede desarrollarse. La pregunta es dónde debe vivir esa regla para que siga siendo gobernable dentro de tres años.
Primero: crear una matriz de fuentes de verdad
Antes de escribir integración, lista los dominios principales: cliente, usuario, dirección, catálogo, atributos, precio, disponibilidad, pedido, factura, crédito, envío y documento. Para cada uno define sistema propietario y consumidores.
En una integración WooCommerce ERP típica, ERP suele mandar sobre cuenta, condiciones comerciales, precio final, crédito, pedido y factura. WooCommerce puede mandar sobre sesión, contenido editorial, navegación, carrito previo a confirmación y ciertas preferencias de usuario. PIM puede ser propietario de enriquecimiento de producto.
Clientes y cuentas: no confundir usuario con cliente
WordPress piensa de forma natural en usuarios; B2B piensa en cuentas con varios usuarios. La integración necesita una capa que relacione usuarios individuales con una entidad de cliente ERP. Esa relación debe soportar roles, centros, permisos y cambios de personal.
No uses el email como único identificador permanente si el negocio tiene cuentas corporativas complejas. Conserva IDs de ERP y claves estables. Un usuario puede cambiar de email; una empresa puede fusionarse; dos contactos pueden compartir dominio sin pertenecer a la misma cuenta.
Precios: calcular o sincronizar
Hay dos grandes patrones. El primero sincroniza listas y reglas a WooCommerce y calcula localmente. El segundo consulta al ERP o a un pricing service durante la experiencia. El modelo local es más rápido y tolerante a caídas; el remoto reduce duplicación de lógica.
La decisión depende de frecuencia de cambios, complejidad y necesidad de exactitud inmediata. Un precio contractual que cambia una vez al trimestre puede sincronizarse. Una cotización dependiente de materias primas o reglas complejas puede requerir cálculo remoto.
En ambos casos debe existir una forma de explicar discrepancias: qué precio se mostró, con qué versión de datos y qué valor recibió finalmente el ERP.
Stock y disponibilidad: la cifra no siempre es la promesa
El stock físico del ERP puede no equivaler a cantidad vendible. Hay reservas, almacenes, lotes, pedidos en curso y reglas de asignación. Diseña un concepto de disponibilidad adecuado al comprador: unidades disponibles, fecha estimada, disponibilidad por almacén o simplemente estado.
Para referencias críticas puede utilizarse consulta en tiempo real. Para catálogos grandes, una combinación de snapshots frecuentes y validación final antes de confirmar pedido suele ser más eficiente.
Catálogo: ERP no siempre es PIM
Muchos ERP contienen SKU y descripción administrativa, pero no la información necesaria para vender: beneficios, aplicaciones, compatibilidades, documentos, imágenes o taxonomía. No fuerces al ERP a convertirse en PIM sólo porque ya existe.
Cuando hay PIM, WooCommerce debería recibir contenido enriquecido desde él y datos transaccionales desde ERP. Define reglas de merge para evitar que una sincronización administrativa borre contenido comercial.
Pedidos: diseñar una máquina de estados
El momento más delicado es el traspaso del pedido. Decide cuándo WooCommerce considera la operación aceptada: al crear el pedido local, al recibir confirmación ERP o tras validar crédito. Cada elección tiene consecuencias de UX y soporte.
Una arquitectura robusta utiliza IDs de correlación e idempotencia. Si se reintenta la misma petición, no debe crearse un segundo pedido. Guarda respuesta ERP y estado de integración de forma separada del estado comercial mostrado al cliente.
Webhooks, colas y procesos batch
Los webhooks son buenos para avisar de cambios rápidos, pero no deberían ser la única garantía. Pueden perderse, duplicarse o llegar fuera de orden. Las colas permiten desacoplar sistemas y reintentar. Los procesos batch sirven como reconciliación.
Un patrón sólido combina eventos para velocidad y una rutina periódica que comprueba que ambos lados siguen coherentes. Por ejemplo, el webhook actualiza el estado de pedido y una reconciliación nocturna detecta pedidos que no recibieron evento.
Reintentos sin duplicar efectos
Todo proceso remoto debería asumir que habrá timeouts. Si no sabemos si ERP recibió una petición antes de que la conexión se cortara, repetirla sin clave idempotente puede duplicar pedidos. Diseña operaciones que puedan reintentarse con seguridad.
Diferencia errores temporales —timeout, servicio caído— de errores de negocio —cliente bloqueado, referencia no válida—. Los primeros pueden reintentarse automáticamente; los segundos necesitan intervención o mensaje al usuario.
Una cola de excepciones es parte del producto
Las integraciones B2B no deben ocultar fallos en un log técnico. Crea una vista operativa de excepciones: pedido pendiente de ERP, precio sin respuesta, cliente no mapeado, documento fallido. Asigna responsable y acción posible.
El objetivo no es lograr cero errores, sino detectar y resolver rápidamente los inevitables sin que el cliente sea quien descubra el problema.
Observabilidad: qué debería medirse
- Latencia por tipo de operación.
- Tasa de fallos y reintentos.
- Mensajes en dead-letter queue.
- Diferencias detectadas en reconciliación.
- Pedidos duplicados evitados por idempotencia.
- Antigüedad del último dato de precio y stock.
- Errores por versión de API o sistema.
Estos datos deberían generar alertas cuando superan umbrales. Revisar logs manualmente sólo después de que un cliente llame no es observabilidad.
Seguridad y datos
No expongas credenciales ERP al navegador. La integración debe ejecutarse en servidor o middleware, con secretos gestionados y privilegios mínimos. Registra acciones sensibles sin guardar más datos personales de los necesarios.
Si el portal permite información comercial confidencial, valida que cada consulta esté filtrada por cuenta. Un error de caché o autorización que mezcla precios entre clientes es un incidente grave.
Cómo probar una integración WooCommerce ERP
Utiliza cuentas representativas y escenarios extremos: cambio de tarifa durante una sesión, stock agotado entre carrito y confirmación, ERP lento, pedido parcial, usuario sin permiso, devolución, moneda diferente y referencia discontinuada. Prueba también recuperación después de caída.
Las pruebas de contrato entre APIs ayudan a detectar cambios antes de producción. Si ERP actualiza versión, el equipo ecommerce debería saber si algún campo crítico cambia.
SEO y GEO siguen siendo parte del sistema
La integración sostiene la transacción, pero la parte pública necesita contenido indexable y comprensible. Datos de producto ricos, páginas de aplicación, documentación y relaciones claras entre familias permiten posicionar y ser citados por motores generativos.
Evita que una dependencia del ERP haga que buscadores reciban páginas vacías cuando el sistema está lento. El contenido público importante debe poder servirse de forma resiliente.
Preguntas frecuentes
¿Hace falta tiempo real para todo?
No. Usa tiempo real donde la decisión depende de información inmediata. Para el resto, sincronización frecuente y reconciliación puede ser más simple y fiable.
¿Es mejor integrar directamente o usar middleware?
La conexión directa puede ser suficiente en escenarios simples. Middleware aporta valor cuando hay varios sistemas, transformaciones, colas, observabilidad o necesidad de desacoplar cambios.
¿Quién debe monitorizar la integración?
Necesita una responsabilidad operativa clara. Desarrollo puede mantener la tecnología, pero negocio y operaciones deben tener visibilidad sobre excepciones que afectan pedidos y clientes.
Diseñar una capa anti-corrupción entre ERP y ecommerce
Cuando el ERP utiliza estructuras antiguas o nomenclaturas pensadas para back office, no conviene copiarlas directamente al dominio ecommerce. Una capa de transformación puede convertir códigos, estados y modelos de datos a conceptos estables orientados al canal digital. Esto evita que cada cambio de ERP obligue a modificar lógica de frontend.
La capa también facilita pruebas y observabilidad: puede validar contratos, rechazar mensajes incompletos y registrar transformaciones. En arquitecturas con varios canales, la misma integración puede alimentar ecommerce, portal de distribuidores y aplicaciones sin duplicar adaptadores.
Versionado y cambios controlados
Define versiones de API y contratos de payload. Un nuevo campo opcional es diferente de renombrar un identificador usado en producción. Los equipos deben conocer con antelación cambios incompatibles y disponer de entorno de pruebas. Las integraciones críticas merecen calendario de mantenimiento y rollback igual que cualquier otro componente de producto.
Reconciliación financiera y de pedidos
No basta con comprobar que la API respondió 200. Compara periódicamente pedidos, totales, impuestos, estados y devoluciones entre sistemas. Una reconciliación diaria detecta diferencias silenciosas que los logs técnicos no consideran error. Esta capa es especialmente importante cuando hay pagos, crédito o facturación automatizada.
Ownership: quién decide cuando los datos no coinciden
Las discrepancias no son sólo un problema técnico. Si WooCommerce y ERP muestran distinto precio o estado, debe existir un propietario de negocio que defina la regla correcta y un propietario técnico que implemente la corrección. Sin esa separación, los equipos pueden pasar horas buscando “qué sistema está mal” sin una política sobre cuál debería mandar.
Crea un runbook con responsables, escalado y ejemplos de incidentes. Esto reduce tiempo de diagnóstico y permite incorporar nuevos miembros sin depender de conocimiento oral.