La sincronización de stock en WooCommerce no consiste sólo en copiar una cantidad desde un ERP, un WMS o un catálogo externo. El problema es coordinar decisiones tomadas en momentos distintos: una venta en la tienda, una recepción en almacén, una cancelación, una reserva temporal o una corrección manual. Dos sistemas pueden mostrar cifras diferentes y, aun así, estar funcionando conforme a sus propios tiempos y reglas.
El riesgo aparece cuando esa diferencia permite vender unidades que ya no están disponibles o cuando, para evitarlo, la tienda consulta o espera al sistema externo en cada paso de compra. El primer enfoque causa sobreventas; el segundo puede degradar catálogo, carrito y checkout. La arquitectura debe separar la experiencia de compra del procesamiento operativo y hacer verificable cada cambio.
Definir una fuente de verdad para cada tipo de stock
Antes de elegir APIs, webhooks o tareas programadas, hay que definir qué representa cada cifra. “Stock” suele agrupar conceptos que no son intercambiables:
- Stock físico: unidades realmente presentes en una ubicación.
- Stock comprometido: unidades asignadas a pedidos que siguen activos.
- Stock reservado: unidades retenidas temporalmente durante una compra o una validación de pago.
- Stock disponible para vender: cantidad que puede exponerse al cliente según reglas comerciales, reservas y márgenes de seguridad.
- Stock publicado: valor actualmente mostrado o aplicado por WooCommerce, junto con el instante y origen de su actualización.
El ERP o WMS suele ser la autoridad para el stock físico y para movimientos de almacén. WooCommerce puede ser la autoridad para el estado del carrito, del pedido y de una reserva asociada a la sesión de compra. La disponibilidad comercial puede requerir una regla propia, por ejemplo:
disponible_para_vender = físico - comprometido - reservado - margen_de_seguridad
Esta regla debe tener un propietario claro. Si WooCommerce y el sistema externo la calculan de forma distinta, intercambiar una cifra final no resolverá la inconsistencia. También conviene almacenar la fecha de cálculo, la versión o secuencia del evento y la ubicación afectada cuando el inventario es multialmacén.
Elegir el flujo de actualización según el riesgo
No todos los cambios merecen el mismo tratamiento. Una importación nocturna puede ser suficiente para un catálogo informativo, pero no para referencias de alta rotación o stock escaso.
Eventos, consultas, lotes y enfoque híbrido
- Actualización por eventos: el sistema externo emite cambios de inventario y un consumidor actualiza la proyección disponible en WooCommerce. Reduce la latencia, pero exige gestionar reintentos, duplicados y orden.
- Consulta bajo demanda: la tienda consulta disponibilidad al entrar en el carrito o antes del pago. Puede ser útil como validación puntual, pero no debe convertir la disponibilidad del proveedor en una dependencia síncrona de cada página.
- Sincronización periódica: un proceso recoge cambios por lotes. Es más simple para catálogos amplios, aunque la ventana entre ejecuciones aumenta el riesgo de discrepancia.
- Modelo híbrido: eventos para cambios urgentes, procesos periódicos para recuperar omisiones y una validación final para productos sensibles.
En la práctica, el modelo híbrido suele separar la lectura rápida de la compra de la operación lenta de inventario. WooCommerce sirve una proyección local del stock; los eventos actualizan esa proyección en segundo plano; y la conciliación detecta lo que no llegó o no pudo aplicarse.
Reservar durante la compra sin descontar dos veces
Una reserva no es necesariamente una venta. Debe crearse en un momento definido, tener caducidad y poder liberarse por cancelación, fallo de pago o abandono. Si WooCommerce reduce su stock nativo al crear o cambiar el estado de un pedido y, además, el ERP descuenta la misma unidad al recibir ese pedido, puede producirse un doble descuento.
La solución requiere definir un único flujo contable. Por ejemplo, WooCommerce puede registrar la reserva local y enviar al sistema externo una solicitud identificada de reserva. Cuando el pago se confirma, esa reserva pasa a compromiso o salida según la operación externa. Si vence, ambas partes deben recibir o derivar una liberación verificable.
Una reserva debe incluir como mínimo el identificador de pedido o sesión, SKU o variación, cantidad, estado, hora de expiración y una clave única de operación. No basta con almacenar una cantidad agregada: sin identidad no es posible saber qué liberar ni explicar una falta de disponibilidad.
La reducción visible de stock, la reserva operativa y el movimiento físico son transiciones distintas. Decidir dónde ocurre cada una evita ajustes manuales posteriores que ocultan el origen del error.
Procesar cambios con colas, idempotencia y orden
Las actualizaciones de inventario no deberían ejecutarse como trabajo pesado dentro de una petición web del catálogo o del checkout. Un endpoint puede validar y persistir el mensaje rápidamente; un consumidor asíncrono procesa después la actualización, registra el resultado y aplica reintentos controlados.
Las colas desacoplan picos de eventos de la capacidad de WooCommerce y del sistema externo. Sin embargo, una cola no corrige por sí sola duplicados ni eventos fuera de orden. Cada mensaje necesita un identificador idempotente, y el procesador debe recordar si ya aplicó esa operación.
clave_idempotencia = origen + tipo_evento + identificador_operacion
Para cada SKU, ubicación o combinación que comparta inventario, conviene conservar una secuencia o marca temporal fiable. Si llega un evento antiguo después de uno más reciente, no debe sobrescribirlo sin una regla explícita. Cuando no existe un orden global garantizado, es preferible aceptar el evento, marcar la entidad para conciliación y consultar el estado autorizado antes de corregir.
También hay que limitar la capacidad: tamaño máximo de lote, concurrencia del consumidor, reintentos con espera progresiva y una cola de incidencias para mensajes que superen el límite. Reintentar indefinidamente una credencial inválida o un SKU inexistente sólo acumula retraso y oculta el problema.
Responder a retrasos e indisponibilidad sin bloquear la tienda
La tienda necesita una política de degradación. Si el ERP no responde, no es razonable que cada ficha de producto quede esperando una conexión externa. La página puede usar la última proyección conocida, pero la organización debe decidir qué ocurre según la antigüedad del dato y la criticidad del artículo.
- Para stock amplio, puede mantenerse la disponibilidad publicada mientras se alerta por retraso.
- Para unidades escasas o productos de alta demanda, puede ocultarse la compra, aplicar un margen conservador o exigir una validación adicional antes de confirmar.
- Para un pedido ya iniciado, puede permitirse el avance hasta una verificación final, siempre que el mensaje comercial y la política de excepción estén definidos.
La confirmación de pedido tampoco debe depender de una tarea larga. Debe registrar de forma duradera la intención de compra y desencadenar el proceso posterior. Si una reserva externa falla, el pedido necesita un estado operativo claro para revisión, pago pendiente o cancelación, no una respuesta ambigua al cliente ni un proceso bloqueado.
Conciliar diferencias sin borrar decisiones recientes
La conciliación compara la proyección de WooCommerce con la fuente autorizada de inventario y con las reservas activas. Debe ejecutarse de forma programada y también tras incidentes, acumulación de mensajes o recuperación de un servicio externo.
No conviene reemplazar ciegamente todas las cantidades. Una corrección puede sobrescribir una reserva creada hace segundos que todavía no ha sido propagada. Antes de aplicar el ajuste, hay que comprobar la marca temporal, versión o secuencia de ambas partes, las operaciones pendientes y las reservas locales activas. Las diferencias sin explicación deben pasar a revisión, especialmente si afectan a pedidos pagados o productos con stock negativo.
Una conciliación útil clasifica la causa: evento no recibido, fallo al procesar, cambio manual, SKU mal asociado, cálculo diferente de disponible o retraso normal dentro de la ventana acordada. Corregir la cifra sin registrar la causa hace que el mismo error vuelva a aparecer.
Trazabilidad y pruebas antes de activar la integración
Cada cambio debería dejar una línea de auditoría: SKU y variación, origen, cantidad anterior y nueva, tipo de movimiento, identificador de evento, pedido o reserva relacionada, fecha de recepción, fecha efectiva, resultado y motivo de rechazo. Esta información permite responder por qué un cliente vio disponibilidad, por qué se liberó una unidad o por qué se ajustó un producto.
Antes de una activación gradual, las pruebas deben simular condiciones operativas, no sólo una actualización correcta:
- Dos compras concurrentes de la última unidad.
- Eventos repetidos, retrasados y recibidos fuera de orden.
- Cancelaciones, pagos rechazados, expiración de reservas y devoluciones.
- Caída temporal del ERP, WMS o API de catálogo.
- Picos de cambios de stock y recuperación de una cola acumulada.
- Ediciones manuales en WooCommerce y en el sistema externo.
- Variaciones, kits, productos compartidos entre canales y cambios de SKU.
Lista de decisión para evaluar el diseño actual
- ¿Está definida la fuente de verdad para stock físico, disponible, reserva y compromiso?
- ¿Se sabe exactamente cuándo se crea, confirma y libera una reserva?
- ¿Cada operación es idempotente y puede relacionarse con un pedido, SKU y origen?
- ¿Las actualizaciones pesadas se procesan fuera de catálogo, carrito y checkout?
- ¿Existe una política explícita para datos antiguos o servicios externos indisponibles?
- ¿La conciliación protege operaciones recientes y clasifica las causas de diferencia?
- ¿Los equipos de ecommerce y operaciones pueden explicar una disponibilidad concreta mediante registros?
Si alguna respuesta es negativa, la prioridad no debería ser aumentar la frecuencia de sincronización sin más. El rediseño debe centrarse en estados, propiedad del dato, transiciones de reserva y recuperación ante fallos. Así, la sincronización de stock en WooCommerce puede proteger la venta sin convertir el inventario externo en un punto único de bloqueo.
