Todo el mundo lo ha hecho alguna vez. Un pedido duplicado. Un test que se quedó pendiente. Un cliente que compró por error. Abres WooCommerce, borras el pedido y sigues con tu día.
Pero hay una diferencia importante entre borrar un pedido de prueba y borrar un pedido 'real' porque algo ha fallado. Si lo haces una vez, es un incidente. Si lo haces cada semana, es un patrón. Y ese patrón tiene un nombre: falta de integridad transaccional.
Por qué borrar pedidos es peligroso
Cuando borras un pedido en WooCommerce, lo que haces es eliminar un registro de una operación comercial. Si ese pedido ya ha viajado al ERP — como factura, como salida de stock, o como asiento contable — acabas de crear una incoherencia entre sistemas que es muy difícil de rastrear.
- Stock fantasma. El ERP restó el stock cuando recibió el pedido. Si lo borras en WooCommerce, el stock de la web se recupera, pero el ERP no lo sabe. Ahora tienes cifras diferentes.
- Agujero contable. Si se generó una factura asociada al pedido y después lo borras, queda una factura sin pedido. O un pedido sin factura. Ambos casos son un problema para auditoría.
- Pérdida de trazabilidad. Con VeriFactu, cada operación fiscal debe ser trazable. Borrar un pedido que generó un documento fiscal puede ser un incumplimiento normativo.
- El ERP no se entera. La mayoría de conectores no propagan el borrado. El ERP sigue con su versión de los hechos. Para siempre.
Qué deberías hacer en lugar de borrar
La respuesta correcta nunca es borrar. Es cancelar. Un pedido cancelado sigue existiendo como registro, pero tu sistema puede gestionar la reversión de forma controlada: reponer el stock, revertir el asiento contable, y emitir un abono si es necesario.
El problema es que muchos conectores estándar no saben gestionar cancelaciones correctamente. Cuando reciben un cambio de estado a 'cancelled', no hacen nada. O hacen lo contrario de lo que debían. Por eso muchas empresas acaban optando por borrar: porque cancelar 'da más problemas'.
Eso es exactamente el síntoma de una integración que no garantiza la integridad de las operaciones.
Las 3 situaciones donde se borra (y no se debería)
- Pedido duplicado: 'El cliente compró dos veces, borramos uno'. → Solución real: idempotencia. El sistema debería detectar y rechazar el duplicado antes de llegar al ERP.
- Pedido con datos incorrectos: 'La dirección estaba mal, mejor borrar y hacer uno nuevo'. → Solución real: edición controlada con propagación a ambos sistemas.
- Pedido de test: 'Era una prueba y hay que borrarlo'. → Solución real: entorno de staging. Si haces pruebas en producción, estás añadiendo riesgo innecesariamente.
El coste real de la 'solución rápida'
Cada pedido borrado es tiempo invertido en detectar el problema, decidir qué hacer, y ejecutar la corrección manualmente. Si lo haces una vez al mes, parece poco. Pero si lo multiplicas por 12 meses, por 3 personas que intervienen (ecommerce manager, contable, almacén), y por el impacto en datos corporativos, el coste real es mucho más alto de lo que parece.
Y lo peor: cada borrado esconde el problema real. No lo soluciona. Lo pospone hasta que aparece con más fuerza — normalmente durante un pico de ventas o una auditoría.
Probablemente no tienes varios problemas
Si has llegado hasta aquí probablemente ya lo has visto: no es un fallo concreto, es un patrón. Cuando el ecommerce y el ERP no comparten una única fuente de verdad, los problemas aparecen en lugares distintos cada vez.
WooCommerce y tu ERP creen ser la fuente de verdad al mismo tiempo. Cuando ambos conviven sin control, aparecen incoherencias. No es un bug puntual. Es un problema de integridad transaccional.