Il registro di audit di returnEasier è un registro append-only di tutto ciò che accade alle tue richieste: ogni volta che ne viene creata una, viene approvata, viene segnata come ricevuta o viene rimborsata, si aggiunge una riga nuova, e l'app non offre alcun modo di modificarla o cancellarla. Ogni evento viene sigillato con un hash SHA-256 concatenato con il precedente, che puoi confrontare con quelli delle tue esportazioni passate; il PDF della ricevuta di recesso riporta inoltre l'hash della sua richiesta. Quando hai bisogno di fornire prove —a un revisore, all'amministrazione o al tuo consulente— vai su Conformità → Esporta audit e scarichi uno ZIP con tutto lo storico e un file di integrità per verificarlo.
Perché il registro è append-only?
La tabella degli eventi è append-only: si aggiungono solo righe. Per la via normale dell'applicazione, un trigger di PostgreSQL rifiuta gli UPDATE e i DELETE su di essa, e l'app non offre alcun modo di modificare o cancellare un evento.
Su questa base si costruisce la catena di hash:
- Il contenuto di ogni evento (
payload) viene convertito in un JSON canonico (chiavi ordinate, senza ambiguità) e gli viene calcolato uno SHA-256. - Quell'hash viene calcolato includendo l'hash dell'evento precedente (
hash_precedente). Il primo evento di ogni catena è il «genesi». - Se qualcuno modificasse un solo dato del contenuto (
payload) di un evento passato, il suo hash cambierebbe e smetterebbe di combaciare con l'hash_precedentedell'evento successivo: una modifica isolata del contenuto spezza la catena. La data di ogni evento è salvata a parte e non fa parte dell'hash. Per confrontare lo storico con una riscrittura completa, conserva le tue esportazioni precedenti.
Le richieste (return_requests) portano anche il proprio hash e hash precedente, che vengono inclusi nell'esportazione affinché si possano verificare fuori dall'app.
Come esporto il mio storico verificabile?
L'esportazione vive in Conformità → Esporta audit (percorso /app/settings/compliance/export) dentro l'app, nello Shopify Admin.
- Apri Conformità nel menu laterale; l'esportazione è il blocco Esporta audit.
- Indica un intervallo di date: «da» e «a» (formato data). Puoi lasciare entrambi vuoti per esportare tutto il tuo storico. Le date vengono interpretate nel fuso orario del tuo negozio (per impostazione predefinita Europe/Madrid).
- Premi Genera esportazione. A seconda del numero di richieste dell'intervallo, returnEasier fa una di due cose (vedi più avanti).
Download all'istante o via email, a seconda del volume
returnEasier genera lo ZIP in entrambi i casi; ciò che cambia con il volume è se te lo invia anche via email:
| Richieste nell'intervallo | Cosa succede |
|---|---|
| 1 – 100 | Si genera e hai il link di download a schermo. |
| 101 – 1200 | Si genera allo stesso modo: hai il link di download a schermo e in più te lo inviamo via email (se il tuo negozio non ha un'email in Shopify, solo a schermo). |
| Più di 1200 | L'esportazione viene rifiutata: restringi l'intervallo di date. |
In entrambi i casi, il link scade dopo 7 giorni. Se non c'è nessuna richiesta nell'intervallo, l'app te lo dice e non genera nulla.
Il limite rigido è di 1200 richieste per esportazione. Se il tuo storico è più grande, suddividilo in più intervalli di date (per esempio, trimestre per trimestre) ed esporta ciascuno.
Al termine, la schermata ti mostra il conteggio di richieste, eventi e PDF, se la catena di eventi è «Verificata» e quanti PDF non erano disponibili. Nella stessa pagina puoi generare il DPA.
Cosa c'è dentro lo ZIP?
Il file si chiama returneasier-auditoria-<tuo-negozio>-<data>.zip e contiene:
LEGGIMI.txt— guida in linguaggio chiaro: cos'è ogni file e come verificare l'integrità.solicitudes.csv— una riga per richiesta, con colonne comepublic_id,tipo,estado,creada_en_utc,resuelta_en_utc,pedido,cliente_email,cliente_nombre,importe,moneda,motivo,resolucion_preferida,notas_cliente,hash,hash_anteriorerefund_id.eventos.csv— il registro append-only completo:public_id,return_request_id,evento,actor,actor_id,fecha_utc,hash,hash_anteriorepayload_json.pdfs/— i PDF di ricevuta di recesso di ciascun recesso, uno per richiesta.INTEGRITY.json— il file di integrità: algoritmo (SHA-256), conteggi, l'hash di ogni file dello ZIP e la verifica di ogni catena di eventi.
Come verifico l'integrità dell'esportazione?
L'INTEGRITY.json è il pezzo chiave per verificare che i file dello ZIP non siano cambiati da quando è stata generata l'esportazione —a patto di confrontarlo con una copia del manifest conservata a parte, perché viaggia senza firma dentro lo stesso ZIP—, e riporta il risultato del ricalcolo della catena di eventi di ogni richiesta:
- Contiene l'hash SHA-256 di ogni file dello ZIP. Ricalcola l'hash di, per esempio,
eventos.csvcon qualsiasi strumento standard e confrontalo con quello indicato lì. - Include la verifica di ogni catena di eventi: per ciascuna richiesta indica se la sua catena è
okobroken(nella schermata dell'app: «Verificata» o «N catena/e con problemi») e, se del caso, il motivo (catena biforcata, ciclo, hash che non si ricostruisce…). - Se qualche PDF non si è potuto recuperare (per esempio, perché è stato cancellato per una richiesta GDPR, o perché la ricevuta di un recesso non è mai stata generata), resta annotato nell'elenco dei PDF non disponibili con il suo motivo, anziché far fallire l'intera esportazione.
L'INTEGRITY.json stesso non può contenere il proprio hash, quindi è l'unico file che non si autoverifica; tutto il resto sì.
Relazione con altre funzioni
Il registro di audit è la base dei modelli legali e del PDF di ricevuta di recesso (vedi «Cosa contiene il PDF di ricevuta del recesso?»): ogni conferma di recesso che viene inviata al cliente resta ancorata alla catena di hash. Per capire quali email generano quegli eventi, guarda «Quali email invia returnEasier e a chi?». E prima di disinstallare o annullare, conviene esportare lo storico: lo racconta «Disinstallare o annullare returnEasier».