Guía operativa — sistema Mossos d'Esquadra

Mossos Viajeros: cómo operar el portal de registro día a día

El sistema Mossos d'Esquadra para viajeros (registreviatgers.mossos.gencat.cat) es el portal que utilizan los alojamientos turísticos en Cataluña para comunicar a la policía autonómica los datos de cada huésped que pernocta. Esta guía explica cómo funciona el sistema día a día, qué requiere, y cómo cumplir sin errores. Damos por supuesto que ya sabes por qué Cataluña utiliza este portal en lugar de SES.Hospedajes; lo que falta para la mayoría de hosts es la mecánica operativa: cómo se da de alta el establecimiento, qué fichero hay que generar, cómo se sube y cómo se reacciona cuando el sistema lo rechaza.

El problema operativo que hay que resolver

Cada noche que un huésped pernocta en un alojamiento turístico catalán dispara una obligación con tres componentes: recoger el conjunto de datos definido por la Direcció General de la Policia, codificarlos en el formato de fichero que el portal de Mossos acepta y subirlos al portal dentro de las 24 horas siguientes a la entrada. A diferencia de SES.Hospedajes, el portal de Mossos no expone una API REST pública: la única vía técnica es la carga de un fichero plano por la interfaz web del portal (o vía SFTP cuando se ha solicitado y habilitado expresamente). Esto convierte el cumplimiento en un ciclo manual o semi-manual incluso para alojamientos con volúmenes considerables.

La consecuencia práctica es que la fricción no está en entender qué hay que hacer, sino en ejecutarlo correctamente, cada día, sin omisiones. Un fichero mal formateado se rechaza entero. Un campo con un acento codificado en UTF-8 cuando el portal espera ISO-8859-1 corrompe la línea. Un número de soporte de DNI omitido marca el registro como inválido. La operativa típica de un host catalán pasa, por tanto, por estandarizar el flujo: recogida, validación, generación de fichero, subida, archivado del comprobante.

Ciclo operativo diario

Para un alojamiento que cumple por carga manual, el flujo se reduce a estos cinco actos repetidos cada día con entrada:

1. Recoger los datos del huésped antes o en el momento de la llegada. La práctica recomendada es desplazar la recogida a un pre-check-in entre 7 y 2 días antes de la entrada, con un formulario online enviado al huésped que valide los campos antes de la llegada física.
2. Formatear los datos en el fichero plano de anchura fija que define la especificación de Mossos. Cada huésped es un registro; cada registro tiene un identificador de establecimiento, datos del contrato y datos del viajero.
3. Subir el fichero al portal con las credenciales del usuario operador. La interfaz permite validar el fichero antes de enviarlo en firme; conviene usar esa validación previa siempre.
4. Confirmar la recepción descargando el comprovant que emite el portal tras procesar el envío. Este documento es la prueba del cumplimiento del plazo.
5. Archivar el parte firmado por el huésped, el fichero enviado y el comprovant, organizados por estancia, durante los tres años exigidos.

Las páginas internas de esta guía desarrollan cada uno de estos cinco actos con el detalle suficiente para que un host nuevo pueda operar el sistema sin haber recibido formación previa, y para que un host con experiencia pueda diagnosticar dónde está fallando un envío rechazado.

Lo que diferencia operativamente a Mossos de SES

Si comparas este sistema con SES.Hospedajes, las diferencias que importan para la operativa son tres:

• No hay API pública. En SES, un PMS o un servicio especializado puede mandar partes en tiempo real vía REST. En Mossos, la integración pasa por generar el fichero y subirlo: el envío automático per check-in nativamente no existe.
• El procesamiento es por lotes. Como la carga es un fichero, lo habitual es agrupar varias entradas del día en un único envío. Esto introduce una sutileza: si el fichero contiene un registro con error, el lote completo se rechaza en algunas configuraciones, y hay que corregir y reenviar.
• La codificación es ISO-8859-1. El portal histórico de Mossos espera el conjunto de caracteres latin-1, no UTF-8. Esto importa para nombres con acentos, eñes, caracteres catalanes y huéspedes extranjeros con tildes o diéresis: si tu sistema interno trabaja en UTF-8, hay que convertir antes de generar el fichero, sin perder caracteres por el camino.

Quién es responsable y quién no

La responsabilidad de cumplir recae sobre el titular del establecimiento: la persona física o jurídica que explota la actividad de hospedaje. Ni la plataforma de intermediación (Airbnb, Booking, Vrbo) ni el huésped sustituyen al host. La plataforma comunica las reservas que recibe, pero eso no cubre la obligación del titular de comunicar la entrada efectiva del huésped. Si gestionas la propiedad de un tercero como property manager, contractualmente la responsabilidad puede repartirse, pero ante Mossos el sujeto obligado es el titular registrado; conviene formalizar la representación si vas a operar el portal en su nombre.

Errores más frecuentes en los primeros envíos

Los hosts que se enfrentan por primera vez al portal de Mossos repiten un patrón de errores reconocible. Aparecen tan a menudo que conviene anticiparlos antes del primer envío:

• Codificación equivocada. El fichero se generó en UTF-8 y los caracteres con tilde se transcriben como dos bytes; el portal devuelve error de formato.
• Anchura de campo incorrecta. Un nombre largo desborda el campo y desplaza todos los offsets de la línea. El registro completo se invalida.
• Número de soporte omitido. Para DNI y TIE es obligatorio; el sistema lo verifica contra una base de datos interna y, sin él, marca el registro como no válido.
• Formato de fecha incorrecto. El campo de fecha de nacimiento se rellenó como DD/MM/AAAA cuando la especificación pide AAAAMMDD.
• Doble envío. Por miedo a no haber enviado, el host carga el mismo fichero dos veces; el portal puede aceptar el segundo y dejar el primero pendiente, generando duplicados que luego hay que reconciliar.

La página Cómo funciona aborda estos errores uno por uno con su código de rechazo del portal y su solución típica.

Resumen y siguientes lecturas

El portal de Mossos para viajeros es, en lo sustantivo, el equivalente catalán de SES.Hospedajes: misma finalidad de seguridad pública, mismos datos por huésped, mismo plazo de 24 horas, misma conservación trianual. Lo que cambia es la mecánica: fichero plano en lugar de API, codificación latin-1, carga manual, comprovant por descarga. Si gestionas un alojamiento turístico en Barcelona, Girona, Lleida o Tarragona, esto es lo que tienes que dominar para cumplir sin sobresaltos.