El audit log de returnEasier es un registro de solo añadir de todo lo que ocurre con tus solicitudes: cada vez que se crea una, se aprueba, se marca recibida o se reembolsa, se añade una fila nueva, y la app no ofrece ninguna forma de editarla ni borrarla. Cada evento se sella con un hash SHA-256 encadenado con el anterior, que puedes contrastar con los de tus exportaciones anteriores; el PDF del acuse lleva además el hash de su solicitud. Cuando necesitas entregar pruebas —a un auditor, a la administración o a tu asesor— vas a Cumplimiento → Exportar auditoría y descargas un ZIP con todo el histórico y un fichero de integridad para verificarlo.
¿Por qué el registro es de solo añadir?
La tabla de eventos es append-only: solo se añaden filas. Por la vía normal de la aplicación, un trigger de PostgreSQL rechaza los UPDATE y DELETE sobre ella, y la app no ofrece ninguna forma de editar ni borrar un evento.
Sobre esa base se construye la cadena de hashes:
- El contenido de cada evento (
payload) se convierte a un JSON canónico (claves ordenadas, sin ambigüedad) y se le calcula un SHA-256. - Ese hash se calcula incluyendo el hash del evento anterior (
hash_anterior). El primer evento de cada cadena es el «génesis». - Si alguien cambiara un solo dato del contenido (
payload) de un evento pasado, su hash cambiaría y dejaría de cuadrar con elhash_anteriordel evento siguiente: una modificación aislada del contenido rompe la cadena. La fecha de cada evento se guarda aparte y no forma parte del hash. Para contrastar el histórico frente a una reescritura completa, conserva tus exportaciones anteriores.
Las solicitudes (return_requests) llevan también su propio hash y hash anterior, que se incluyen en la exportación para que se puedan verificar fuera de la app.
¿Cómo exporto mi histórico auditable?
La exportación vive en Cumplimiento → Exportar auditoría (ruta /app/settings/compliance/export) dentro de la app, en el Shopify Admin.
- Abre Cumplimiento en el menú lateral; la exportación es el bloque Exportar auditoría.
- Indica un rango de fechas: «desde» y «hasta» (formato fecha). Puedes dejar ambos vacíos para exportar todo tu histórico. Las fechas se interpretan en la zona horaria de tu tienda (por defecto Europe/Madrid).
- Pulsa Generar exportación. Según el número de solicitudes del rango, returnEasier hace una de dos cosas (ver más abajo).
Descarga al momento o por email, según el volumen
returnEasier genera el ZIP en los dos casos; lo que cambia con el volumen es si además te lo envía por email:
| Solicitudes en el rango | Qué ocurre |
|---|---|
| 1 – 100 | Se genera y tienes el enlace de descarga en pantalla. |
| 101 – 1200 | Se genera igual: tienes el enlace de descarga en pantalla y además te lo enviamos por email (si tu tienda no tiene correo en Shopify, solo en pantalla). |
| Más de 1200 | La exportación se rechaza: acota el rango de fechas. |
En los dos casos, el enlace caduca a los 7 días. Si no hay ninguna solicitud en el rango, la app te lo dice y no genera nada.
El límite duro es de 1200 solicitudes por exportación. Si tu histórico es mayor, divídelo en varios rangos de fechas (por ejemplo, trimestre a trimestre) y exporta cada uno.
Al terminar, la pantalla te muestra el recuento de solicitudes, eventos y PDF, si la cadena de eventos está «Verificada» y cuántos PDF no estaban disponibles. En la misma página puedes generar el DPA.
¿Qué hay dentro del ZIP?
El archivo se llama returneasier-auditoria-<tu-tienda>-<fecha>.zip y contiene:
LEEME.txt— guía en lenguaje claro: qué es cada fichero y cómo verificar la integridad.solicitudes.csv— una fila por solicitud, con columnas comopublic_id,tipo,estado,creada_en_utc,resuelta_en_utc,pedido,cliente_email,cliente_nombre,importe,moneda,motivo,resolucion_preferida,notas_cliente,hash,hash_anterioryrefund_id.eventos.csv— el registro append-only completo:public_id,return_request_id,evento,actor,actor_id,fecha_utc,hash,hash_anteriorypayload_json.pdfs/— los PDF de acuse de recibo de cada desistimiento, uno por solicitud.INTEGRITY.json— el fichero de integridad: algoritmo (SHA-256), recuentos, el hash de cada fichero del ZIP y la verificación de cada cadena de eventos.
¿Cómo verifico la integridad de la exportación?
El INTEGRITY.json es la pieza clave para comprobar que los ficheros del ZIP no han cambiado desde que se generó la exportación —siempre que lo contrastes con una copia del manifiesto que guardes aparte, porque viaja sin firma dentro del mismo ZIP—, y trae el resultado de recalcular la cadena de eventos de cada solicitud:
- Trae el hash SHA-256 de cada fichero del ZIP. Recalcula el hash de, por ejemplo,
eventos.csvcon cualquier herramienta estándar y compáralo con el que figura ahí. - Incluye la verificación de cada cadena de eventos: por cada solicitud indica si su cadena está
okobroken(en la pantalla de la app: «Verificada» o «N cadena(s) con problemas») y, en su caso, el motivo (cadena bifurcada, ciclo, hash que no recompone…). - Si algún PDF no se pudo recuperar (por ejemplo, porque se borró por una solicitud RGPD, o porque el acuse de un desistimiento nunca llegó a generarse), queda anotado en la lista de PDF no disponibles con su motivo, en lugar de fallar la exportación entera.
El propio INTEGRITY.json no puede contener su propio hash, así que es el único fichero que no se autocomprueba; todo lo demás sí.
Relación con otras funciones
El audit log es la base de las plantillas legales y del PDF de acuse de recibo (ver «El PDF de acuse de recibo»): cada confirmación de desistimiento que se envía al cliente queda anclada a la cadena de hashes. Para entender qué emails generan esos eventos, mira «Los emails que envía returnEasier». Y antes de desinstalar o cancelar, conviene exportar el histórico: lo cuenta «Desinstalar o cancelar returnEasier».