El parte para Mossos — Fichero plano, formato propio

Parte de viajeros para los Mossos d'Esquadra

El parte de viajeros para los Mossos d'Esquadra es el documento de comunicación que los alojamientos turísticos ubicados en Cataluña deben enviar a la policía autonómica con los datos identificativos de cada huésped: un fichero de anchura fija en texto plano, con extensión .txt, que se sube manualmente al portal registreviatgers.mossos.gencat.cat. No es un XML, no es un JSON, no es una llamada a una API: es un fichero de líneas con campos colocados en posiciones tasadas y rellenados con espacios o ceros para mantener la anchura constante. Esta página describe ese fichero desde fuera y desde dentro: qué lo distingue del parte de SES.Hospedajes que se utiliza en el resto del Estado, qué campos lleva, qué errores de formato lo hacen inválido y cómo encaja en la obligación que el Real Decreto 933/2021 impone a todos los hosts españoles.

¿A quién aplica este parte concreto?

El parte que se describe en este sitio es específico para los alojamientos turísticos cuya propiedad se ubica físicamente en cualquiera de las cuatro provincias catalanas —Barcelona, Girona, Lleida o Tarragona—. Cataluña ejerce competencias propias en materia de policía a través de los Mossos d'Esquadra, lo que se traduce, a efectos del registro de viajeros, en un sistema separado del SES.Hospedajes estatal. La obligación material es paralela —los mismos campos del Anexo I del RD 933/2021, las mismas 24 horas, los mismos tres años de conservación— pero el canal técnico es distinto y el formato del documento también.

  • Hoteles, hostales, pensiones, hospederías y posadas en Cataluña.
  • Apartamentos turísticos y aparthoteles ubicados en suelo catalán.
  • Habitatges d'ús turístic (HUT), la denominación catalana de las viviendas de uso turístico.
  • Cases de pagès, masías y cases rurals.
  • Càmpings, refugios de montaña y albergues turísticos.

Si la propiedad está en territorio catalán, el parte se envía a Mossos en este formato. Si la propiedad está fuera de Cataluña, el parte se envía a SES.Hospedajes en formato XML por API REST. Un host con propiedades en ambos territorios opera, en la práctica, dos formatos paralelos y dos cuentas separadas.

El parte de Mossos, en una mirada

Soporte:
Fichero de texto plano, anchura fija, extensión .txt
Codificación:
Históricamente ISO-8859-1; UTF-8 admitido en versiones recientes — verificar contra la especificación vigente
Estructura:
Una línea por viajero; campos posicionales rellenados con espacios o ceros
Portal:
registreviatgers.mossos.gencat.cat — carga manual
Plazo:
24 horas desde la entrada del huésped
Firma:
Huésped mayor de 14 años — queda en poder del host, no se sube
Conservación:
3 años desde el final de la estancia (profesionales)
API pública:
No disponible — solo carga manual de fichero

Por qué un fichero de ancho fijo

La elección del formato no es estética: responde a una tradición administrativa de la Direcció General de la Policia que precede al RD 933/2021 y que se mantiene por razones de continuidad operativa. El fichero de anchura fija —donde cada campo ocupa exactamente N caracteres, sin separadores, sin etiquetas— era el formato natural de intercambio entre sistemas heredados; tiene la ventaja de ser extraordinariamente compacto (un parte con diez viajeros ocupa unos pocos kilobytes), fácil de parsear con herramientas simples (un script en Python o awk extrae los campos por slicing de cadena) y resistente a errores de codificación en intercambios con mainframes y bases de datos relacionales antiguas.

El precio es la rigidez. Un solo carácter de más en una línea desplaza todos los campos siguientes y convierte un parte aparentemente correcto en un parte inválido. Los apellidos catalanes con apóstrofo (d'Esquadra, l'Hospitalet), las eñes, los acentos y los caracteres especiales de pasaportes extranjeros son fuentes habituales de problemas si la codificación del fichero no coincide con la esperada por el portal.

Anatomía del registro: secciones y campos

El fichero típico contiene una cabecera con datos del establecimiento, seguida de una línea por viajero con sus datos personales. En algunas variantes del formato, los datos del contrato (fechas, número de habitaciones, importe) viajan en una línea intermedia entre la cabecera y los viajeros.

Los campos por viajero son materialmente los mismos del Anexo I del RD 933/2021: nombre, primer apellido, segundo apellido si procede, sexo, nacionalidad codificada según ISO 3166-1, fecha de nacimiento en formato YYYY-MM-DD, tipo de documento, número de documento, número de soporte cuando aplique, lugar de residencia habitual, teléfonos, correo, relación de parentesco si hay menores y rol del viajero. Lo que cambia es cómo se serializa cada campo en la línea: cada uno ocupa una anchura y unas posiciones definidas en la especificación técnica del portal.

A título ilustrativo (las anchuras exactas deben comprobarse contra la especificación vigente publicada por la Direcció General de la Policia), la primera parte de un registro por viajero podría tener una estructura como esta:

Pos 001-030  Primer apellido       (30 caracteres, alineado a la izquierda, relleno con espacios)
Pos 031-060  Segundo apellido      (30 caracteres, alineado a la izquierda, relleno con espacios)
Pos 061-090  Nombre                (30 caracteres, alineado a la izquierda, relleno con espacios)
Pos 091-091  Sexo                  (1 carácter: H / D)
Pos 092-100  Tipo de documento     (9 caracteres, código del catálogo Mossos)
Pos 101-120  Número de documento   (20 caracteres, alfanumérico)
Pos 121-130  Fecha de nacimiento   (10 caracteres, formato AAAA-MM-DD)
Pos 131-133  Nacionalidad          (3 caracteres, ISO 3166-1 alfa-3)
Pos 134-...  ...

Una línea de viajero anonimizada quedaría, también de forma ilustrativa, así:

GARCIA                        LOPEZ                         JUAN                          HDNI      00000000T            1985-04-12ESP...

Las posiciones exactas, la lista de códigos de tipo de documento, la lista de códigos de sexo y la lista de códigos de país son los elementos que con más frecuencia cambian entre versiones del formato. Antes de implementar cualquier integración, conviene descargar la especificación técnica vigente desde el portal de Mossos.

¿Buscas una solución que se encargue de todo?

Generar el parte de viatgers en el formato correcto para los Mossos d'Esquadra, huésped a huésped, dentro de las 24 horas y conservarlo 3 años, es un trabajo recurrente que escala mal y donde los errores de formato cuestan tiempo. TouristTaxManager es un servicio especializado que automatiza la recogida de datos antes de la llegada, genera el parte en el formato exigido y lo envía al portal de los Mossos, conservando tu registro durante los plazos legales.

Conocer TouristTaxManager

Resumen de lo que tienes que hacer

Para un host catalán que arranca de cero, el ciclo completo de cumplimiento del parte de viatgers se reduce a estos pasos:

  1. Alta en el portal de Mossos. Acceso con idCAT mòbil, Cl@ve, certificado FNMT o el usuario/contraseña que emiten los Mossos tras verificación presencial. Sin un medio de identificación electrónica válido, el alta no es posible.
  2. Recogida de los datos del huésped antes o en el momento de la llegada — los campos del Anexo I del RD 933/2021, ampliados con las particularidades del formato Mossos cuando proceden.
  3. Generación del fichero en el formato de anchura fija definido por la especificación vigente del portal — con la codificación de caracteres correcta y con las anchuras y rellenos exactos.
  4. Firma del huésped mayor de 14 años, conservada por el host como parte del archivo, no subida al portal.
  5. Carga manual del fichero al portal de Mossos dentro de las 24 horas posteriores a la entrada del primer huésped del fichero.
  6. Conservación trianual del parte firmado, del fichero generado y del comprobante de carga emitido por el portal.

Riesgos: dos formatos, dos sistemas, dos puntos de fallo

El riesgo principal del parte para Mossos no es teórico sino operativo: el rechazo silencioso del fichero por errores de formato. La carga manual no siempre devuelve diagnóstico detallado; el portal puede aceptar la subida y rechazar internamente líneas con desbordamientos o codificaciones incorrectas, dejando viajeros sin registrar y sin que el host sea consciente. Los errores más frecuentes en los primeros meses de exigencia plena (desde el 2 de diciembre de 2024) han sido:

  • Líneas con anchura distinta de la esperada por la inserción accidental de un tabulador o un retorno de carro \r\n en lugar de \n.
  • Caracteres con tilde codificados en UTF-8 cuando el portal espera ISO-8859-1, lo que duplica la anchura del campo y desplaza todo lo posterior.
  • Códigos de país en formato alfa-2 (ES) cuando se espera alfa-3 (ESP), o viceversa.
  • Fechas en formato DD/MM/YYYY cuando se espera YYYY-MM-DD.
  • Omisión del campo de número de soporte para DNI y TIE, que en el formato Mossos también es obligatorio.

Las sanciones aplicables son las del régimen general de la Ley Orgánica 4/2015: de 100 € a 600 € por infracciones leves (envío fuera de plazo, errores), de 601 € a 30 000 € por infracciones graves (no estar dado de alta, no enviar). En Cataluña, la competencia sancionadora corresponde a la Generalitat.

Por dónde seguir

Las siguientes cuatro páginas profundizan en cada bloque: la definición jurídica del parte y su contexto regulatorio, la guía operativa de generación y envío, el régimen sancionador, y las preguntas más habituales que los hosts catalanes formulan sobre el formato y el portal.

Resuelve el formato y deja de generarlo a mano

Si gestionar el fichero de anchura fija a mano —entre apellidos catalanes con apóstrofo, codificaciones de caracteres y plazos de 24 horas— deja de ser sostenible, hay servicios diseñados exactamente para esto. TouristTaxManager automatiza la generación del parte en el formato exigido por los Mossos, la carga al portal y la conservación trianual del archivo. Tu intervención queda reducida a lo imprescindible.

Ver cómo funciona TouristTaxManager