Historial de condiciones generales y prueba de aceptación: documentación

Instalación

Instale el módulo desde Módulos > Gestor de módulos > Subir un módulo enviando el archivo ZIP, o copie la carpeta dftermsversion en el directorio /modules/ de su tienda y haga clic en Instalar.

Al instalarse, el módulo crea sus tablas, añade dos pestañas en el menú Pedidos (Versiones de condiciones y Registro de aceptaciones) e importa el contenido de su página CMS de condiciones como borrador. Sus clientes todavía no ven nada: ninguna versión está vigente hasta que publique una.

Publicar su primera versión

Abra Pedidos > Versiones de condiciones. El borrador importado aparece con el estado Borrador. Haga clic en él para leerlo en cada idioma y luego en Modificar si es necesario.

Campos de una versión

• Número de versión: la etiqueta mostrada a los clientes, por ejemplo 2026-10 o 4.2. Debe ser única.
• Título y texto: por idioma. Un idioma vacío toma el texto del idioma predeterminado al publicar.
• Vigente a partir del: déjelo vacío para aplicar la versión en cuanto se publique. Una fecha futura programa el cambio. Una fecha pasada añade una versión anterior al historial (ver más abajo).
• Resumen de cambios: se muestra en el historial público.

Después haga clic en Publicar. La versión queda bloqueada: su texto, su huella SHA-256 y sus PDF, generados en cada idioma, ya no pueden cambiar. Si el sellado de tiempo está activo, el módulo solicita de inmediato un sello a la autoridad configurada.

Modificar sus condiciones

Desde una versión publicada, haga clic en Crear una nueva versión a partir de esta. Se crea un borrador con el mismo texto. Modifíquelo, rellene el resumen de cambios, elija la fecha de entrada en vigor y publíquelo.

Comparar dos versiones

En la vista de una versión, el bloque Comparar propone por defecto la versión anterior, o la versión vigente si está en un borrador. Haga clic en Ver los cambios: los párrafos modificados, añadidos y eliminados aparecen resaltados, palabra a palabra en los modificados, y los párrafos sin cambios se pliegan. Cambie de idioma con los botones de arriba a la derecha.

Programar un cambio

Una versión publicada con fecha futura tiene el estado Programada. Pasa a ser la versión vigente automáticamente en esa fecha, sin tarea cron. La página de configuración muestra la próxima versión programada.

Lo que ve el cliente

• En el pago: encima de los métodos de pago, un aviso indica la versión vigente, su fecha y un enlace a su PDF, además de un enlace a las versiones anteriores si el historial público está activo.
• En el email de confirmación: el PDF de la versión aceptada se adjunta al email order_conf.
• En su cuenta: el detalle de cada pedido recuerda la versión aceptada con un enlace de descarga.
• En la factura: una mención de la versión y su huella, si la opción está activa.

Lo que el módulo registra en cada pedido

Cuando se muestra el paso de pago, el módulo anota la versión mostrada al cliente, con su dirección IP, su navegador y la hora. Al validar el pedido registra la versión mostrada, la huella SHA-256 del texto en el idioma del cliente y esta información de visualización.

Si no se registró ninguna visualización, por ejemplo con un checkout que no llama al hook displayPaymentTop, el módulo registra la versión vigente en la fecha del pedido con el método «Validación del pedido». Un pedido creado en el back office se registra con el método «Back office».

Consultar la prueba de un pedido

En la ficha del pedido del back office, la tarjeta Condiciones generales aceptadas muestra la versión, las fechas, la IP, el método de registro, el control de integridad del texto y la posición del pedido en el registro. Tres botones:

• Expediente de prueba (ZIP): el archivo que hay que enviar en caso de litigio (detalle más abajo).
• Certificado de aceptación (PDF): un documento con todos los datos registrados, seguido del texto completo aceptado.
• Condiciones aceptadas (PDF): el PDF de la versión, tal como se adjuntó al email.

Contenido del expediente de prueba

• 01-acceptance-certificate.pdf: el certificado de aceptación.
• 02-...pdf: el PDF de la versión aceptada.
• 03-accepted-text.txt: el texto fuente exacto. Su SHA-256 es igual a la huella registrada con el pedido.
• 04-version-timestamp/: el manifiesto de la versión y su sello de tiempo .tsr.
• 05-register/: la entrada del pedido en el registro, un extracto de la cadena (solo identificadores y huellas, sin datos de otros clientes) y el sellado que la cubre.
• README.txt: la explicación de cada archivo y los comandos de verificación, en el idioma del empleado.

El registro sellado

Cada aceptación contiene la huella de su contenido y la huella de la aceptación anterior. Modificar, insertar o eliminar un registro a posteriori rompe esta cadena. En Pedidos > Registro de aceptaciones, el botón Verificar el registro recalcula toda la cadena e indica la primera entrada alterada, si la hay.

Sellados

Un sellado hace que la autoridad feche la huella de la última entrada del registro. Prueba que todo el registro hasta esa entrada existía en esa fecha y detecta también la eliminación de las últimas entradas. Haga clic en Sellar ahora o programe una vez al día, en una tarea cron, la URL que aparece en el bloque Sellado automático:

0 3 * * * curl -s "https://su-tienda.es/module/dftermsversion/cron?token=..." > /dev/null

La URL solo sella el registro si se han registrado entradas nuevas desde el último sellado.

Sellado de tiempo por un tercero

El sellado de tiempo RFC 3161 hace que una autoridad independiente firme una huella junto con la fecha. El módulo lo usa para cada versión publicada (sobre un manifiesto con la huella del texto en cada idioma) y para los sellados del registro.

Por defecto el módulo usa http://timestamp.digicert.com, gratuito y sin cuenta. Puede indicar otra autoridad en la configuración, por ejemplo https://freetsa.org/tsr o una autoridad cualificada eIDAS. El servidor de la tienda debe poder conectar con la autoridad.

Si la autoridad no responde al publicar, la versión se publica de todos modos. El error aparece en la vista de la versión, con un botón Sellar ahora para reintentarlo.

Tienda existente: historial y pedidos anteriores

Para cubrir los pedidos realizados antes de la instalación:

1. Publique primero la versión actual de sus condiciones.
2. Cree una versión por cada versión antigua de sus condiciones, con su fecha real de entrada en vigor en el pasado, y publíquela. El módulo solo rechaza una fecha pasada si pedidos ya vinculados a otra versión caen en ese periodo.
3. En Pedidos > Registro de aceptaciones, el bloque Pedidos anteriores indica cuántos pedidos no están vinculados a ninguna versión. Haga clic en Vincular estos pedidos: el proceso se hace por lotes con una barra de progreso.

Estos pedidos reciben la versión vigente en su fecha y quedan marcados como Vinculada a posteriori, sin IP ni rastro de visualización. El módulo no afirma lo que no ha constatado: estas vinculaciones indican la versión aplicable, no prueban una visualización.

Ajustes del módulo

• Adjuntar el PDF a los emails y Plantillas de email: order_conf por defecto, puede añadir por ejemplo payment o bankwire.
• Mostrar la versión en el pago: el aviso encima de los métodos de pago. Si se desactiva, el módulo sigue registrando la versión mostrada.
• Mención en las facturas.
• Historial público de versiones: una página con las versiones publicadas y sus PDF.
• Actualizar la página CMS automáticamente: cuando una versión entra en vigor, su texto sustituye el de la página CMS elegida, para que la casilla del proceso de compra enlace siempre con la versión correcta. El botón Actualizar la página CMS ahora fuerza la sincronización.
• Anonimizar las direcciones IP: solo guarda la parte de red de la IP.
• Sellado de tiempo por un tercero y Autoridad de sellado de tiempo.
• Solicitudes de supresión RGPD: ver más abajo.
• Eliminar todos los datos al desinstalar: desactivado por defecto. Manténgalo desactivado, sus versiones y su registro son sus pruebas.

RGPD

El módulo se conecta al módulo RGPD oficial de PrestaShop (psgdpr). Las aceptaciones de un cliente se incluyen en la exportación de sus datos. Para las solicitudes de supresión hay dos opciones:

• Conservar la prueba (por defecto): los registros se conservan, algo que permite el artículo 17.3.e del RGPD para formular, ejercer o defender reclamaciones. Menciónelo en su política de privacidad.
• Borrar la dirección IP y el navegador: estos campos se vacían. El registro sigue siendo verificable y una huella calculada al borrar protege los demás campos, pero la prueba es más débil para ese cliente.

Solución de problemas

El aviso no aparece en el pago

Compruebe que hay una versión vigente y que la opción de visualización está activa. Si su tema o su módulo de checkout no llama al hook displayPaymentTop, los pedidos se registran con la versión vigente en la fecha del pedido.

El PDF no se adjunta al email

Compruebe la opción Adjuntar el PDF a los emails y el nombre exacto de la plantilla. Algunos módulos de pago envían su propio email de confirmación con otro nombre de plantilla: añádalo a la lista.

El sellado de tiempo falla

El mensaje de error indica la causa. Lo más habitual es que el alojamiento bloquee las conexiones salientes. Pruebe otra autoridad o pida a su proveedor que abra el acceso a la dirección de la autoridad. Se recomienda la extensión PHP cURL.

La verificación del registro indica una alteración

El mensaje indica la entrada afectada y el tipo de problema: contenido modificado, entrada insertada o eliminada antes que ella, o entrada sellada desaparecida. Restaure la tabla dftv_acceptance desde una copia de seguridad anterior a la alteración y vuelva a lanzar la verificación.

Compatibilidad

• PrestaShop 8.0 a 9.x, el mismo ZIP cubre las dos ramas.
• Multitienda y multilingüe.
• PDF generados con el TCPDF integrado en PrestaShop, extensión PHP zip necesaria para el expediente de prueba.
• Arquitectura ModuleAdminController, sin dependencias de Composer.
• Interfaz disponible en español, inglés, francés, alemán, italiano, neerlandés, polaco y portugués.