Una reducción doble puede provocar una falsa rotura de stock: la tienda muestra agotado aunque del almacén solo haya salido una unidad. El segundo cambio puede venir de eventos de pago duplicados, hooks propios, ajustes manuales o una sincronización externa.
Reconcilia primero la cantidad. Otro pedido, devolución o movimiento de almacén puede explicar parte de la diferencia.
Construye la línea temporal
Lee las notas privadas del pedido y el historial de inventario disponible. Registra cambios de estado, notas de stock, eventos de pasarela y sincronizaciones.
- ID de pedido y cantidad de la línea
- producto o variación
- stock anterior y posterior
- actor o integración
- ID del evento del proveedor
- fecha, hora y zona horariaNo incluyas datos del cliente ni credenciales. La secuencia debe mostrar si existieron dos operaciones reales o solo una lectura atrasada.
Identifica quién manda sobre el inventario
Determina si la fuente principal es WooCommerce, un ERP, almacén o marketplace. Dos sistemas pueden reaccionar a la misma venta y devolver ambos una reducción.
Documenta la dirección: WooCommerce envía la venta y recibe una cantidad absoluta, o el sistema externo recibe un delta. Combinar ambos modelos exige claves de idempotencia. Si nuevos pedidos amplían el error, pausa únicamente la ruta defectuosa conservando logs y continuidad de preparación.
Inspecciona el marcador de reducción
WooCommerce registra si ya descontó el stock para que las llamadas normales no repitan la operación. El código que evita las APIs o borra este marcador anula la protección.
$order = wc_get_order( $order_id );
$reduced = $order ? $order->get_meta( '_order_stock_reduced' ) : null;Léelo como evidencia. Cambiarlo manualmente puede provocar otra reducción o impedir una reposición legítima.
Localiza hooks duplicados
Busca en el código propio llamadas a wc_reduce_stock_levels(), setters de producto y callbacks conectados a Processing, Completed o pago completado. Un plugin puede actuar en dos transiciones para el mismo evento comercial.
Los hooks pueden ejecutarse más de una vez. Cada callback debe comprobar si su evento ya fue procesado, no asumir que toda invocación es única. No edites el núcleo ni desactives globalmente todos los hooks de inventario.
Revisa webhooks y reintentos
Las pasarelas reintentan una notificación si reciben timeout. La misma confirmación puede llegar varias veces y cambiar estados si el handler no es idempotente.
Compara IDs y entregas del proveedor con las notas. Un doble clic también puede crear dos pedidos distintos; demuestra que se trata realmente de un pedido con dos descuentos.
Corrige respuestas lentas o fallidas y haz que un evento repetido termine correctamente sin repetir efectos. Conserva el ID procesado durante el plazo de reintentos.
Diferencia reducción, restauración y nueva reducción
Una reposición válida seguida de otro descuento puede parecer duplicación al mirar solo el valor final. Lee la secuencia completa de cancelaciones y reembolsos.
El reembolso no siempre repone existencias automáticamente; el personal puede marcar esa opción o ajustar manualmente. Los estados personalizados también pueden restaurar y volver a reducir en un orden inesperado. Cada movimiento necesita motivo y referencia.
Corrige sin reescribir el pedido
Cuenta el stock físico y revisa ventas, devoluciones y ajustes del periodo. Devuelve solo el exceso demostrado mediante una herramienta compatible del sistema propietario.
Añade una nota administrativa. No lleves un pedido pagado a Pending y de vuelta para manipular cantidades: puede reenviar emails, facturas y sincronizaciones.
Prueba en sandbox pago correcto, reintento del webhook, cambio de estado, cancelación y devolución. Una venta lógica debe descontar una vez. El mantenimiento recurrente debe detectar varias notas de reducción para el mismo pedido y cambios sin una operación asociada.