Guía operativa — el fichero por dentro

Cómo se genera y envía el parte a los Mossos

Esta página describe, paso a paso, cómo se construye y se entrega el parte de viajeros a los Mossos d'Esquadra: desde el alta inicial en el portal, hasta el guardado del comprobante en el archivo trianual del host. La sección central detalla la anatomía del fichero de anchura fija que la Direcció General de la Policia exige como formato de entrega. Los offsets concretos que se muestran a continuación son ilustrativos de cómo funciona un fichero posicional típico; antes de cualquier implementación productiva, conviene contrastar las anchuras y los códigos exactos con la especificación técnica vigente publicada en el portal de Mossos.

Paso 1 — Alta del establecimiento en el portal

Antes de generar el primer parte, el establecimiento debe estar dado de alta en el Registre de Viatgers dels Mossos d'Esquadra, a través del portal registreviatgers.mossos.gencat.cat. El alta requiere identificación electrónica fuerte:

• idCAT mòbil: el sistema de identificación de la Generalitat, accesible a personas con DNI/NIE y un número de móvil verificado.
• Cl@ve con nivel suficiente: el sistema estatal, válido también para hosts no catalanes con NIF activo.
• Certificado Digital FNMT: el certificado de la Fábrica Nacional de Moneda y Timbre, reconocido por la Generalitat.
• Usuario/contraseña Mossos: en algunos supuestos, los Mossos emiten credenciales propias tras una verificación presencial del titular del establecimiento.

Durante el alta, el sistema recoge los datos identificativos del titular (NIF/NIE, razón social), los datos del establecimiento (denominación, dirección postal completa, tipo de hospedaje, número de habitaciones u unitats d'allotjament) y la inscripción en el Registre de Turisme de Catalunya cuando corresponda. Al finalizar, el portal asigna un código de establecimiento propio que identifica la propiedad en cada fichero posterior. Este código no es el mismo que el código H de SES.Hospedajes; los hosts con propiedades dentro y fuera de Cataluña reciben un código distinto para cada sistema.

Paso 2 — Recogida de datos del huésped

Por cada estancia, el host debe capturar el conjunto de datos del Anexo I del RD 933/2021. La recogida se hace típicamente antes de la llegada, mediante un proceso de pre-check-in: enviar al huésped un enlace en el que cumplimente los datos, valide su documento de identidad y firme. La alternativa es capturar los datos al llegar, pero esto es muy frágil en alojamientos con check-in autónomo, llegadas en festivos o ausencia del host.

Los campos a capturar por viajero son los siguientes. La lista coincide con el Anexo I; lo que varía en el contexto Mossos es cómo cada campo se serializa en el fichero final.

El campo número de soporte es uno de los que más rechazos provoca cuando se omite: en el DNI español es el código alfanumérico que aparece en una esquina de la tarjeta y que identifica la emisión concreta del documento, distinto del número del DNI propiamente dicho. En el TIE de residentes extranjeros, el equivalente cumple la misma función. Para pasaportes, este campo no aplica y se deja vacío.

Paso 3 — Generación del fichero de anchura fija

Una vez recogidos los datos, el host (o el software del host) genera el fichero .txt en el formato que el portal de Mossos exige. La pieza clave es entender que cada carácter cuenta: las posiciones son absolutas, no hay separadores entre campos, y cualquier campo más corto que su anchura definida debe rellenarse con espacios (alineación a la izquierda para textos) o con ceros a la izquierda (alineación a la derecha para algunos numéricos).

Estructura típica del fichero (ilustrativa)

Un fichero típico contiene tres tipos de registro distinguidos por su primer campo:

• Registro de cabecera (tipo 1): identifica al establecimiento emisor.
• Registro de contrato (tipo 2): identifica la reserva o estancia.
• Registro de viajero (tipo 3): un registro por cada persona alojada.

Una secuencia mínima ilustrativa podría tener este aspecto (los códigos 1, 2, 3 al inicio de línea son discriminadores de tipo de registro):

1H000123456BARCELONA HOTELS S.L.            HOTEL                   ...
2REF-2026-04001                  2026-05-10T14:00:002026-05-12T11:00:00...
3GARCIA                        LOPEZ                         JUAN ...
3MARTINEZ                      RUIZ                          MARIA ...

Layout de un registro de viajero (ilustrativo)

El detalle posicional de un registro de viajero, que es el más extenso, podría aproximarse a este esquema. Insistimos: las anchuras concretas deben verificarse contra la especificación oficial vigente. Las que se muestran a continuación son representativas de un fichero posicional típico de este género.

Pos  001-001  Tipo de registro       (1 carácter: "3")
Pos  002-031  Primer apellido        (30 caracteres, izquierda, espacios)
Pos  032-061  Segundo apellido       (30 caracteres, izquierda, espacios)
Pos  062-091  Nombre                 (30 caracteres, izquierda, espacios)
Pos  092-092  Sexo                   (1 carácter: H / D)
Pos  093-101  Tipo de documento      (9 caracteres del catálogo)
Pos  102-121  Número de documento    (20 caracteres, izquierda, espacios)
Pos  122-130  Número de soporte      (9 caracteres, izquierda, espacios)
Pos  131-140  Fecha de nacimiento    (10 caracteres, AAAA-MM-DD)
Pos  141-143  Nacionalidad           (3 caracteres, ISO 3166-1 alfa-3)
Pos  144-193  Dirección               (50 caracteres, izquierda, espacios)
Pos  194-223  Localidad              (30 caracteres, izquierda, espacios)
Pos  224-226  País de residencia     (3 caracteres, ISO 3166-1 alfa-3)
Pos  227-241  Teléfono móvil         (15 caracteres, derecha, ceros)
Pos  242-291  Correo electrónico     (50 caracteres, izquierda, espacios)
Pos  292-293  Rol                    (2 caracteres: VI)
Pos  294-...  Campos opcionales adicionales

Un registro de viajero anonimizado

Un ejemplo de cómo quedaría la línea de un viajero adulto, español, con DNI, residente en Barcelona (datos ficticios):

3GARCIA                        LOPEZ                         JUAN                          HDNI      12345678Z          ABC123456 1985-04-12ESPCARRER DE LA DIPUTACIO 123, 4t 2a            BARCELONA                     ESP000034600123456jgarcialopez@example.com                          VI

El mismo viajero, si fuera extranjero con pasaporte (segundo apellido vacío, sin número de soporte):

3SMITH                                                       JOHN ALEXANDER                HPAS      P12345678            1979-11-03GBR221B BAKER STREET                                LONDON                        GBR000044720123456j.smith@example.com                               VI

Estas líneas son ilustrativas: la anchura exacta de cada campo y la posición de cada delimitador deben ajustarse a la especificación vigente del portal.

Codificación de caracteres

El portal de Mossos ha utilizado tradicionalmente ISO-8859-1 (Latin-1), codificación de un byte por carácter que cubre el español, el catalán y la mayoría de lenguas europeas occidentales. Algunas versiones recientes admiten también UTF-8, pero la práctica recomendada cuando hay duda sigue siendo ISO-8859-1, salvo que la especificación vigente confirme expresamente UTF-8. La diferencia importa: un apellido como Pérez se codifica con un solo byte para la é en ISO-8859-1, pero con dos bytes en UTF-8; un fichero generado en UTF-8 e interpretado como ISO-8859-1 (o viceversa) producirá desplazamientos en los campos posteriores y, casi con seguridad, el rechazo del fichero.

Final de línea y final de fichero

El final de línea esperado es típicamente \n (LF, Unix) en lugar de \r\n (CRLF, Windows). Un fichero generado en Notepad u otros editores Windows sin atención a este detalle introduce un carácter extra al final de cada línea que altera la posición efectiva y dispara errores. La forma más fiable de evitarlo es generar el fichero programáticamente desde una herramienta que controle explícitamente el byte de fin de línea.

Paso 4 — Firma del huésped

El RD 933/2021 exige que cada viajero de 14 años o más firme el parte. La firma no se sube al portal de Mossos: lo que se sube es el fichero de datos. La firma queda en poder del host como parte del archivo trianual, como prueba documental de que el huésped fue identificado correctamente y de que aceptó la captura de sus datos. Las modalidades admitidas son las mismas que en el sistema estatal:

• Firma electrónica simple en pantalla (tableta, móvil del huésped).
• Firma electrónica reforzada con OTP en un flujo de pre-check-in antes de la llegada — la modalidad más sólida en términos de evidencia.
• Firma manuscrita en papel retenida físicamente por el host.

Los menores de 14 años no firman; firma el adulto acompañante, y el campo de relación de parentesco pasa a ser obligatorio en el registro del menor.

Paso 5 — Carga del fichero al portal

El portal de Mossos opera con carga manual: el usuario autenticado selecciona el fichero .txt generado, lo sube mediante el formulario web correspondiente y obtiene un comprobant con un identificador único. Este comprobante es la prueba de que el envío se realizó dentro del plazo de 24 horas, y debe conservarse junto con el fichero y los partes firmados de los huéspedes.

El portal verifica algunos errores en el momento de la subida (formato general, identificador de establecimiento válido) y otros en proceso asíncrono posterior (validación campo a campo de cada registro). Es importante revisar el comprobant y, si el portal pone a disposición un informe de validación detallado, comprobarlo: una subida aparentemente correcta puede contener líneas rechazadas individualmente.

A diferencia de SES.Hospedajes, que ofrece una API REST pública documentada, el portal de Mossos no expone, al menos en la versión actual, una API equivalente para envíos automatizados. Los servicios que automatizan la carga lo hacen actuando programáticamente sobre los mismos formularios web que utilizaría un humano.

Paso 6 — Conservación trianual

Los hosts profesionales en Cataluña deben conservar, durante tres años desde el final de cada estancia, el archivo documental completo de cada parte:

• El fichero .txt generado y subido al portal.
• El comprobant de carga emitido por Mossos.
• El parte firmado por cada huésped mayor de 14 años, en el soporte en que se haya recogido (electrónico o papel).
• Cualquier evidencia auxiliar relacionada (correos de pre-check-in, validación documental, etc.).

La conservación debe permitir la consulta por la autoridad si lo requiere: un soporte electrónico estructurado, indexable por estancia, es la solución más sólida. Un cajón con papeles desordenados es admisible en términos jurídicos pero impracticable si se recibe un requerimiento.

Patrón habitual de fallo: el fichero que parece correcto pero no lo es

Desde la entrada en vigor plena del régimen el 2 de diciembre de 2024, los errores más recurrentes que han dejado a hosts catalanes con partes técnicamente inexistentes son:

• Codificación incorrecta. Generar el fichero en UTF-8 cuando el portal espera ISO-8859-1, lo que rompe las anchuras de las líneas con acentos o eñes.
• Final de línea CRLF. Editar el fichero en Windows e introducir \r\n en lugar de \n.
• Códigos de país equivocados. Usar alfa-2 (ES, FR, GB) cuando se espera alfa-3 (ESP, FRA, GBR), o viceversa.
• Fechas en formato local. 12/04/1985 en lugar de 1985-04-12.
• Apellidos con apóstrofo mal escapados (l'Hospitalet, d'Anglès): el apóstrofo es válido en ISO-8859-1 pero algunos generadores no lo emiten correctamente.
• Número de soporte omitido para DNI y TIE: el portal lo rechaza como campo incompleto.
• Líneas más cortas o más largas de lo esperado por mal cálculo de la anchura de un campo.

Hosts con propiedades dentro y fuera de Cataluña

Un caso operativo frecuente es el del host que gestiona varias propiedades, algunas en Cataluña y otras en otra comunidad autónoma. En ese supuesto, conviven dos formatos y dos cuentas:

• Para las propiedades catalanas: parte en fichero .txt de anchura fija, subido al portal de Mossos.
• Para las propiedades fuera de Cataluña (y el País Vasco): parte en XML, enviado por API REST o formulario web a SES.Hospedajes.

Los datos del huésped son los mismos en uno y otro caso; el host debe generar dos serializaciones distintas y operar dos altas separadas. Los servicios de cumplimiento profesional gestionan ambos formatos en paralelo a partir de una única captura de datos del huésped.