El Libro de Reclamaciones Virtual no es solo un formulario de contacto más; en Perú, es una exigencia legal estricta regulada por el Código de Protección y Defensa del Consumidor (Ley N° 29571) y supervisada por INDECOPI. Desde una perspectiva de ingeniería de software, su implementación requiere una arquitectura de datos precisa, generación de comprobantes inmutables y notificaciones automatizadas.
A continuación, se detalla la normativa técnica y una propuesta arquitectónica para su desarrollo desde cero.
¿Qué páginas web están obligadas a tenerlo?
La regla general de INDECOPI establece que cualquier proveedor que ofrezca bienes o servicios a consumidores finales (B2C) a través de medios digitales debe contar con un Libro de Reclamaciones Virtual. Esto incluye:
- Plataformas de Comercio Electrónico (E-commerce): Cualquier tienda en línea con un carrito de compras que procese transacciones para productos físicos (ej. venta de regalos, golosinas, repuestos) debe tener el libro accesible.
- Directorios y Portales de Servicios Pagos: Si un portal de noticias o directorio industrial comercializa suscripciones, espacios publicitarios o registros premium directamente a usuarios, está sujeto a la norma.
- Servicios Digitales Profesionales: Consultorías, agencias y plataformas educativas que facturen directamente al consumidor.
Excepción: Los portales puramente informativos (como un blog o una web de noticias que no comercializa nada directamente en la plataforma) no están obligados legalmente, aunque se recomienda tener un canal de contacto.
Requisitos de Interfaz (UI/UX)
- Visibilidad: El enlace o botón debe estar en la página de inicio (generalmente en el footer o en un panel flotante) y debe incluir el logotipo oficial del Libro de Reclamaciones establecido por INDECOPI.
- Diferenciación: El formulario debe obligar al usuario a elegir claramente entre un Reclamo (inconformidad relacionada directamente con los bienes adquiridos o servicios prestados) y una Queja (malestar o descontento respecto a la atención al público, que no involucra directamente el producto).
Lógica de Backend y Flujo de Trabajo
Si se desarrolla una solución a medida utilizando Vanilla PHP o un framework ligero, el flujo del servidor debe garantizar la trazabilidad y la notificación inmediata.
- Generación de Código Correlativo: La ley exige un código único y correlativo para cada registro. Una buena práctica es concatenar el año actual con un número secuencial rellenado con ceros (ej. 000015-2026). Esta lógica debe ser transaccional para evitar duplicidades si dos usuarios envían un formulario en el mismo milisegundo.
- Acuse de Recibo Automatizado: Al procesar el POST, el backend debe enviar inmediatamente un correo electrónico al consumidor con una copia exacta de su hoja de reclamación, idealmente en formato PDF (utilizando librerías como FPDF o mPDF) o como un correo HTML inmutable.
- Tiempos de Respuesta: La normativa actualizda exige que los reclamos se respondan en un plazo máximo de 15 días hábiles. A nivel de sistema, es recomendable implementar un cron job que envíe alertas internas al equipo de atención al cliente a los 7 y 12 días si el ticket sigue abierto.
Propuesta de Esquema de Base de Datos (MySQL)
Para cumplir con todos los campos obligatorios del Anexo de INDECOPI, el esquema relacional en MySQL debe ser estructurado de la siguiente manera:
| Columna | Tipo de Dato (MySQL) | Descripción y Restricciones |
| id_reclamacion | INT AUTO_INCREMENT | Llave primaria interna. |
| codigo_correlativo | VARCHAR(20) UNIQUE | Código oficial visible (ej. 00001-2026). |
| fecha_registro | DATETIME | Timestamp exacto de la recepción. |
| tipo_documento | ENUM(‘DNI’,’CE’,’Pasaporte’) | Documento de identidad del consumidor. |
| numero_documento | VARCHAR(15) | Número de identidad validado. |
| nombre_completo | VARCHAR(150) | Nombre o Razón Social del consumidor. |
| email_contacto | VARCHAR(100) | Obligatorio para el acuse de recibo. |
| telefono_contacto | VARCHAR(20) | Teléfono del consumidor. |
| menor_edad | TINYINT(1) | Booleano (1 si es menor, requiere datos del apoderado). |
| apoderado_nombre | VARCHAR(150) NULL | Obligatorio si menor_edad es 1. |
| bien_contratado | ENUM(‘Producto’,’Servicio’) | Definición de lo que se comercializó. |
| monto_reclamado | DECIMAL(10,2) NULL | Valor de la transacción en Soles. |
| descripcion_bien | TEXT | Qué compró exactamente (ej. Pack de fiesta). |
| tipo_incidencia | ENUM(‘Reclamo’,’Queja’) | Clasificación legal. |
| detalle_incidencia | TEXT | Relato del consumidor. |
| pedido_consumidor | TEXT | Qué exige el consumidor (ej. Devolución). |
| estado_ticket | ENUM(‘Abierto’,’Resuelto’) | Control interno del sistema. |
| fecha_respuesta | DATETIME NULL | Cuándo se cerró el caso. |
Consideraciones Técnicas y de Seguridad
- Sanitización de Entradas: Al ser un formulario público extenso, es un vector clásico para inyecciones SQL y ataques XSS (Cross-Site Scripting). En PHP, es imperativo procesar todos los campos de texto utilizando consultas preparadas (Prepared Statements con PDO) y limpiar las salidas HTML (htmlspecialchars).
- Protección de Datos Personales (Ley N° 29733): El formulario captura información sensible de ciudadanos peruanos. Debes incluir una casilla de verificación (checkbox) obligatoria y no premarcada donde el usuario acepte la «Política de Privacidad y Tratamiento de Datos Personales».
- Almacenamiento y Retención: INDECOPI requiere que las hojas de reclamaciones se conserven por un periodo mínimo de dos años. La base de datos debe contemplar este archivo histórico, y es prudente realizar respaldos regulares de esta tabla específica.