Conciliar pedidos WooCommerce tras restaurar un WordPress hackeado: plantilla

La tienda vuelve a cargar. Alguien respira, alguien quiere quitar el mantenimiento y alguien descubre que faltan pedidos. Ese último detalle tiene la mala costumbre de aparecer cuando ya parecía que todo estaba arreglado.

Después de restaurar un WordPress hackeado, conciliar pedidos de WooCommerce significa relacionar cada operación con su pago, sus datos recuperables y lo que ya ocurrió fuera de la tienda. No basta con que cuadre la facturación total ni con poner todos los pedidos en «procesando».

Esta guía ofrece una plantilla de trabajo, seis casos ficticios y un ejercicio local original sobre totales engañosos. Sirve para preparar y revisar una intervención; no ejecuta importaciones, cobros ni cambios de estado. Si necesitas recuperar operaciones recientes, solicita una evaluación de recuperación urgente de WooCommerce antes de sobrescribir otra base de datos.

Qué resuelve esta plantilla y qué corresponde al técnico

La plantilla ordena decisiones: qué operación existe, qué falta, qué fuente respalda cada dato y quién puede aprobar el siguiente paso. La extracción, revisión de integridad e importación corresponden al proceso técnico acordado. Un inventario comercial no convierte una base comprometida en una fuente segura.

Si el problema es distinguir pérdida real de un cambio de almacenamiento, empieza por la guía sobre pedidos desaparecidos después de restaurar una copia. Aquí partimos del expediente preservado y construimos el registro con el que negocio y recuperación pueden trabajar juntos.

Designa un responsable de conciliación y un sustituto. Evita que almacén, soporte y desarrollo mantengan tres listas con criterios distintos. Pueden aportar fuentes diferentes, pero cada decisión necesita una referencia común y una persona autorizada a resolver discrepancias.

Fija la ventana antes de contar pedidos

Anota la fecha de la copia restaurada, el momento de contención, las fuentes conservadas y el corte previsto. Usa una zona horaria explícita. Distingue la hora en que se creó un pedido de la hora de autorización, captura, devolución o envío.

No deduzcas cuántos faltan restando el último número de pedido al anterior. Guarda referencias de operaciones y eventos, con su procedencia. Si una fuente permite consultar solo parte del periodo, registra ese límite; una hoja completa en apariencia puede contener un intervalo sin observar.

Mientras se investiga, acuerda qué sistema manda para nuevas operaciones y quién controla los efectos pendientes. El procedimiento de protección de pedidos recientes durante una recuperación desarrolla la conservación y el corte. La plantilla documenta sus resultados, sin sustituirlos por una importación improvisada.

Campos de una ficha de conciliación

Crea una ficha por operación candidata. Las referencias pueden apuntar a documentos protegidos; no copies direcciones, tarjetas o cargas completas de webhooks a una hoja compartida por comodidad. El responsable debe poder localizar la evidencia autorizada sin multiplicar sus copias.

Ficha: REC-___ | responsable y fecha de revisión:
Referencia del proveedor / pedido anterior / pedido recuperado:
Fuente y fecha de cada observación / zona horaria:
Importe y moneda de la operación:
Estado financiero observado / captura / devolución:
Pedido presente en la copia restaurada: sí / no / sin verificar
Detalle recuperable: artículos, cantidades y relaciones:
Entrega, stock, accesos y mensajes ya ejecutados:
Discrepancia o dato que sigue sin conocerse:
Acción propuesta / aprobación / dependencia:
Prueba aislada y resultado / efectos controlados:
Cierre: evidencia / responsable / pendientes:

«Sin verificar» y «no existe» son respuestas distintas. Buscar una vez en el administrador no establece ausencia en todas las fuentes. Tampoco conviertas una coincidencia de importe en identidad: registra el identificador del proveedor y su relación comprobada con el pedido.

Cuando cambie un identificador interno, conserva la correspondencia anterior/nuevo y el motivo. El registro debe permitir seguir una operación a través de la recuperación, aunque el sistema limpio no pueda reutilizar exactamente el mismo identificador.

Seis casos ficticios: misma incidencia, decisiones diferentes

Todos los casos de la tabla son inventados. Las cantidades, referencias y estados sirven para discutir decisiones de revisión, no para ordenar acciones automáticas. Ninguna fila autoriza cobrar, devolver, enviar mercancía o modificar producción.

REC-01 puede parecer resuelto, pero aún falta saber si hubo envío o reducción de stock. REC-02 tiene una fuente candidata, no permiso para restaurar toda la base posterior. REC-06 tiene dinero observado en el ejemplo, pero no una cesta que podamos inventar.

Para cada fila escribe la pregunta que desbloquea el trabajo. «Revisar pedido» es demasiado amplio. «Confirmar si el transportista recibió el paquete antes del corte» permite asignar una comprobación concreta y registrar su resultado.

Cómo documentar REC-02 sin darlo por recuperado

Sigamos con la fila ficticia de 80 EUR. Negocio conoce el pago, pero la copia restaurada no contiene el pedido. Una copia posterior protegida parece conservar el detalle. La primera decisión es evaluar esa fuente; todavía no sabemos si sus registros son íntegros ni si todas las relaciones necesarias están disponibles.

El técnico debe dejar constancia del origen y de los campos que puede recuperar mediante el procedimiento aprobado. Negocio aporta si hubo entrega, reserva de material o mensajes anteriores. Si se propone un identificador nuevo, la ficha enlaza ambas referencias y la operación del proveedor. El importe coincidente por sí solo no establece ese vínculo.

Para la prueba, se acuerdan entradas, salida esperada y efectos que deben permanecer bloqueados. La aprobación posterior debe citar la evidencia observada y las excepciones, no una frase genérica de éxito. Si falta un dato indispensable, la ficha sigue pendiente con responsable y siguiente comprobación. Este desarrollo de REC-02 continúa siendo un ejemplo: no hemos extraído ni restaurado un pedido real, y no promete que una copia posterior contenga todo lo necesario.

Comprobación propia: dos listas suman 300 EUR y no son iguales

El 24 de octubre de 2026 a las 23:30 UTC ejecutamos un ejercicio local con Python, usando importes decimales y conjuntos de identificadores. Comparamos dos listas sintéticas de tres operaciones, sin conectar con WooCommerce, una pasarela ni una base de clientes.

Lista original ficticia:   DEMO-A 120 | DEMO-B 80 | DEMO-C 100 EUR
Lista restaurada ficticia: DEMO-A 120 | DEMO-B 80 | DEMO-X 100 EUR
Total de cada lista:       300.00 EUR
Referencia que falta:      DEMO-C
Referencia inesperada:     DEMO-X

El resultado observado fue igualdad de totales, con una referencia ausente y otra inesperada. En este ejercicio cambiamos expresamente la tercera referencia para mostrar el límite de una suma. No demostramos fraude, recuperación de pedidos ni compatibilidad de importación.

La consecuencia práctica es revisar identidad y relaciones además de cantidades. Un total es un control útil; no responde si están las operaciones correctas. En una intervención real hay que contrastar también moneda, movimientos posteriores y fuentes autorizadas, no aplicar este pequeño ejemplo como conciliador automático.

Pagos y estados: conserva lo que realmente se observó

Un nombre de estado de WooCommerce no sustituye la evidencia del proveedor. Su documentación de estados recoge diferencias y excepciones. Registra la observación concreta y las notas relevantes antes de proponer un cambio.

Separa autorización y captura, y comprueba la configuración de la pasarela. La documentación de WooPayments describe esa separación para su producto; no extrapoles plazos o comportamientos a otro proveedor.

Incluye devoluciones parciales, disputas y operaciones pendientes como ramas de revisión propias. La tabla anterior no pretende cubrirlas todas. Si falta evidencia o hay estados incompatibles, conserva la discrepancia y asigna el siguiente contacto; cambiar una etiqueta para que quede verde no recupera información.

Almacenamiento y relaciones: el pedido no es una fila suelta

La documentación oficial de HPOS diferencia tablas autoritativas y de respaldo. Pide al técnico que identifique el almacenamiento de cada copia. La sincronización entre tablas no debe tratarse como una copia histórica independiente.

En la ficha, registra si se han validado artículos, cantidades, variaciones y relaciones necesarias para ese negocio. Una tienda con suscripciones, reservas o descargas necesita revisar también esos sistemas. El contenido mínimo recuperable depende del pedido real, no de la plantilla.

Evita completar los huecos con el catálogo actual sin comprobarlo. Un producto puede haber cambiado de precio, impuesto o configuración desde la operación original. Si una fuente no conserva el dato, márcalo como desconocido y acuerda cómo investigar la diferencia.

Una referencia visual para separar resumen y detalle

Un resumen sirve para localizar dónde mirar. La decisión necesita bajar al detalle de la operación. En tu expediente, mantén ambos niveles: cuántas fichas quedan abiertas y qué evidencia falta en cada una.

Prueba aislada: verifica efectos, además de registros

Antes del cambio aprobado, acuerda qué se probará en una copia protegida. Identifica el conjunto de operaciones, el mapeo previsto y los mecanismos para impedir cobros, correos, envíos, sincronizaciones o accesos duplicados. Que una pantalla no muestre un botón activo no demuestra que todas las automatizaciones estén detenidas.

El técnico debe documentar qué controles aplicó y qué queda fuera de la prueba. Negocio revisa las fichas y los efectos observados. Una segunda ejecución controlada, cuando proceda, debe estudiarse expresamente para detectar duplicados; no se supone segura por reutilizar el mismo archivo.

Conserva el resultado por operación y los fallos pendientes. No publiques una exportación real como ejemplo. Las pruebas posteriores de carrito, checkout, pedidos y cuentas completan la aceptación funcional; la conciliación aporta el seguimiento de los registros anteriores al corte.

Qué debe entregar una intervención de recuperación

Pide inventario de fuentes y límites, ventana revisada, correspondencias de referencias, decisiones aprobadas, resultado de la prueba y relación de excepciones. Aclara quién conserva la evidencia, quién puede consultarla y quién resolverá lo pendiente.

Separa «operación identificada», «datos suficientes para recuperar», «recuperación probada» y «aceptada por negocio». Son hitos distintos. Una ficha con pago conocido y artículos desconocidos no debe desaparecer del informe porque el total general cuadre.

La reapertura requiere además el cierre técnico del compromiso. Tener pedidos conciliados no acredita que el acceso o el código sean fiables. El plan de recuperación de WordPress para 2027 ayuda a asignar esas decisiones y sus responsables antes de la próxima urgencia.

Preparar el presupuesto sin enviar datos de clientes

Para una primera evaluación, basta describir dominio, fechas de copia y restauración, zona horaria, volumen aproximado y fuentes disponibles. Explica si se siguieron aceptando pedidos y si existen suscripciones, ERP, almacén o varias monedas.

Pide que el alcance indique conservación, análisis, prueba aislada, recuperación y aceptación por separado. La disponibilidad y fiabilidad de las fuentes condicionan qué puede recuperarse. Es más útil confirmar esos límites antes de elegir una importación que descubrirlos cuando ya se ha sobrescrito el único registro posterior.

El objetivo del expediente es que cada operación termine con una decisión defendible: recuperada y verificada, pendiente de una comprobación identificada o limitada por datos que no existen. Así soporte y negocio pueden continuar el trabajo con un registro compartido, en lugar de otra ronda de «creo que ya está».