Detalle técnico y operativo

Cómo funciona el portal Mossos paso a paso: fichero, subida y archivo

Esta página es la guía técnica del portal Mossos para viajeros. Cubre desde el alta inicial del establecimiento hasta el archivado del comprovant, pasando por la pieza central del sistema: el fichero plano de anchura fija que el portal espera. Si has llegado hasta aquí desde la portada o desde qué es, ya conoces el encuadre; lo que sigue es la mecánica.

Paso 1 — Alta del establecimiento en el portal

El alta es un acto único por propiedad y previo a cualquier envío. Se realiza desde el propio portal, identificándose con idCAT mòbil, Cl@ve, certificat FNMT o credenciales emitidas por Mossos. Durante el alta, el portal solicita:

  • Identificación del titular (NIF/NIE/razón social) y, en su caso, del representante autorizado.
  • Datos del establecimiento: denominación, dirección completa, municipio, comarca, provincia, tipología (hotel, apartament turístic, habitatge d'ús turístic, càmping, casa de turisme rural…).
  • Número de inscripción en el Registre de Turisme de Catalunya cuando aplica. Para habitatges d'ús turístic, este número se conoce coloquialmente como el código HUTB, HUTG, HUTL o HUTT según provincia.
  • Capacidad: número de unidades de alojamiento, plazas autorizadas.
  • Datos de contacto operativos: persona responsable, teléfono, correo electrónico.

Tras el alta, Mossos asigna el identificador interno del establecimiento, distinto del HUT y distinto del código de SES.Hospedajes. Este identificador es el que viajará en cada registro del fichero. Conviene guardarlo en un sitio accesible: si más adelante delegas la operativa, esa será la pieza que el operador necesitará para configurar el sistema.

Paso 2 — Alta de usuarios operadores

Si la persona física que operará el portal no es el titular, hay que dar de alta usuarios adicionales con el rol apropiado. La práctica habitual:

  • Titular o property manager principal: rol de gestor del establecimiento, con permisos plenos.
  • Personal de recepción o gestor delegado: rol de operador, con permisos para cargar ficheros y descargar comprovants.
  • Servicio especializado externo: rol de operador también, con la formalización contractual de la delegación.

Cada usuario se identifica con sus propias credenciales (idCAT mòbil, Cl@ve, FNMT). El gestor del establecimiento puede revocar el acceso de un operador en cualquier momento desde la propia interfaz, lo que es relevante cuando hay rotación de personal o cuando se cambia de servicio externo.

Paso 3 — Recogida de los datos del huésped

Por cada huésped que pernocta hay que capturar el conjunto de datos definido. La recogida es una pieza separada de la codificación en fichero: muchos hosts hacen las dos cosas en el mismo soporte (una hoja de cálculo, una herramienta del PMS), pero conceptualmente conviene separarlas porque los errores ocurren en lugares distintos. Los campos a capturar por viajero son aproximadamente los mismos del Anexo I del RD 933/2021:

  • Nombre, primer apellido, segundo apellido (este último para nacionales con DNI/NIF).
  • Sexo, nacionalidad (codificación ISO 3166-1 alfa-3), fecha de nacimiento.
  • Tipo de documento (DNI, NIE, TIE, pasaporte), número del documento, número de soporte (para DNI y TIE).
  • Lugar de residencia habitual: dirección completa, localidad, país.
  • Teléfono fijo, móvil y correo electrónico cuando se disponen.
  • Relación de parentesco cuando hay menores en la reserva.

Por cada reserva se capturan, además, los datos del contrato: referencia interna, fecha de formalización, fecha y hora de entrada, fecha y hora de salida, número de personas, número de habitaciones y tipo de pago. El tipo de pago se codifica en una lista cerrada (efectivo, tarjeta, plataforma, transferencia, otros); el número de tarjeta o cuenta no se comunica.

Paso 4 — Formato del fichero plano de anchura fija

El fichero que se carga al portal de Mossos es un texto plano con un registro por línea. La especificación que publica la Direcció General de la Policia define para cada campo: posición de inicio, longitud, tipo (alfanumérico o numérico) y, en algunos casos, valores aceptados. Los registros son de anchura fija: cada campo ocupa exactamente las posiciones que le corresponden, sin separadores. Los campos cortos se rellenan con espacios a la derecha (alfanuméricos) o con ceros a la izquierda (numéricos).

Características del formato

  • Codificación: ISO-8859-1 (latin-1). No UTF-8. Los caracteres con tilde, eñes y caracteres catalanes específicos se codifican en un byte.
  • Final de línea: CRLF (\r\n) o LF según la versión del esquema; la especificación reciente acepta ambos.
  • Longitud típica del registro: en torno a 400–500 bytes por viajero, dependiendo de la versión del esquema y de los campos optativos presentes.
  • Tipos de registro: el fichero suele tener un registro de cabecera (con identificador del establecimiento, fecha del envío, número total de registros) y un registro por cada viajero. Algunas especificaciones incluyen también un registro por contrato si hay varios viajeros agrupados.
  • Formato de fecha: AAAAMMDD para fechas sueltas (nacimiento, formalización) y AAAAMMDDhhmm o AAAAMMDDhhmmss para fecha y hora (entrada, salida). Las barras o guiones se quitan.
  • Codificación de nacionalidad: ISO 3166-1 alfa-3 (ESP, FRA, GBR, USA…).

Cómo codificar correctamente los caracteres especiales

El paso de UTF-8 a ISO-8859-1 es donde se concentran los errores de codificación. Caracteres como à, è, í, ó, ú, ç, ñ tienen punto de código en latin-1. Caracteres fuera del rango (cirílicos, asiáticos, algunos diacríticos exóticos) no tienen representación directa y deben transliterarse, no eliminarse en silencio. Si tu PMS o tu hoja de cálculo guarda el fichero en UTF-8, hay que convertir el conjunto antes de subirlo. En la línea de comandos, una conversión típica:

iconv -f UTF-8 -t ISO-8859-1//TRANSLIT entrada.txt -o salida.txt

El flag //TRANSLIT traduce caracteres que no caben en el destino a su mejor equivalente en latin-1 en lugar de fallar. Una conversión silenciosa que pierde bytes desplaza las anchuras de los campos y rompe la validación.

Paso 5 — Subida al portal y validación

Con el fichero generado, la subida se hace desde la sección correspondiente del portal. La práctica recomendada es:

  1. Iniciar sesión con el usuario operador.
  2. Seleccionar el establecimiento.
  3. Usar la opción de validación previa del fichero (cuando está disponible): el portal procesa el contenido sin grabarlo, indica errores de formato y permite corregir antes del envío en firme.
  4. Una vez validado, ejecutar el envío en firme.
  5. Descargar el comprovant emitido por el portal, con la referencia única del envío.

El comprovant es la prueba documental del cumplimiento del plazo. Su descarga inmediata y archivado son críticos: el portal mantiene el histórico, pero la pieza que demuestra que el envío llegó dentro de las 24 horas exigidas es el comprovant con su sello de tiempo.

¿Buscas una solución que se encargue de todo, integrada con el sistema Mossos?

Generar el fichero de anchura fija correcto, subirlo al portal, confirmar la recepción y conservar el registro — todo dentro de plazo y para cada huésped — es un trabajo recurrente que escala mal. TouristTaxManager es un servicio especializado que automatiza la recogida de datos antes de la llegada, genera y envía el parte al sistema de los Mossos d'Esquadra, y conserva tu registro durante los plazos legales.

Conocer TouristTaxManager

Cómo se cuentan las 24 horas en Mossos

El cómputo del plazo de 24 horas se cuenta desde la entrada efectiva del huésped al establecimiento, no desde la fecha de la reserva ni desde la fecha de formalización del contrato. En la práctica, la fecha y hora de entrada que aparece en el registro del fichero es la que define el tic inicial. Algunos hosts confunden la entrada con la fecha del check-in administrativo (firma del parte) o con el alta en el PMS; el dato relevante es la entrada física al alojamiento, que se hace coincidir habitualmente con el check-in.

Esta sutileza importa porque, si el huésped llega a las 23:30 de un sábado, el plazo expira a las 23:30 del domingo. La ausencia del personal o la imposibilidad de subir el fichero un domingo no detiene el plazo. La forma operativa de garantizar el cumplimiento es desplazar la recogida al pre-check-in: el viajero rellena sus datos online en los días previos, el fichero se genera automáticamente y la subida se programa en cuanto se confirma la entrada.

Errores de rechazo y qué significan

Cuando el portal rechaza un fichero, devuelve un mensaje de error que apunta al registro y al campo. Los patrones más frecuentes:

Tipo de error Causa más probable Cómo se corrige
Error de codificación Fichero guardado en UTF-8 o caracteres no latin-1 Re-guardar en ISO-8859-1 con conversión por transliteración
Longitud de registro incorrecta Un campo desbordó su anchura y desplazó toda la línea Truncar el campo en su anchura máxima; revisar nombres largos
Documento no válido Número de DNI/NIE mal formado o número de soporte omitido Capturar el número de soporte; verificar dígito de control
Fecha mal formada Formato DD/MM/AAAA en lugar de AAAAMMDD Reformatear todas las fechas; quitar separadores
Nacionalidad no reconocida Código de 2 letras en lugar de 3, o nombre del país en texto Usar siempre ISO 3166-1 alfa-3 (ESP, FRA, GBR, USA…)
Establecimiento no autorizado Identificador del establecimiento erróneo o no dado de alta Verificar identificador asignado por Mossos en el alta
Duplicado El mismo huésped y entrada ya fueron registrados No reenviar; el sistema mantiene el primero

Algunas configuraciones del portal rechazan el lote completo cuando hay errores en uno de los registros; otras procesan los válidos y devuelven un parcial con la lista de errores. La diferencia depende del esquema del fichero y de la opción seleccionada en la subida; conviene revisar siempre el comprovant para confirmar cuántos registros entraron.

Paso 6 — Archivado del comprovant y trazabilidad

Los hosts profesionales tienen obligación de conservar el archivo documental durante tres años desde el final de la estancia. El archivo, en el caso del sistema Mossos, se compone de tres elementos por estancia:

  1. El parte firmado por el huésped (firma electrónica simple o reforzada, o firma manuscrita en papel retenida por el host).
  2. El fichero enviado, en su versión definitiva tras corregir errores.
  3. El comprovant del portal, con la referencia única y la fecha/hora de aceptación.

El archivo debe ser consultable por la autoridad cuando lo requiera, lo que en la práctica obliga a tenerlo en un soporte electrónico estructurado, no como acumulación de PDFs sueltos en un directorio. Una solución razonable es una hoja-índice por estancia o una carpeta nombrada con la fecha y referencia, que permita localizar cualquier estancia en segundos.

Herramientas y panorama tecnológico

Los hosts catalanes resuelven la generación del fichero por una de cuatro vías:

  • Hoja de cálculo manual. Plantilla en Excel/Google Sheets con los campos exigidos; al final del día, exportar a texto y formatear las anchuras. Funciona para volumen muy bajo; muy propenso a errores de formato.
  • Exportación del PMS. Algunos PMS especializados (sobre todo los orientados al mercado catalán) incluyen un exportador de fichero de Mossos. La calidad varía; algunos generan el fichero técnicamente correcto, otros producen un texto que requiere ajustes posteriores.
  • Aplicación de generación de ficheros dedicada: pequeñas herramientas, locales o cloud, que toman la lista de huéspedes y producen el fichero. Resuelven el formato pero dejan la subida al portal manual.
  • Servicio especializado integral: el host externaliza el ciclo completo, incluido el pre-check-in, la generación, la subida y el archivado.

La elección depende del volumen, del valor del tiempo del host y de la tolerancia al riesgo de error. Para una vivienda con 3 entradas al mes, una hoja de cálculo bien hecha basta. Para una cartera de 20 propiedades con rotación semanal, mantener el cumplimiento manualmente es desproporcionado.

Reglas que importan en el día a día

No fotocopies el DNI

La obligación es capturar los campos, no conservar la imagen del documento. La Agencia Española de Protección de Datos considera que conservar la fotocopia íntegra del DNI, NIE, TIE o pasaporte excede el principio de minimización de datos del RGPD. Validar visualmente el documento al recibir al huésped es admisible; archivar la copia, no.

Registra a todos los huéspedes, incluidos menores

Todos los viajeros, sin excepción de edad, generan un registro. Los menores de 14 años no presentan documento de identidad y no firman; firma el adulto acompañante. El campo de relación de parentesco pasa a ser obligatorio cuando hay un menor en la reserva.

Si el huésped no quiere dar sus datos

El host puede denegar el alojamiento al huésped que se niega a proporcionar los datos exigidos. La obligación pesa sobre el host, y el host no puede cumplir si el viajero no colabora. Conviene comunicar el requisito en la confirmación de reserva y en el correo de bienvenida, no en la puerta.

Automatiza el ciclo entero

Si la operativa que acabas de leer te pesa, hay una capa de software que la elimina. TouristTaxManager recoge los datos por pre-check-in, valida los documentos, genera el fichero en formato Mossos, lo sube al portal y archiva el comprovant. Tú no tocas el portal.

Ver cómo lo hace TouristTaxManager