Automatización del parte de viajeros: guía del RD 933/2021

La automatización del parte de viajeros falla casi siempre en el mismo sitio: no en el envío, sino en lo que pasa antes. Un formulario que no pregunta el parentesco de un menor. Un pago que vive en otro sistema. Una reserva hecha a las nueve de la noche para entrar a las once. El Real Decreto 933/2021 exige un registro documental completo de cada estancia y una comunicación rápida de esos datos, y cualquier hueco en el flujo acaba saliendo en una inspección.

Aquí tienes qué datos pide la norma, cómo se cuenta el plazo, qué infracciones prevé y cómo encadenar cada paso para que ninguna estancia se quede sin comunicar. Cada punto legal remite a su artículo en el BOE; donde la norma no dice algo, lo indicamos.

¿A quién obliga el RD 933/2021?

Son sujetos obligados las personas físicas o jurídicas que desarrollen o intermedien en las actividades de hospedaje y de alquiler de vehículos a motor sin conductor (art. 2.3). Las segundas quedan sujetas al mismo deber de registro documental que el hospedaje (art. 2.2), así que el decreto no es una norma pensada solo para hoteles.

Para un gestor de alquiler vacacional, la consecuencia práctica es directa: si alojas a viajeros, o intermedias en ese alojamiento, el deber es tuyo. Da igual que tengas un apartamento o doscientos.

Delegar el trabajo no traslada la responsabilidad

La responsabilidad por las infracciones recae directamente en los sujetos obligados que sean autores del hecho, sin que la delegación en un tercero la traslade (art. 8). Puedes contratar a una empresa de check-in, a un coanfitrión o a un software que haga todo el trabajo. Cuando algo falla, quien responde sigue siendo el titular de la actividad.

De ahí sale una regla de contratación sencilla:

• Exige acceso propio al histórico de envíos y a sus respuestas.
• Pide que el proveedor te avise de cada rechazo, no solo de los éxitos.
• Comprueba que puedes exportar tus registros en un formato que puedas abrir sin él.

Quien depende del panel de un tercero descubre el problema el día que necesita una estancia antigua y el proveedor ya no existe.

Qué datos pide el Anexo I y cómo recogerlos

El Anexo I enumera los datos que hay que registrar. Conviene leerlos por bloques, porque cada bloque sale de un sitio distinto de tu operativa.

| Bloque | Datos que exige el Anexo I | De dónde salen |
|---|---|---|
| Identidad de cada viajero | Nombre, primer apellido, segundo apellido, sexo, tipo y número de documento de identidad, número de soporte del documento, nacionalidad, fecha de nacimiento y lugar de residencia habitual | Formulario de check-in y documento del viajero |
| Contacto | Teléfono fijo, teléfono móvil y correo electrónico | Formulario de check-in |
| Menores | Relación de parentesco entre los viajeros cuando alguno sea menor de edad | Pregunta explícita en el formulario |
| Transacción | Tipo de pago, identificación del medio de pago, titular del medio de pago, fecha de caducidad de la tarjeta y fecha del pago | Pasarela de pago o liquidación del canal |

Los datos de identidad se piden a cada persona

Hay que pedirlos a cada viajero, no solo a quien reservó. Parece obvio y sin embargo es el error más repetido: el canal entrega los datos del titular de la reserva, el formulario se rellena una vez y los acompañantes no aparecen en ningún registro.

Diseña el formulario con una ficha por ocupante desde el principio. Cuando la reserva dice cuatro huéspedes, el enlace de check-in tiene que pedir cuatro fichas y no dejar cerrar el proceso con una.

El parentesco con un menor no está en ningún documento

El Anexo I exige declarar la relación de parentesco entre los viajeros cuando alguno de ellos sea menor de edad. Ese dato no se lee de un pasaporte, ni de la zona MRZ, ni del aviso de reserva de una plataforma. Hay que preguntarlo.

Un flujo que rellena el registro solo a partir de escaneos de documentos produce registros incompletos en todas las reservas familiares. Y lo hace sin dar ningún error, porque ningún campo técnico queda vacío: simplemente falta una pregunta.

Errores de formato que más rechazos provocan

Casi todos los rechazos vienen de un puñado de campos. Tenlos controlados en el formulario, antes de que el dato salga de tu sistema.

| Campo | Error típico | Cómo evitarlo |
|---|---|---|
| Número de documento | Espacios, guiones o la letra de control equivocada en un DNI o NIE | Normaliza el texto y calcula la letra antes de aceptar la ficha |
| Número de soporte | Confundirlo con el número de documento | Muestra una imagen del documento señalando dónde está cada número |
| Segundo apellido | Huéspedes extranjeros que no lo tienen y escriben un punto o repiten el primero | Permite dejarlo vacío de forma explícita, con una casilla |
| Fecha de nacimiento | Día y mes invertidos en formatos de otros países | Usa un selector de fecha, no un campo de texto libre |
| Nacionalidad | Nombres de país escritos a mano | Ofrece una lista cerrada de países con su código |
| Teléfono | Sin prefijo internacional | Pide el prefijo en un campo aparte |

Ninguno de estos controles es legal en sí mismo. Son la diferencia entre un registro que se acepta a la primera y uno que vuelve cuando el huésped ya no contesta.

El pago vive en otro sistema

La mitad del registro que más se olvida es la de la transacción. Identidad y contacto vienen de un formulario de cara al huésped; tipo de pago, medio, titular, caducidad de la tarjeta y fecha del pago están en tu pasarela o en el informe de liquidación del canal.

Las reservas pagadas por una empresa merecen cuidado aparte. Quien paga y quien duerme son personas distintas, y un esquema de datos que asuma que coinciden pierde el titular real del medio de pago sin avisar.

Une ambos bloques con el identificador de la reserva antes de comunicar nada. Cualquier registro donde falte la parte de pago está incompleto aunque la identidad sea perfecta.

Plazo de 24 horas: desde cuándo corre

El texto del art. 6.3 dice que la comunicación de la información debe realizarse de manera inmediata y, en todo caso, en un plazo no superior a 24 horas a partir de la reserva o formalización del contrato (o su anulación) y del inicio de los servicios contratados.

Fíjate en la estructura. Hay dos momentos de arranque, no un único reloj:

1. La reserva o formalización del contrato, y también su anulación.
2. El inicio de los servicios contratados, es decir, la llegada.

De ahí que un proceso que solo actúa en el check-in llegue tarde a la primera de las dos comunicaciones. Y un proceso que solo actúa en la reserva se queda corto en la segunda, porque los datos de cada viajero no se conocen hasta que llegan.

Las reservas del mismo día comprimen todo

Piensa en una reserva hecha a las 21:00 para entrar a las 23:00. Recogida, validación y envío tienen que caber en un par de horas, de noche, sin nadie mirando. Un proceso por lotes que corre una vez al día no sobrevive a ese caso.

El único montaje que aguanta es el que empieza en la confirmación de la reserva: el enlace de check-in sale con la confirmación y el envío se dispara por eventos, no por un horario. Si tu flujo depende de que el huésped rellene un formulario después de cruzar la puerta, cada llegada tardía es una incidencia esperando a ser contada.

Las cancelaciones también cuentan

La anulación aparece en el mismo artículo. Una integración que solo escucha las reservas nuevas deja las cancelaciones sin comunicar. Suscríbete también a los eventos de cancelación y modificación del canal. Lo mismo vale para una reserva que cambia de fechas o de número de huéspedes: el registro que comunicaste ya no describe la estancia real.

Cómo diseñar la automatización del parte de viajeros

El patrón que funciona es una cadena de eventos: cada paso se dispara cuando termina el anterior, sin tareas programadas por en medio.

1. Recibe el webhook de la reserva confirmada y crea el registro de la estancia con su identificador.
2. Envía al huésped principal un enlace de check-in propio de esa reserva, con una ficha por ocupante.
3. Valida cada ficha mientras el huésped la rellena: formato y dígito de control del documento, fechas, campos obligatorios y parentesco si hay menores.
4. Une la ficha con los datos de pago de la misma reserva.
5. Comunica los datos y guarda la respuesta completa con su marca de tiempo.
6. Emite el código de la cerradura solo cuando la comunicación ha sido aceptada.
7. Escucha cancelaciones y modificaciones y repite la comunicación cuando cambian los datos.

Por qué el código de acceso va al final

Las integraciones de cerraduras inteligentes suelen emitir un código temporal el día de la llegada. Mueve ese disparador para que dependa del acuse y no del calendario. Así el paso de cumplimiento deja de ser algo que alguien tiene que recordar: sin comunicación aceptada no hay código. En vez de un huésped dentro sin registrar, tienes un aviso en el panel.

Cualquier cerradura con una API que permita crear y revocar códigos bajo demanda sirve. Importa más el orden de los pasos que la marca. En las funciones que estamos construyendo en Klimpy contamos cómo planteamos este mismo orden.

Qué pedir a tu PMS o channel manager

La cadena entera depende de que tu sistema de reservas avise a tiempo. Antes de elegir o renovar proveedor, pregunta por escrito:

• Qué eventos envía por webhook: reserva nueva, modificación, cancelación y cambio en el número de huéspedes.
• Con qué retraso llegan esos eventos y si se reintentan cuando tu servidor no responde.
• Qué datos del huésped incluye el aviso y cuáles hay que pedir aparte.
• Dónde quedan los datos de pago y si puedes leerlos por API con el mismo identificador de reserva.
• Cómo se identifica cada inmueble, para no mezclar estancias de pisos distintos.

Las respuestas vagas aquí acaban siendo registros incompletos más adelante. Pide ejemplos reales del contenido de cada evento, no solo la documentación comercial.

Qué guardar de cada estancia

De cada estancia conserva el contenido enviado, la respuesta recibida, la hora de ambos y quién o qué proceso disparó el envío. Con eso, una inspección se resuelve con una consulta a tu base de datos. Guarda también las versiones anteriores cuando un huésped corrige un dato, para poder explicar qué cambió y cuándo.

Qué hacer cuando un envío falla

Los fallos son de varios tipos, y tratarlos igual es la forma más rápida de agotar el plazo.

| Fallo | Ejemplo | Qué hacer |
|---|---|---|
| Transporte | Tiempo de espera agotado, error de servidor, conexión caída | Reintenta con espera creciente hasta obtener respuesta; si el plazo se acerca, avisa a una persona |
| Validación | Número de documento mal formado, código de país desconocido, apellido vacío | No reintentes: corrige el dato en origen, idealmente con el huésped todavía en el formulario |
| Datos incompletos | Falta la ficha de un acompañante o el titular del pago | Bloquea el envío, pide el dato que falta y deja la estancia marcada en la cola |
| Sin acuse | El envío salió pero no hay respuesta guardada | Trátalo como no comunicado hasta tener la respuesta |

Un rechazo de validación reintentado en bucle es el peor de los casos: la cola parece activa, el plazo se consume y la estancia acaba sin comunicar. Distingue los dos tipos de error desde el primer día.

Valida antes de transmitir

En el momento de la recogida, con el huésped delante, comprueba el formato del documento y la letra de control de DNI o NIE. Revisa también los códigos de país y los campos obligatorios. Un error descubierto horas después ya no tiene a nadie que lo corrija.

Infracciones y multas: qué fija la ley

El régimen sancionador de las infracciones al RD 933/2021 se rige por el capítulo V de la Ley Orgánica 4/2015; el real decreto no fija cuantías (art. 8.1).

| Tipo | Conducta (art. 8 del RD 933/2021) | Multa (art. 39 de la LO 4/2015) |
|---|---|---|
| Grave | La carencia de los registros documentales previstos en el real decreto y la omisión de las comunicaciones obligatorias | De 601 a 30.000 euros |
| Leve | Las irregularidades o deficiencias en la cumplimentación de los registros y la realización de las comunicaciones obligatorias fuera del plazo establecido | De 100 a 600 euros |

Lee la tabla al revés de como se suele leer. Comunicar tarde es leve; no comunicar es grave. Un sistema que, ante la duda, prefiere enviar aunque sea tarde a no enviar nunca está bien orientado. Un sistema que se queda bloqueado esperando un dato perfecto acaba en la fila de abajo.

Qué no dice la tabla

La tabla da horquillas, no cifras. No vamos a darte multas medias ni casos tipo: no hay en el BOE una tabla que permita calcular de antemano dónde cae una sanción concreta dentro de cada horquilla.

Conservación del registro durante tres años

Los datos del registro informático deben conservarse durante un plazo de tres años a contar desde la finalización del servicio (art. 5.3). Ese archivo es tuyo, no la copia que quede en la plataforma que recibe las comunicaciones.

Algunas consecuencias prácticas:

• Guarda el registro en un sistema que controles y que puedas exportar.
• Calcula la fecha de borrado desde el final de la estancia, no desde la reserva.
• Programa el borrado al terminar ese plazo, para no conservar datos personales más tiempo del necesario.
• Restringe el acceso: son documentos de identidad y medios de pago.

Checklist antes de dar de alta un piso

Repasa esta lista con cada inmueble nuevo, y otra vez cuando cambies de canal o de proveedor.

• ☐ El enlace de check-in sale con la confirmación de la reserva, no con la llegada.
• ☐ El formulario pide una ficha por cada viajero.
• ☐ El formulario pregunta el parentesco cuando hay un menor.
• ☐ Los datos de pago se unen a la estancia por el identificador de la reserva.
• ☐ Las cancelaciones y modificaciones también disparan una comunicación.
• ☐ Los errores de transporte se reintentan y los de validación van a corrección.
• ☐ Cada respuesta se guarda con su hora.
• ☐ El código de la cerradura depende del acuse, no del calendario.
• ☐ El registro se conserva tres años desde el fin de la estancia y luego se borra.
• ☐ Tienes acceso propio a todo el histórico, aunque trabajes con un tercero.

Klimpy está en fase de prelanzamiento; en el apartado de cumplimiento de la web de Klimpy explicamos cómo lo estamos abordando.