Un pedido puede tener una dirección dañada, metadatos de línea ausentes, estado incorrecto o reembolso local incompleto mientras el historial de la pasarela sigue siendo válido. Editar IDs de transacción, totales o estados históricos para mejorar la pantalla puede destruir la trazabilidad necesaria para contabilidad y disputas.
Trata la pasarela como evidencia independiente. Haz copia de la base y documenta la corrección antes de tocar WooCommerce.
Define el campo dañado
Anota qué está mal, cómo se detectó y qué fuente demuestra el valor correcto. Separa datos introducidos por el cliente, cálculos, hechos de pago, movimientos de stock y fulfilment.
Fuentes posibles:
- transacción o reembolso de la pasarela
- emails o exportaciones originales
- cálculos fiscales y de envío
- registro de almacén
- logs protegidos
- corrección de dirección confirmadaNo aceptes un email no verificado para cambiar datos sensibles de cuenta o entrega.
Conserva el estado original
Haz backup y exporta una representación del pedido con privacidad controlada. Registra ID, almacenamiento activo, estado, totales y referencias externas.
Restringe el acceso y define la retención: contiene información personal y comercial. Evita editar mientras llegan callbacks de pago o sincronizaciones. Si es imprescindible, pausa solo la integración implicada y registra la ventana.
Concilia el pago por separado
En el proveedor, confirma captura, reembolso, disputa y payout. Guarda IDs estables e importes, nunca datos de tarjeta.
El estado WooCommerce no prueba el estado financiero y cambiarlo no mueve dinero. No lances otra captura o devolución para alinear la interfaz. Si los totales discrepan, clasifica primero impuestos, envío, comisiones, moneda y devoluciones parciales.
Usa el datastore activo
Comprueba si HPOS es autoritativo. Carga y actualiza con las APIs para que WooCommerce gestione tablas y cachés correctas.
$order = wc_get_order( $order_id );
if ( ! $order ) {
throw new RuntimeException( 'El pedido no puede cargarse con seguridad' );
}No escribas directamente en wp_posts, postmeta o tablas HPOS. SQL bruto puede dejar direcciones, lookup y caché incoherentes.
Separa correcciones de eventos históricos
Corrige una errata de dirección como cambio administrativo actual y añade nota privada. Registra un reembolso ya completado externamente como reembolso manual local vinculado a su ID. Ajusta stock mediante una operación auditable.
No borres notas antiguas, reutilices un ID para otro cobro ni muevas estados para disparar efectos. Para impuestos o facturas, sigue el procedimiento contable de rectificación; no reescribas silenciosamente una venta cerrada.
Ensaya sobre una copia
Usa staging con email saliente, indexación, pagos reales y fulfilment desactivados. Aplica exactamente el cambio compatible y confirma que el pedido carga en administración, informes e integraciones.
Revisa totales, redondeo, líneas y permisos. Un script debe apuntar a IDs explícitos, validar precondiciones y ofrecer simulación. Nunca ejecutes una consulta «arreglar todo» sin límites.
Incluye como precondición una huella del valor actual y detén el proceso si cambió desde el diagnóstico. Así no sobrescribes una actualización legítima llegada desde soporte, la pasarela o el almacén mientras preparabas la reparación.
Aplica a un pedido y verifica
Toma una copia reciente, ejecuta la corrección mínima y añade una nota con evidencia, operador y hora. Limpia solo cachés relacionadas.
Recarga mediante WooCommerce, confirma que las referencias financieras no cambiaron y que no se duplicaron emails, stock o preparación. Procesa un lote acotado únicamente cuando el primer caso haya sido revisado.
Evita la recurrencia
Rastrea la fuente: escritura fallida, extensión incompatible, importación, proceso manual o migración HPOS. Añade validación y logs en ese límite.
El mantenimiento recurrente debe conciliar totales del proveedor, integridad, inventario y tareas fallidas. Una reparación fiable recupera la operación sin borrar la historia que necesitan cliente, contable y equipo de disputas.