Avaluació inicial sense contrasenyes Pressupost abans d’intervenir Un especialista responsable de principi a fi

Copies Restauracio Verificacio

Conciliar comandes WooCommerce després de restaurar un WordPress hackejat: plantilla

Plantilla per conciliar comandes WooCommerce després de restaurar: pagaments, dades recuperables, sis casos ficticis i criteris per revisar la recuperació.

La botiga torna a carregar. Algú respira, algú vol treure el manteniment i algú descobreix que falten comandes. Aquest últim detall té el mal costum d’aparèixer quan ja semblava que tot estava arreglat.

Després de restaurar un WordPress hackejat, conciliar comandes de WooCommerce significa relacionar cada operació amb el pagament, les dades recuperables i el que ja va passar fora de la botiga. No n’hi ha prou que quadri la facturació total ni a posar totes les comandes en «processant».

Aquesta guia ofereix una plantilla de treball, sis casos ficticis i un exercici local original sobre totals enganyosos. Serveix per preparar i revisar una intervenció; no executa importacions, cobraments ni canvis d’estat. Si necessites recuperar operacions recents, demana una avaluació de recuperació urgent de WooCommerce abans de sobreescriure una altra base de dades.

Què resol aquesta plantilla i què correspon al tècnic

La plantilla ordena decisions: quina operació existeix, què falta, quina font sustenta cada dada i qui pot aprovar el pas següent. L’extracció, revisió d’integritat i importació corresponen al procés tècnic acordat. Un inventari comercial no transforma una base compromesa en una font segura.

Si el problema és distingir pèrdua real d’un canvi d’emmagatzematge, comença per la guia sobre comandes desaparegudes després de restaurar una còpia. Aquí partim de l’expedient conservat i construïm el registre amb què negoci i recuperació poden treballar plegats.

Designa un responsable de conciliació i un substitut. Evita que magatzem, suport i desenvolupament mantinguin tres llistes amb criteris diferents. Poden aportar fonts diverses, però cada decisió necessita una referència comuna i una persona autoritzada a resoldre discrepàncies.

Fixa la finestra abans de comptar comandes

Anota la data de la còpia restaurada, el moment de contenció, les fonts conservades i el tall previst. Fes servir una zona horària explícita. Distingeix l’hora de creació d’una comanda de l’hora d’autorització, captura, devolució o enviament.

No dedueixis quantes en falten restant l’últim número de comanda de l’anterior. Conserva referències d’operacions i esdeveniments amb la seva procedència. Si una font només permet consultar una part del període, registra aquest límit; un full aparentment complet pot contenir un interval sense observar.

Mentre s’investiga, acordeu quin sistema mana per a les operacions noves i qui controla els efectes pendents. El procediment de protecció de comandes recents durant una recuperació desenvolupa la conservació i el tall. La plantilla en documenta els resultats sense substituir-los per una importació improvisada.

Camps d’una fitxa de conciliació

Crea una fitxa per operació candidata. Les referències poden apuntar a documents protegits; no copiïs adreces, targetes o càrregues completes de webhooks a un full compartit per comoditat. El responsable ha de poder localitzar l’evidència autoritzada sense multiplicar-ne les còpies.

Fitxa: REC-___ | responsable i data de revisió:
Referència del proveïdor / comanda anterior / recuperada:
Font i data de cada observació / zona horària:
Import i moneda de l'operació:
Estat financer observat / captura / devolució:
Comanda a la còpia restaurada: sí / no / sense verificar
Detall recuperable: articles, quantitats i relacions:
Lliurament, estoc, accessos i missatges ja executats:
Discrepància o dada que encara no es coneix:
Acció proposada / aprovació / dependència:
Prova aïllada i resultat / efectes controlats:
Tancament: evidència / responsable / pendents:

«Sense verificar» i «no existeix» són respostes diferents. Cercar un cop a l’administrador no estableix absència a totes les fonts. Tampoc no converteixis una coincidència d’import en identitat: registra l’identificador del proveïdor i la seva relació comprovada amb la comanda.

Quan canviï un identificador intern, conserva la correspondència anterior/nou i el motiu. El registre ha de permetre seguir una operació durant la recuperació, encara que el sistema net no pugui reutilitzar exactament el mateix identificador.

Sis casos ficticis: mateixa incidència, decisions diferents

Tots els casos de la taula són inventats. Les quantitats, referències i estats serveixen per discutir decisions de revisió, no per ordenar accions automàtiques. Cap fila no autoritza cobrar, retornar diners, enviar mercaderia o modificar producció.

Exemple editorial: decisions proposades, pendents de revisió
Fitxa Evidència financera fictícia Botiga restaurada Comprovació següent
REC-01 120 EUR capturats Comanda i referència coincideixen Revisar lliurament i efectes ja executats
REC-02 80 EUR capturats Falta comanda; hi ha detall posterior protegit Preparar recuperació revisada en còpia aïllada
REC-03 60 EUR autoritzats, sense captura Comanda present Comprovar estat amb el proveïdor; no marcar cobrat
REC-04 90 EUR capturats i 90 EUR retornats La còpia conserva un estat anterior Reconstruir historial de devolució; evitar un altre enviament
REC-05 75 USD capturats Comanda candidata de 75 EUR Bloquejar associació per moneda discrepant
REC-06 45 EUR capturats Falta comanda i no hi ha detall d’articles Mantenir dades desconegudes i avaluar altres fonts

REC-01 pot semblar resolt, però encara cal saber si hi va haver enviament o reducció d’estoc. REC-02 té una font candidata, no permís per restaurar tota la base posterior. REC-06 té diners observats a l’exemple, però no una cistella que puguem inventar.

Per a cada fitxa escriu la pregunta que desbloqueja la feina. «Revisar comanda» és massa ampli. «Confirmar si el transportista va rebre el paquet abans del tall» permet assignar una comprovació concreta i registrar-ne el resultat.

Com documentar REC-02 sense donar-lo per recuperat

Seguim amb la fila fictícia de 80 EUR. Negoci coneix el pagament, però la còpia restaurada no conté la comanda. Una còpia posterior protegida sembla conservar-ne el detall. La primera decisió és avaluar aquesta font; encara no sabem si els registres són íntegres ni si totes les relacions necessàries estan disponibles.

El tècnic ha de deixar constància de l’origen i dels camps que pot recuperar mitjançant el procediment aprovat. Negoci aporta si hi va haver lliurament, reserva de material o missatges anteriors. Si es proposa un identificador nou, la fitxa enllaça totes dues referències i l’operació del proveïdor. L’import coincident per si sol no estableix aquest vincle.

Per a la prova, s’acorden entrades, sortida esperada i efectes que han de continuar bloquejats. L’aprovació posterior ha de citar l’evidència observada i les excepcions, no una frase genèrica d’èxit. Si falta una dada indispensable, la fitxa continua pendent amb responsable i comprovació següent. Aquest desenvolupament de REC-02 continua sent un exemple: no hem extret ni restaurat una comanda real, i no promet que una còpia posterior contingui tot el que cal.

Comprovació pròpia: dues llistes sumen 300 EUR i no són iguals

El 24 d’octubre de 2026 a les 23:30 UTC vam executar un exercici local amb Python, fent servir imports decimals i conjunts d’identificadors. Vam comparar dues llistes sintètiques de tres operacions, sense connectar amb WooCommerce, una passarel·la ni una base de clients.

Llista original fictícia:   DEMO-A 120 | DEMO-B 80 | DEMO-C 100 EUR
Llista restaurada fictícia: DEMO-A 120 | DEMO-B 80 | DEMO-X 100 EUR
Total de cada llista:       300.00 EUR
Referència que falta:       DEMO-C
Referència inesperada:      DEMO-X

El resultat observat va ser igualtat de totals, amb una referència absent i una d’inesperada. En aquest exercici vam canviar expressament la tercera referència per mostrar el límit d’una suma. No vam demostrar frau, recuperació de comandes ni compatibilitat d’importació.

La conseqüència pràctica és revisar identitat i relacions, a més de quantitats. Un total és un control útil; no respon si hi ha les operacions correctes. En una intervenció real també cal contrastar moneda, moviments posteriors i fonts autoritzades, no aplicar aquest petit exemple com a conciliador automàtic.

Pagaments i estats: conserva el que realment s’ha observat

Un nom d’estat de WooCommerce no substitueix l’evidència del proveïdor. La seva documentació d’estats recull diferències i excepcions. Registra l’observació concreta i les notes rellevants abans de proposar un canvi.

Separa autorització i captura, i comprova la configuració de la passarel·la. La documentació de WooPayments descriu aquesta separació per al seu producte; no extrapolïs terminis o comportaments a un altre proveïdor.

Inclou devolucions parcials, disputes i operacions pendents com a branques de revisió pròpies. La taula anterior no pretén cobrir-les totes. Si falta evidència o hi ha estats incompatibles, conserva la discrepància i assigna el contacte següent; canviar una etiqueta perquè quedi verda no recupera informació.

Emmagatzematge i relacions: la comanda no és una fila solta

La documentació oficial de HPOS diferencia taules autoritatives i de suport. Demana al tècnic que identifiqui l’emmagatzematge de cada còpia. La sincronització entre taules no s’ha de tractar com una còpia històrica independent.

A la fitxa, registra si s’han validat articles, quantitats, variacions i relacions necessàries per a aquell negoci. Una botiga amb subscripcions, reserves o descàrregues també necessita revisar aquests sistemes. El contingut mínim recuperable depèn de la comanda real, no de la plantilla.

Evita completar els buits amb el catàleg actual sense comprovar-ho. Un producte pot haver canviat de preu, impost o configuració des de l’operació original. Si una font no conserva la dada, marca-la com a desconeguda i acordeu com investigar la diferència.

Una referència visual per separar resum i detall

Panell ecommerce StockSphere amb resum i taula de comandes dissenyat per Mahmudul Hasan Dip
Referència externa: E-commerce Admin Dashboard UI Design, de Mahmudul Hasan Dip, a Behance. Presentació de StockSphere; no és el nostre programari ni evidència d’una recuperació.

Un resum serveix per localitzar on mirar. La decisió necessita baixar al detall de l’operació. Al teu expedient, mantén tots dos nivells: quantes fitxes continuen obertes i quina evidència falta a cadascuna.

Prova aïllada: verifica efectes, a més de registres

Abans del canvi aprovat, acordeu què es provarà en una còpia protegida. Identifica el conjunt d’operacions, el mapatge previst i els mecanismes per impedir cobraments, correus, enviaments, sincronitzacions o accessos duplicats. Que una pantalla no mostri un botó actiu no demostra que totes les automatitzacions estiguin aturades.

El tècnic ha de documentar quins controls ha aplicat i què queda fora de la prova. Negoci revisa les fitxes i els efectes observats. Una segona execució controlada, quan pertoqui, s’ha d’estudiar expressament per detectar duplicats; no se suposa segura perquè es reutilitzi el mateix arxiu.

Conserva el resultat per operació i els errors pendents. No publiquis una exportació real com a exemple. Les proves posteriors de carretó, checkout, comandes i comptes completen l’acceptació funcional; la conciliació aporta el seguiment dels registres anteriors al tall.

Què ha de lliurar una intervenció de recuperació

Demana inventari de fonts i límits, finestra revisada, correspondències de referències, decisions aprovades, resultat de la prova i relació d’excepcions. Aclareix qui conserva l’evidència, qui pot consultar-la i qui resoldrà les fitxes pendents.

Separa «operació identificada», «dades suficients per recuperar», «recuperació provada» i «acceptada per negoci». Són fites diferents. Una fitxa amb pagament conegut i articles desconeguts no ha de desaparèixer de l’informe perquè el total general quadri.

La reobertura també requereix el tancament tècnic del compromís. Tenir comandes conciliades no acredita que l’accés o el codi siguin fiables. El pla de recuperació de WordPress per al 2027 ajuda a assignar aquestes decisions i els seus responsables abans de la pròxima urgència.

Preparar el pressupost sense enviar dades de clients

Per a una primera avaluació, n’hi ha prou a descriure domini, dates de còpia i restauració, zona horària, volum aproximat i fonts disponibles. Explica si es van continuar acceptant comandes i si hi ha subscripcions, ERP, magatzem o diverses monedes.

Demana que l’abast indiqui conservació, anàlisi, prova aïllada, recuperació i acceptació per separat. La disponibilitat i fiabilitat de les fonts condicionen què es pot recuperar. És més útil confirmar aquests límits abans de triar una importació que descobrir-los quan ja s’ha sobreescrit l’únic registre posterior.

L’objectiu de l’expedient és que cada operació acabi amb una decisió defensable: recuperada i verificada, pendent d’una comprovació identificada o limitada per dades que no existeixen. Així suport i negoci poden continuar amb un registre compartit, en lloc d’una altra ronda de «crec que ja està».

ABANS D’ENVIAR LA SOL·LICITUD

Preguntes freqüents.

Demaneu contrasenyes al formulari?+

No. El formulari públic no demana mai accessos. Les dades segures es demanen només després d’aprovar l’abast i el pressupost.

Qui revisa la incidència?+

La sol·licitud arriba a Jordi Ensenyat, fundador de Code Barcelona i especialista en WordPress amb més de 15 anys d’experiència.

Es canvia res abans del pressupost?+

No. Primer es revisen els símptomes visibles i es defineix l’abast. La intervenció comença després de l’aprovació i amb una via de recuperació preparada.

Treballeu amb webs en anglès i fora d’Espanya?+

Sí. WP Repair atén incidències de WordPress i WooCommerce en català, castellà i anglès mitjançant un servei remot.

Avaluar la meva incidència↗