Respuesta directa
Una integración de WooCommerce con un ERP funciona cuando se define un sistema maestro para cada dato: por ejemplo, el ERP para stock, tarifas y facturación; WooCommerce para el carrito y la experiencia de compra. Después se sincronizan eventos concretos, no tablas completas sin criterio.
El error típico es conectar la tienda para “que se actualice todo” sin acordar qué ocurre con una devolución, un pedido cancelado o una venta telefónica. El resultado son existencias negativas, facturas duplicadas y un equipo corrigiendo Excel. Empieza por el flujo que más trabajo manual o errores produce.
Qué hay que decidir antes de tocar la configuración
| Dato | Origen recomendado | Evento |
|---|---|---|
| Stock | ERP | Cambio confirmado de almacén |
| Pedido | WooCommerce | Pago o pedido válido |
| Factura | ERP | Regla fiscal y estado acordado |
| Precio | ERP o catálogo | Publicación controlada |
Plan de implementación paso a paso
- Mapa productos, variantes, impuestos, almacenes y estados de pedido.
- Elige identificadores estables: SKU y referencias externas, no nombres editables.
- Define la cola, los reintentos y el registro de cada operación.
- Sincroniza primero un catálogo reducido en entorno de prueba.
- Valida compra, reembolso, rotura de stock y pedido manual.
- Activa por fases y revisa diariamente las excepciones iniciales.
Diseña la sincronización por eventos, no por pantallas
El alta de un producto, una venta pagada, una cancelación y una devolución son eventos distintos. Para cada uno anota el identificador que viaja, el estado que permite continuar, el mensaje de error y la corrección manual autorizada. Si el ERP reserva unidades al recibir el pedido, WooCommerce no debe descontarlas de nuevo al marcarlo como completado.
Control de cierre diario
Compara pedidos pagados, pedidos enviados al ERP, facturas emitidas y variaciones de stock. La diferencia no se corrige borrando registros: se investiga con el ID de pedido y el log de la integración. Este control revela pronto un webhook perdido o una regla de estado mal definida.
Prueba una venta que se repite y una devolución parcial
En un entorno de prueba, crea un producto con dos variantes y vende una unidad de cada una. Comprueba qué referencia recibe el ERP, qué almacén reserva las unidades y qué importe corresponde a cada línea. Reenvía el mismo evento con el mismo identificador: debe recuperar la operación existente, sin crear otro pedido ni volver a descontar existencias. Cambia después el nombre comercial del producto y verifica que la relación sigue funcionando por sus identificadores.
Devuelve solo una de las variantes. El reembolso económico y la recepción física pueden ocurrir en momentos distintos; anota qué evento genera el abono y cuál devuelve una unidad al almacén. Compara cantidades y totales por línea, incluidos descuento y transporte. Si no coinciden, detén ese flujo y revisa el mapeo antes de probar otro pedido. No ajustes el saldo final para hacer cuadrar una operación cuyo recorrido sigue sin entenderse.
Recupera pedidos sin perder su historial
Simula una interrupción después de que el ERP acepte el pedido, pero antes de que el conector reciba la confirmación. Al recuperar el servicio, consulta primero la referencia externa. Esa comprobación evita repetir una creación que ya tuvo efecto. La cola debería distinguir una entrega pendiente, una operación confirmada y un rechazo que necesita corregir datos; cada situación exige una acción diferente.
Entrega a administración una vista con pedido de tienda, documento de ERP, último intento y motivo del bloqueo. Para corregir un SKU inexistente, arregla su correspondencia y reenvía esa operación concreta. Comprueba después factura, reserva y estado visible al comprador. Conserva los identificadores, pero evita copiar direcciones, credenciales o cuerpos completos a un registro de diagnóstico compartido.
Riesgos habituales y cómo evitarlos
- Dos sistemas editando stock: reserva una fuente de verdad y limita la edición en el otro.
- Reintentos que duplican pedidos: usa una clave idempotente y guarda la respuesta del ERP.
- Estados mal traducidos: acuerda cuándo se descuenta, factura y devuelve stock.
Cuando la decisión depende de una función concreta, conviene contrastarla con la documentación oficial de la API REST de WooCommerce antes de desplegar. La documentación del proveedor cambia con más frecuencia que una guía general.
Cuándo pedir ayuda técnica
Si hay varios almacenes, tarifas B2B o un ERP heredado, la arquitectura merece un análisis previo. Codanter puede diseñar la integración dentro de su servicio de automatización y ecommerce.
Consulta automatización e integración de sistemas, el servicio de ecommerce y la guía sobre WooCommerce con catálogos grandes.
Equipo Codanter
Desarrollo web, IA y automatización