[davidpachecop]

The INE (Spanish National Statistics Institute) shut down its ARCE platform and moved the occupancy surveys to IRIA, where a questionnaire can no longer be edited once uploaded. Whatever is wrong in the file comes back as a rejection, days later, with a message that names neither the guest nor the setting behind it.

This PR adds the tourist apartments occupancy survey (EOAP), which the module did not build at all, and fixes the hotel one (EOH) for the rejection causes seen in production, reporting them while the file is being built instead of handing over a file the INE will reject.

Tourist apartments occupancy survey (EOAP)

An establishment listed as tourist apartments answers a different questionnaire from a hotel (root element APARTAMENTOS instead of ENCUESTA). Until now the module built the hotel one for everybody, so those establishments had no way to answer their survey from the PMS.

• The survey is picked from the INE category of the property (new survey_type on pms.ine.tourism.type.category), so there is no new setting to decide. The 53 existing categories are seeded as hotel and the 5 apartment ones (0–4 keys) are added.
• Apartment typology on pms.room (studio / 2-4 pax / 4-6 pax / other), inferred from the capacity of the room when left empty, so it works unconfigured.
• INFORMANTE block on pms.property, mandatory in this survey.
• Full builder: CABECERA, CABECERA_APARTAMENTOS, INFORMANTE, ALOJAMIENTO (shared with the hotel survey, extracted to a common helper), CAPACIDAD and OCUPACION per typology, PRECIOS and PERSONAL_OCUPADO.

A file built by this code for a real establishment was uploaded to IRIA and accepted by the INE, which issued the receipt.

Hotel occupancy survey (EOH)

Without changing the format establishments already upload successfully.

Configuration checks move to the property. ine_configuration_problems() returns everything that is missing at once instead of only the first thing, exposed as ine_ready / ine_blocking_reasons so the interface can list it. Before, each attempt produced one generic error and another download.

The period is always the natural month. The questionnaire asks for a week (hotels) or a fortnight (apartments), but the file must carry the whole month. A range was accepted as given, and it failed in both directions:

• Reaching into the next month repeats a day number inside a RESIDENCIA, and the schema rejects it because the day is a key there.
• Falling short of the month breaks the daily chain (XML_8) on the first day of the file, because the INE assumes no overnight stays the day before.

The period is now expanded to the month of the start date.

Extra beds are derived from the occupancy. Only the ones sold as a service were counted, and hardly any establishment configures that product. A baby in a cot counted as a traveller while the bed they slept in did not, and the INE rejected the file as soon as the guests of a night exceeded the declared seats. The survey methodology (5.10) is explicit that cots count as extra beds, and travellers (5.4) have no exception by age.

Two sources are now combined and the larger one wins: the extra beds sold as a service, and the guests registered beyond the places their room offers. Since the declared seats are already required to be at least the capacity of the rooms reported, the per-room figure always dominates the aggregate shortfall, which makes XML_12 unfailable by construction.

Country codes of the INE. The INE publishes its own country list next to the survey schemas. It follows ISO 3166-1 alpha-3 except where ISO has no code: Kosovo is KOS for them and has no alpha-3 in Odoo, so ID_PAIS came out empty and the schema rejected the file. A new ine_country_code on res.country covers the exceptions, and a country left without a code is now reported by name.

Formatting. Decimals with 2 positions and percentages normalised in whole hundredths, so the printed sum is exactly 100.00 by construction. Real UTF-8: the file declared ISO-8859-1 while encoding UTF-8. Province literal of the specification (max. 25 characters), seeded for the 52 provinces from the published annex: several Odoo names exceed it.

How it is organised

Building a file is three steps, each in its own place:

Step	Where	What it does
1. Is the property ready?	models/pms_property.py	Lists what is missing to configure, no XML involved
2. Build the XML	wizards/wizard_ine.py	Reads the occupancy and builds the questionnaire
3. Would the INE accept it?	wizards/ine_content_checks.py	The content rules, over the built file

Step 3 is plain code with no ORM: it takes the XML and returns the list of problems. Each rule carries the identifier the INE publishes it under (XML_0 … XML_17), reads without the wizard in front of it and is tested without creating records.

Reviewing this

Half of the diff is not code:

	Lines	What
.xsd fixtures	2,234	The 4 schemas as the INE publishes them. Not loaded at runtime: only the tests use them, to prove the file validates
Tests	564	34 tests
Data	218	Provinces and categories from the published annexes
Code	~1,300	What there is to review

Suggested order: the module docstring of wizards/wizard_ine.py (what the two surveys are, why two schema variants coexist, in what order a file is built), then wizards/ine_content_checks.py, then models/pms_property.py, then the two builders, then the tests.

Tests

34 tests, covering validation against the 4 schemas (published and versioned, hotel and apartments), exact percentage sum, rate and percentage consistency, period expansion in both directions, extra beds through both sources, country codes, the configuration checklist and each content rule.

Beyond the test suite, every correction was checked by regenerating the real files of two months for 125 properties across 50 databases, read-only, and comparing the result against the schemas and the content rules.

Notes

• No new dependency: the only manifest change is the version bump.
• No migration: the new fields are created by Odoo and the province and category data files update on their own. Existing categories become hotel, and a property without one falls back to hotel.
• Translations are left to Weblate.
• Behaviour change worth knowing: a property that used to download a file the INE would reject now gets an error saying what is missing. That is the point, but it makes pending configuration visible the first month.

Not in this PR

Submitting the questionnaire through the INE web service, so the portal does not have to be visited at all. IRIA requires no prior registration for it: the credential is the order number printed on the questionnaire, which this PR already keeps in the property, plus a single-use control code that is never stored.

Size

This is over the 500 line reference point of the AI policy, so to be explicit about what it is made of: 2,234 of the added lines are the four .xsd schema fixtures published by the INE, 564 the tests and 218 the reference data from the official annexes. The code is around 1,300 lines, of which roughly half is the new apartments survey.

It can be split into the apartments survey and the hotel fixes if a maintainer prefers, though both share the ALOJAMIENTO builder and the test fixtures, and several of the hotel fixes are what make the apartments file pass validation too. Happy to do it either way — say the word before reviewing and I will resubmit rather than have anyone read it twice.

Disclosure

Developed with AI assistance, declared with an Assisted-by: Claude Opus 5 trailer on every commit, per the OCA Generative AI / LLM policy. The work was directed, reviewed and tested by me against the INE specification and against real data, and I take full responsibility for it: ask about any line and I will answer for it.

[davidpachecop]

cc @DarioLodeiros as maintainer of this module.

A note on the size, since it looks heavier than it is: 2,234 of the 4,351 added lines are the four .xsd fixtures, the survey schemas as the INE publishes them. They are not loaded at runtime — only the tests use them, to prove the generated file validates against both the published schema and the versioned one IRIA serves. Another 564 lines are the tests and 218 the reference data from the official annexes, so the code to review is around 1,300 lines.

Happy to split it if you would rather review the apartments survey and the hotel fixes separately, although they share the ALOJAMIENTO builder and most of the test fixtures.