Repository navigation
[16.0][IMP][FIX] pms_l10n_es: INE occupancy surveys on IRIA — add tourist apartments (EOAP) and stop the recurring rejections - #233
davidpachecop wants to merge 12 commits into
Conversation
… tourist apartments (EOAP) The INE replaced the ARCE platform with IRIA. IRIA questionnaire schemas are namespace-qualified, so the XML files generated so far are rejected at upload time (XSD error on line 1: cannot find the declaration of the root element). IRIA also removed the in-portal editing that ARCE allowed, so the generated file must be exact. Hotel survey (EOH) fixes: - Qualify the root element with the IRIA namespace, configurable through the ir.config_parameter pms_l10n_es.ine_xml_namespace_hotel. - Declare and encode the file as UTF-8 (it declared ISO-8859-1 while encoding UTF-8 bytes). - Print DIAS_ABIERTO_MES_REFERENCIA zero-padded to 2 digits and omit the URL element when the property has no website (both rejected by the IRIA schema). - Emit every decimal with exactly 2 digits and normalize the occupancy percentages in integer hundredths so the printed values add up to exactly 100.00: float artifacts have been a recurrent source of files rejected by the INE content validations. - New INE province literal on res.country.state: the survey header expects the province literal of the INE specification (max. 25 chars) and several Odoo state names exceed it. New tourist apartments survey (EOAP): - New survey_type on the INE categories and seed data for the tourist apartments categories (0-4 keys). The wizard picks the questionnaire format from the property INE category. - New apartment typology on rooms (studio / 2-4 pax / 4-6 pax / other), inferred from the room capacity when not set. - New informant fields on the property (required block in EOAP). - New XML builder with the EOAP blocks (CABECERA_APARTAMENTOS, INFORMANTE, CAPACIDAD, OCUPACION and PRECIOS per typology), sharing the guest movements and staff blocks with the hotel survey. The whole occupancy of each typology is reported under the normal rate with its ADR, which satisfies the INE content validations and has been accepted by the INE in a real submission. Tests validate both generated files against the current IRIA schemas and the exactness of the printed decimals and percentage sums. Assisted-by: Claude Opus 5
…nexes The INE publishes the survey annexes as XML files. Checking the seed data against them: - The province literal expected for province 48 is VIZCAKAIA (as published in the province annex), not VIZCAYA. - The hotel type/category table includes one pair that was missing. Assisted-by: Claude Opus 5
Actualización: respuesta del INE (5-ago) y datos oficialesEl INE (equipo de IRIA) ha contestado a nuestras consultas y ha publicado los enlaces permanentes de los esquemas y anexos de cada encuesta. Resumen de lo que confirma y de lo que ha cambiado en la rama: Confirmado por el INE:
Cambios en la rama a partir de sus anexos oficiales (commit "align INE reference data with the published INE annexes"):
Matiz importante sobre el espacio de nombres (decisión 1): el INE indica que "el esquema es exactamente igual que el de ARCE". Estructuralmente es cierto (mismos 65 elementos en el mismo orden), pero hay dos variantes del esquema y se excluyen mutuamente:
Comprobado: el fichero que el INE nos aceptó y registró lleva espacio de nombres y no valida contra el esquema publicado; y ese mismo fichero sin espacio de nombres no valida contra el del cuestionario. Es decir, la carga por el portal valida contra el esquema versionado (con espacio de nombres), que es lo que hace esta rama. Además, la documentación del servicio web apunta al esquema publicado (sin espacio de nombres), así que puede haber divergencia entre canales: otro motivo para mantener el espacio de nombres como parámetro configurable en lugar de fijarlo en el código. Pendiente de que el INE confirme ambos puntos (preguntado). |
The INE confirmed that the reference schema of each survey is the one they publish, which declares no target namespace, and not the one the IRIA application generates for the questionnaire. Both variants have been accepted on upload so far (hotel files without namespace, an apartments file with it), so the files are built after the published schema and the qualified variant can be enabled per survey with a config parameter for the questionnaires that need it. This keeps the hotel file byte-compatible with what the establishments have been uploading successfully. Assisted-by: Claude Opus 5
Corrección importante: el fichero hotelero NO estaba rotoEn el comentario anterior daba por probable que los ficheros hoteleros estuvieran siendo rechazados en IRIA por no declarar el espacio de nombres. Era una inferencia y es incorrecta. Lo aclaran dos cosas de hoy:
El rechazo que originó todo esto se explica entonces solo por el guión equivocado: se subía el fichero de hoteles a un cuestionario de apartamentos, y ahí Cambio aplicado (commit "build the INE files after the published schema"): el espacio de nombres pasa a estar vacío por defecto en las dos encuestas, de modo que el fichero hotelero queda idéntico al que la flota sube con éxito, y la variante cualificada se puede activar por encuesta con un parámetro si algún cuestionario la exigiera. Los tests cubren ahora las dos variantes: por defecto validan contra los esquemas publicados por el INE y, con el parámetro puesto, contra los versionados que entrega IRIA. 27 tests, 0 fallos. Otras confirmaciones del INE
|
The INE questionnaire is also downloaded from the guest app through the REST API, so the validation messages reach end users: translate the new error messages, field labels and selections. Assisted-by: Claude Opus 5
Traducciones al castellano de los mensajes nuevosEl cuestionario también se descarga desde la app a través de la API REST ( Nota para el revisor: el Sobre el lado de la app: propuesta de no tocar nadaEl flag
Es un estado transitorio que solo aparece si se marca una propiedad como apartamentos sin completar el informante, así que encaja mejor en el checklist de configuración que en el gate. |
Generating the file of every property with an INE category in the fleet and checking it against the schema published by the INE and its official content validations (XML_0..XML_17 of the web service documentation) surfaced three cases that build a file the INE rejects: - Properties whose phone has less than 9 digits: the schema requires between 9 and 13 characters in TELEFONO_1. - Periods without guest movements: the schema requires at least one RESIDENCIA under ALOJAMIENTO, so an empty block cannot be uploaded. - A client type reporting a rate with a zero percentage, or the other way around: the INE requires both to be consistent, on top of the percentages adding up to 100. The first two now raise a message explaining what to fix instead of building an invalid file, and the percentages are normalized keeping their consistency with the rates. The file must also carry the whole reference month even though the questionnaire asks for a single week (hotels) or fortnight (apartments), so a partial period is rejected up front. Assisted-by: Claude Opus 5
Prueba de la flota completa contra las validaciones oficiales, sin gastar clavesEl INE nos ha dado claves ficticias de prueba, pero el código de control es de un solo uso (así lo dice la documentación del servicio web: "Sólo es válido para una vez, pues corresponde a un único cuestionario"). Antes de gastar ninguna, hemos hecho la comprobación en frío con datos reales:
Lo que ha salidoRechazos de esquema reales, hoy, en producción:
Los otros dos son ficheros que hoy se generan sin protestar y que el INE rechazaría, así que esta rama los convierte en un mensaje claro en lugar de un fichero inválido. Sobre los porcentajes, conviene matizar lo que decía el primer comentario: con el código actual la suma sale exactamente 100.00 en los 21 ficheros que se generan, así que el arreglo de 2024-2025 funciona. Lo de esta rama es endurecerlo (normalización en centésimas enteras, exacta por construcción) y añadir la coherencia entre tarifa y porcentaje por tipo de cliente, que es otra validación oficial (XML_15 y XML_16) y que la normalización podía romper al redondear un grupo pequeño a cero. Y una regla que no estábamos cumpliendo por diseño: el fichero debe llevar el mes completo aunque el cuestionario pida una sola semana (hoteles) o quincena (apartamentos). El asistente aceptaba cualquier rango, así que quien elegía la semana que le pedía la carta del INE se llevaba un fichero incompleto. Ahora se rechaza el periodo parcial indicando qué fechas seleccionar. Configuración pendiente en 8 propiedades (no es código): 3 con huéspedes españoles sin provincia, 2 con huéspedes sin país de residencia y 3 con las plazas del INE mal configuradas (una a cero). Hoy ya no pueden generar el fichero; queda como tarea de soporte. 31 tests, 0 fallos. |
The order number identifies the establishment in the INE questionnaire and is fixed, so it is stored in the property and prefilled in the INE wizard, where it can also be filled in for the first time. The control code is deliberately not stored: it belongs to a single questionnaire and is single use. Assisted-by: Claude Opus 5
The establishment used to find out about a rejected file days later, on the INE portal, with a message naming an XML element. Two changes move that feedback to the moment the file is generated. The reference period is now expanded to the natural month of the start date instead of being rejected when it is not the whole month. A range reaching into the next month was the worst case: it repeats day numbers inside a place of residence, and the day is a key in the survey schema, so the INE answered with a duplicate key error that says nothing to a receptionist who only picked the wrong end date. The content validations the INE runs after the schema are now applied to the built file, and a failure names the day and the figures involved instead of the XML element. Checked against 97 files generated from two real fleets: the only two files reported are the two the INE would reject, both for overnight stays exceeding the seats declared in the property. The empty month error now points at the check-in data, which is where the survey is built from: several establishments with real occupancy and no completed check-ins would otherwise report an empty month. Assisted-by: Claude Opus 5
Actualizacion 07/08: el fichero se valida antes de entregarloDario, resumen de lo que anade el commit Por queHoy ha entrado un ticket urgente de Beratxa (TR1365131) con dos fallos seguidos del INE en el mismo dia. El segundo es el interesante y ha cambiado una decision de diseno de la PR. El hotel selecciono del 1 de julio al 1 de agosto, que es la forma natural de "marcar julio" en un selector de rango. El fichero salio con el dia
El PMS le dejo pedir ese rango y no dijo nada. El hotel se entera por el portal del INE, con un mensaje que nombra un elemento XML. Que cambia1. El periodo se expande al mes natural de la fecha inicial. Antes esta rama daba error si el rango no era el mes completo; ahora lo normaliza y punto. Motivos: la app manda 2. Las validaciones de contenido del INE se aplican al fichero construido (
3. El error de mes vacio apunta a los check-ins. El informe se construye desde los check-ins, no desde las reservas. En la flota hay establecimientos con ocupacion real y cero check-ins completados que declararian un mes vacio (Route 42: 100 reservas y 193 noches vendidas en julio; Alda Borox: 18 reservas; y tres hoteles de Alda igual). Ahora el mensaje lo dice. Verificacion
Pendiente por mi parte en esta rama
Duda para ti, no la decido yo
|
The configuration checks move from the wizard to the property, as ine_configuration_problems(), and report every missing field at once instead of only the first one. Two computed fields expose the result, ine_ready and ine_blocking_reasons, so the interface can list what to fix instead of offering a download that fails. The seats check joins them: it used to live in the middle of the file generation, and it is the most frequent blocker in the fleet, where establishments have the seats unset while their rooms already offer capacity. Spanish translations for the new messages are included, since the app shows them to the end user through the API. The help texts are left to Weblate. Assisted-by: Claude Opus 5
The INE settings page now lists what is missing before the occupancy survey can be built, instead of leaving the operator to find it out when the download fails. Assisted-by: Claude Opus 5
Estado final de la rama y lo que queda fuera de ellaDario, con Lo que anaden estos dos commitsLas comprobaciones de configuracion pasan del asistente a la propiedad, como Dos campos calculados lo exponen: La comprobacion de plazas se une al checklist. Estaba en medio de Traducciones al espanol de los 17 mensajes nuevos, porque son los que ve el usuario final a traves de la API. Los 26 tests de Lo que NO entra en esta rama, a propositoEl gate de la app. Esto revierte la decision que registre el 05/08 de no tocar El envio por servicio web. IRIA no exige alta: la credencial es el par que viene impreso en la carta del cuestionario, Numero de Orden (11 car., fijo por establecimiento, ya lo guardamos) + Codigo de Control (8 car., de un solo uso, cambia cada cuestionario). Eso pide, como minimo:
Va en PR aparte. Tenemos 4 claves de prueba del INE sin gastar (2 EOH + 2 EOAP). Las subidas de validacion en el portal no consumen el codigo: solo lo consume el envio. El plan es gastar el envio del cartucho #1 de cada encuesta cuando el cliente del WS este escrito y probado contra un fichero ya validado, y dejar el #2 de cada una en recamara. Y la duda de siempre, que sigue siendo tuya
|
The INE counts as an extra bed every bed without a fixed character that is not among the declared places, cots included (survey methodology, 5.10), and it counts every guest who stays the night as a traveller, with no exception by age. The file, however, only reported the extra beds sold as a service, and hardly any establishment of the fleet has an extra bed product configured: a baby in a cot was counted as a traveller while the bed they slept in was not, and the survey was rejected as soon as the guests of a night exceeded the declared seats. Extra beds are now also derived from the guests registered in a room beyond the places it offers, and the larger of the two sources wins, so establishments that do sell the service keep reporting it. The declared seats are already required to be at least the capacity of the rooms reported to the INE, which makes the derived figure enough for the overnight stays to never exceed the seats plus the extra beds. Since a room whose capacity is set too low would then report an extra bed every single night, the wizard lists the nights it reported one. Assisted-by: Claude Opus 5
Camas supletorias: añadido
|
The survey carries the country of residence in ID_PAIS, taken from the ISO 3166-1 alpha-3 code, but the INE publishes its own country list next to the survey schemas and it does not match ISO everywhere. Kosovo has no alpha-3 in ISO, so Odoo leaves it empty and the file came out with an empty ID_PAIS, rejected by the schema with nothing pointing at the guest who caused it. The INE codes it as KOS. The code of the country of residence now goes through the INE list, and a country left without one is reported by name instead of producing a file the establishment can only see rejected days later, on the portal. The exception lives in the code because the countries of the base module carry noupdate and a data row over them is silently ignored. The new ine_country_code field is there for whatever the INE changes later without waiting for a release. Checked against the whole fleet, 226 countries of residence in use over 50 databases: Kosovo is the only one missing a code, and Spain the only one outside the INE list, which is correct because Spanish residents travel in ID_PROVINCIA_ISLA. Assisted-by: Claude Opus 5
Códigos de país: añadido
|
Países de Odoo sin code_alpha3 |
1 — Kosovo (XK) |
| Alpha-3 de Odoo que el INE no reconoce | 1 — ESP, y es correcto: los residentes en España viajan en ID_PROVINCIA_ISLA, no en ID_PAIS, por eso el INE no los lista |
| Códigos del INE sin país equivalente en Odoo | 1 — KOS, el mismo caso |
O sea que la correspondencia es 1 a 1 salvo Kosovo. No hay más agujeros hoy, ni entre los países usados ni entre los que podrían usarse mañana.
Cómo queda cubierto para el futuro
Dos capas, porque la lista del INE puede cambiar y la de Odoo también:
res.country.ine_get_country_code()resuelve en este orden: campoine_country_codede la ficha del país → tabla de excepciones del módulo →code_alpha3. Así, si el INE añade otro código propio, se arregla desde la ficha del país sin esperar a una release.- Y sobre todo: si un país se queda sin código, el asistente lo dice por su nombre en vez de emitir un
ID_PAISvacío. Antes el establecimiento se enteraba días después, en el portal del INE, con un error de esquema que no menciona ningún país. Ahora no llega a generarse el fichero y el mensaje nombra el país que falta.
Un detalle de implementación que merece explicación
La excepción está en el código y no en un fichero de datos a propósito: los países del módulo base llevan noupdate, así que una fila CSV sobre base.xk se ignora en silencio. Lo probé primero por ahí y el dato no llegaba a escribirse sin dar ningún error, que es justo el tipo de fallo que no queremos. El campo ine_country_code se queda para las excepciones futuras, que sí se pueden poner a mano.
Verificación
32 tests en verde. Tres nuevos: que un país normal se resuelve por su alpha-3, que Kosovo se resuelve como KOS pese a no tener alpha-3, y que un país sin ningún código se reporta con un error que lo nombra.
Con esto van cuatro motivos distintos de rechazo cubiertos en la rama, los cuatro salidos de tickets reales de este mes: provincia de residencia sin rellenar, periodo que no es el mes natural (por exceso y por defecto), camas supletorias sin declarar y códigos de país fuera de la lista del INE.
The wizard had grown to hold three different jobs at once: reading the occupancy out of the PMS, building the XML, and checking the result against the rules the INE applies after the schema. The last one only needs the built file, so it moves to ine_content_checks, where each rule carries the identifier the INE publishes it under and can be read, and tested, without a record in between. The module docstring now says what the two surveys are, why two schema variants coexist and in what order a file is built, which is the context missing to read the rest. Two defects found while going through it: - The hotel survey cut the phone at 12 characters while the schema takes 13 and the apartments survey already used 13, so an international number lost its last digit. - The file was named INE_7_2026.xml while the REST API named the same file INE_07_2026.xml. Assisted-by: Claude Opus 5
davidpachecop
changed the title
|
@DarioLodeiros he reescrito la descripción de la PR y he hecho una pasada de limpieza, porque la última vez la dejaste aparcada con la sensación de que el código estaba sucio y de que tocaba dependencias raras. Ambas cosas eran razonables, así que van contestadas: Las dependencias no se tocan. El único cambio del manifest es el bump de versión. Lo que abultaba eran los 4 ficheros El código estaba sucio, y en parte sigue siéndolo. El wizard hacía tres trabajos a la vez: leer la ocupación del PMS, construir el XML y comprobar el resultado. He separado el tercero a No he tocado lo que ya había antes de esta rama, para no inflar el diff con movimientos. Dos defectos reales que salieron en la pasada:
En la descripción tienes una guía de revisión con el orden sugerido de lectura, de mayor a menor densidad de decisión, y una sección de preguntas abiertas con las tres cosas que prefiero que decidas tú antes de mergear (el criterio de días abiertos, el gate de la app y si las traducciones las quieres por Weblate). Sobre la urgencia: son cuatro tickets este verano con cuatro causas distintas, y el barrido de la flota dice que se repiten cada cierre de mes. Además, la encuesta de apartamentos hoy no existe en Roomdoo: a esos clientes se la estamos generando a mano cada mes, uno a uno. 34 tests en verde. Cuando puedas, aunque sea para decirme por dónde no va. |
|
Esta PR se traslada a OCA: OCA#457, contra Qué ha cambiado al moverla:
34 tests en verde sobre la rama rebasada y pre-commit limpio. Queda decidir qué hacemos con esta PR. Si se cierra, el arreglo no llega a producción hasta que OCA mergee y se baje aguas abajo, y el cierre de mes del INE no espera. La alternativa es mantenerla abierta como vía de despliegue y que la de OCA sea la canónica, asumiendo que hay que rebasarla cuando allí se mergee. |
949e4a1 to
7adda40
Compare
Las encuestas de ocupación del INE se presentan ahora por IRIA, que ya no deja editar el fichero después de subirlo. Lo que va mal en el XML vuelve como rechazo, y el hotelero lo descubre días después con un mensaje que no nombra ni al huésped ni al campo que lo provoca.
Esta PR hace dos cosas: añade la encuesta de apartamentos turísticos (EOAP), que hoy no existe, y corrige la hotelera (EOH) para los motivos de rechazo que hemos visto en producción, avisando en el momento de generar en lugar de entregar un fichero que el INE va a rechazar.
Por qué ahora
Cuatro tickets este verano, cuatro causas distintas, todas terminando en el mismo sitio: un fichero rechazado y un cliente bloqueado a final de mes.
Ninguna era un fallo del cliente. Y el barrido de la flota dice que se repetirán: sobre 29 propiedades con INE configurado en roomdoo01 y 96 en Alda, en julio 29 no podían ni generar el fichero y 11 más lo generaban inválido.
Qué entrega
Bloque 1 — Encuesta de apartamentos turísticos (EOAP), nueva
Hoy Roomdoo solo genera el guión hotelero. Un establecimiento de apartamentos recibe un cuestionario distinto (raíz
APARTAMENTOSen vez deENCUESTA) y no tiene forma de presentarlo desde el PMS.survey_typeenpms.ine.tourism.type.category), sin campos nuevos que el usuario tenga que decidir. Las 53 categorías existentes quedan comohotely se añaden las 5 de apartamentos (0–4 llaves).pms.room(estudio / 2-4 pax / 4-6 pax / otros), con inferencia por capacidad si no se establece: funciona sin configurar nada.INFORMANTEenpms.property, obligatorio en EOAP.CABECERA,CABECERA_APARTAMENTOS,INFORMANTE,ALOJAMIENTO(compartido con el guión hotelero, extraído a helper común),CAPACIDADyOCUPACIONpor tipología,PRECIOSyPERSONAL_OCUPADO.Bloque 2 — Correcciones de la encuesta hotelera (EOH)
Sin cambiar el formato que los establecimientos ya suben con éxito.
2.1 — Decir qué falta antes de intentar la descarga. Las comprobaciones de configuración se mueven del wizard a la propiedad (
ine_configuration_problems()), devuelven todo lo que falta de una vez en lugar de solo lo primero, y se exponen comoine_ready/ine_blocking_reasonspara que la interfaz pueda listarlo. Antes: un error genérico por cada intento.2.2 — El periodo es siempre el mes natural. El cuestionario pide una semana (hoteles) o una quincena (apartamentos), pero el fichero debe llevar el mes entero. El selector de rango invitaba a equivocarse en las dos direcciones y el PMS no decía nada:
01aparece dos veces dentro de una mismaRESIDENCIAy el esquema lo rechaza, porque ahí el día es una clave.XML_8) falla el primer día del fichero, porque el INE asume cero pernoctaciones el día anterior.Ahora el periodo se normaliza al mes de la fecha inicial, cruce o no cruce.
2.3 — Camas supletorias deducidas de la ocupación. Solo se contaban las vendidas como servicio, y casi ningún establecimiento de la flota tiene ese producto configurado. Un bebé en cuna contaba como viajero mientras su cama no se declaraba, y el INE rechazaba en cuanto los huéspedes de una noche superaban las plazas. La metodología del INE (5.10) es explícita: "Las cunas serán consideradas, igualmente, como camas supletorias".
Se combinan dos fuentes y gana la mayor: las vendidas como servicio (intacto) y los huéspedes registrados por encima de las plazas de su habitación. Como el asistente ya exige
ine_seats >= suma de capacidades, la derivación por habitación siempre domina el exceso agregado:XML_12pasa a no poder fallar por construcción.2.4 — Códigos de país del INE. El INE publica su propia lista junto a los esquemas. Sigue ISO 3166-1 alpha-3 salvo donde la ISO no tiene código: Kosovo es
KOSpara ellos y no tiene alpha-3 en Odoo, así que salía unID_PAISvacío. Contrastado contra los 226 países de residencia en uso en 50 bases de datos: es la única excepción, y España la única fuera de su lista, que es correcto porque va enID_PROVINCIA_ISLA.2.5 — Formato. Decimales a 2 posiciones y porcentajes normalizados en centésimas enteras, de modo que la suma impresa es exactamente 100.00 por construcción (origen de tickets recurrentes, con cuatro commits históricos parcheándolo en float). UTF-8 real: el fichero declaraba ISO-8859-1 mientras codificaba UTF-8. Literal de provincia del INE (máx. 25 caracteres): varios nombres de Odoo lo superan, p. ej. "Illes Balears (Islas Baleares)" (30) →
BALEARES.Cómo está organizado
Generar un fichero son tres pasos, en este orden, y cada uno vive en un sitio distinto:
models/pms_property.pywizards/wizard_ine.pywizards/ine_content_checks.pyEl paso 3 es código puro sin ORM: recibe el XML y devuelve la lista de problemas. Cada regla lleva el identificador con el que el INE la publica (
XML_0…XML_17), se lee sin tener el wizard delante y se testea sin crear registros.Guía de revisión
4.404 líneas suenan a mucho, pero la mitad no es código:
.xsdes.poOrden sugerido, de mayor a menor densidad de decisión:
wizards/wizard_ine.py, el docstring del módulo: qué son las dos encuestas, por qué conviven dos variantes de esquema y en qué orden se construye un fichero. Es el contexto que falta para leer lo demás.wizards/ine_content_checks.py(254 líneas): las reglas del INE, aisladas. Si algo de aquí no cuadra con la especificación, se ve de un vistazo.models/pms_property.py: el checklist de configuración.wizards/wizard_ine.py, los dos builders:_ine_build_xml_hotely_ine_build_xml_apartments.Los commits están ordenados por tema y cada uno explica su porqué;
git log --reversese lee como el hilo del problema.Verificación
XML_12que quedaban en Alda (Galería Coruña día 18, Corrubedo día 04) los resuelve el bloque 2.3.Riesgo y despliegue
GET /ine-reportsigue devolviendo el mismo XML; el wizard decide el guión por la categoría de la propiedad. No hace falta tocarpms_api_restniroomdoo_fastapipara desplegar esto.noupdate). Las 53 categorías existentes pasan ahotel, y una propiedad sinsurvey_typetambién cae enhotelpor defecto.ine_seatssin poner.Preguntas abiertas
Tres cosas que prefiero que decidas tú antes de mergear:
DIAS_ABIERTO_MES_REFERENCIAse declara siempre como los días naturales del mes. Para un establecimiento de temporada que abrió el día 15 eso es falso y le diluye su propia tasa de ocupación. Se podría derivar de la disponibilidad, pero cambia el criterio de lo que ya han declarado todos. Lo he dejado como está.canDownloadIneReport) sigue mirando solo número de registro y categoría. Con el checklist ya disponible tendría sentido que la app listara lo que falta en vez de ofrecer una descarga que va a fallar, pero eso es un cambio enpms_api_resty acopla el despliegue a esta rama. Lo dejo fuera a propósito.a9a2657e, separado. Si prefieres que las incorpore Weblate, se descarta ese commit sin tocar nada más.Lo que no entra aquí
La presentación por servicio web desde el PMS (
SolicitudEncuestaWS), para no tener que pisar el portal del INE. IRIA no exige alta previa: la credencial es el par Nº de Orden (fijo, ya se guarda en la propiedad con esta PR) + Código de Control (de un solo uso, nunca se guarda). Va en una PR aparte, con su modelo de envíos y el acuse en PDF. Tenemos 4 credenciales de prueba del INE sin gastar para validarlo.